Low level WinNT debugger

http://www.sysinternals.com/ntw2k/freeware/debugview.shtml
http://www.sysinternals.com/files/dbgvnt.zip

DebugView is an application that lets you monitor debug output on your local system, or any computer on the network that you can reach via TCP/IP. It is capable of displaying both kernel-mode and Win32 debug output, so you don抰 need a debugger to catch the debug output your applications or device drivers generate, nor do you need to modify your applications or drivers to use non-standard debug output APIs.

DebugView works on Windows 95, 98, Me, NT 4, 2000, XP and .NET Server.
DebugView Capture


Under Windows 95, 98, and Me DebugView will capture output from the following sources:
Win32 OutputDebugString
Win16 OutputDebugString
Kernel-mode Out_Debug_String
Kernel-mode _Debug_Printf_Service
Under Windows NT, 2000, XP and .NET Server DebugView will capture:
Win32 OutputDebugString
Kernel-mode DbgPrint
All kernel-mode variants of DbgPrint implemented in Windows XP and .NET Server
DebugView also extracts kernel-mode debug output generated before a crash from Window NT/2000/XP crash dump files if DebugView was capturing at the time of the crash.

One fascinating behavior of sice is that when you bring out sice console, the entire system runs only one thread only--the sice thread, the schedular, I/O, etc instantly stops and sice takes control the entire system. This is indication of system hooking of IDT, TSS, GDT, LDT, you name it, anything that has to do with scheduling, I/O. So in fact it doesn't matter when s-ice is loaded, but once it's loaded, it took over the entire system. And sice HOOK everything that's necessary so that when s-ice console is up, s-ice thread is the only thing that runs on your CPU. And notably this HOOKING only occurs when the console is up, so I am guessing sice is reporting the correct idt, however, there is no other way to tell if sice is lying because when sice console is active, no other thread can run. So when you list the two tables, they are taken at two different time and they really don't mean anything. Only if you could manage to take 2 snapshots, one from sice, one from another application of the idt at the same time, you can tell if sice is reporting the real idt as it is seen by the cpu. I am inclined to think sice is reporting the correct idt at the moment it's active.

As far as I know, M$ kernel debugger kd does not do this, for that matter nothing else other than sice on windows effective turns windows OS into a dos like OS.

Well, Sice IDT dump shows that int1 & int3 handlers are in the ntoskrnl - but I think it's SI's code that really handles those ints. Maybe SI hooks itself inside windows handlers instead of just replacing IDT entries - I'm not that familiar with its internal working

[edit]
Just checked what's at address displayed by my dumper:

:bpx 8:b3fcd778
Breakpoints not allowed within SoftICE

Remember that even in ring0 there are IRQL interrupt priorities.

Maybe Softice has a higher priority.

Or, maybe I don't know what I'm talking about.

I know that, it just proves that int1 & int3 handlers are within softice, but softice doesn't display it.

[edit]
Looking from LiveKD with softice loaded shows this too.

[SiNTAX]

SoftICE is virtualising certain hardware parts of the system, tricking WinNT so to speak. You can compare it a bit with VMware or VirtualPC.. only that those 2 go way further in the virtualisation (ie. they also create virtual devices, which SoftICE doesn't do ofcourse).

I took a little time to look into the numbers, in fact, the numbers reported from sice for int3 and int0 interrupt handlers are the right address. This means either your kernel dumper is not working correctly or when you took the snapshot sice is not loaded. On my system, w2k+sp4, everything says 60466f5e is the right address for int3. And nobody knows what b3fcd787 is, in fact, by manually going through the PTE, this address is never allocated in the kernel.