Consider
(1) int 0x0d
(2) xor eax, eax
mov eax, [eax]
Both of these cases produce a GPF (right?) But in SoftICE,
if you use F8 to step into the int 0x0d handler, you
wind up in _KiTrap0D in ntoskrnl, whereas if you hit F8 over the mov eax, [eax],
you wind up in ntdll.dll. Shouldn't both of these cause a
jump to the same handler given in the IDT? At least the Intel
dox seem to say so. What have I missed? Thanks.

it depends ;-).

1st one always causes a GPF in a user app if the IDT descriptor has DPL=0 which i think is the case in both 9x and nt.

however, the 2nd one can cause either a GPF or a page fault. in 9x you will get a GPF because the win32 data selector/descriptor specify an expand down segment whose lower limit is not 0 (some 4 digit value, don't recall it). this is the way 9x catches null pointer dereferences from win32 apps without interfering with the V86 part of the system virtual machine. in nt you will get a page fault as the win32 data segment is a true flat one and the paging logic is used to catch null pointer related problems.



enter softice... and turn the world upside down ;-). the exception generated by the CPU on a faulting instruction has nothing to do with what (and when) you see in the debugger. it is entirely up to the designer of the debugger when he chooses to notify the user about it (if at all). softice hooks many exception handlers for various purposes and does its own processing before it decides to pass it down to the OS kernel or pop up the softice window or just let everything go as if nothing had happened. so the intel manuals are right, and you'd be better off with reverse engineering both the NT and NTICE exception handlers to get a better picture.

Yes, that explains it. The 'idt' command presents a fake IDT,
pretending SoftICE isn't loaded. The real interrupt offsets can
still be seen in memory. Thanks for your help.

no all handlers, just take a look at int 1 for example, it points directly
to ntice if you browse the idt gate, but if you just look at ide results,sice will show you the real win address, hiding the sice handler.