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.