Question

For example:

myapp.exe caused a Microsoft C++ Exception (0xe06d7363) in module
kernel32.dll at 001b:7c812afb.

I’m asking this out of curiosity, because I’ve noticed that in all exceptions and crashes this number (001b) always stays the same, while the latter number changes (I assume it holds the instruction pointer’s value).

So what does this 001b mean, exactly?

Answer 1

You are seeing an address of the form CS:EIP, where on your processor CS corresponds to the 16-bit Code Segment register and the EIP is the 32-bit Instruction Pointer (it would be just IP in a 16-bit mode).

That’s the part I knew before looking into why you are seeing a CS of 0x001b (0b0000000000011011) in all the cases you’re studying. Anything else I’m about to say is semi-informed guess-work and/or wild speculation. I’m kind of following along with these:

http://en.wikipedia.org/wiki/X86_memory_segmentation

http://www.cs.cmu.edu/~410/doc/segments/segments.html

So here goes nothing. Just add a “maybe” after every sentence I’m about to say, and someone who does this kind of work for serious can step in and correct the mistakes…

---

In protected mode, the lower two bits of the CS register are the RPL or “Requested Privilege Level”. The protection rings are:

• 0 – Operating System Kernel
• 1 and 2 – Operating System Services
• 3 – Applications

You’re in 3 (0b11) because presumably these are applications that are crashing while calling a system DLL. That’s in contrast to…say…the OS itself having a bug–which would be giving you a blue screen of death instead of a nice Windows dialog. In fact, if you Google around for some blue screens they often start with 0x0028 (0b0000000000101000) and we can see that’s a kernel-level crash.

The next most significant bit is the TI or “Table Indicator”…which is either 0 for the global descriptor table or 1 for the local descriptor table. (This provides a way of interpreting the meaning of the index held in the remaining upper 13 bits of the CS register we haven’t talked about yet.)

In the crash you’re seeing you’ve got 0 in the third bit to indicate use a global descriptor table. That’s because every app doesn’t load its own copy of the same DLL, and your crash is happening inside of a DLL (presumably of it being passed improper data from your app). If your crash was in the code of an EXE we’d expect this to be a 1. My Windows experience is hazy but I seem to remember you get a different sort of message when the crash is actually in your program, and you don’t get the CS register output like you do when it happens in a DLL.

Now we’re left with the rest of it. Index 3 (0b0000000000011) in the Global Descriptor Table. Wazzat mean? Don’t have the source code for Windows on hand, but I did find some references in this kernel tutorial:

http://www.jamesmolloy.co.uk/tutorial_html/4.-The%20GDT%20and%20IDT.html

If you look into the init_gdt() from that, you see:

gdt_set_gate(0, 0, 0, 0, 0);                // Null segment
gdt_set_gate(1, 0, 0xFFFFFFFF, 0x9A, 0xCF); // Code segment
gdt_set_gate(2, 0, 0xFFFFFFFF, 0x92, 0xCF); // Data segment
gdt_set_gate(3, 0, 0xFFFFFFFF, 0xFA, 0xCF); // User mode code segment
gdt_set_gate(4, 0, 0xFFFFFFFF, 0xF2, 0xCF); // User mode data segment

So Windows might use similar numbers (or even the same). Perhaps kernel32.dll is running the user mode code segment because it hasn’t validated the stuff you passed into it yet enough to switch over into code segment 1.

…maybe. 😛