Hi,
It’s just a wild guess but I think I have a good explanation for your
mystery.
It’s explained both IRQL = 0xFF mystery and why the disassembly went
scramble.
(=> The function start with the pair ‘push ebp’ ‘mov ebp,esp’ opcodes)
Before I say my guess some background:
The IRQL is a variable store per each processor. It’s located inside per
processor struct called KPCR->Irql.
The struct position is fixed in memory 0xFFDFF000 (At least at Windows 2K
version), but it can be accessed
(and is accessed) by the fs:[0] pointer.
The FS is a segment register which acts differently upon user-mode and
kernel-mode:
* In user-mode application, the FS register points out to the
Thread-Local-Some-Internal-Name,
where the fs:[0] holds the exception handling list (SEH or C++
exception).
* In Kernel mode, the FS points to the Processor/thread/process
KPCR/ETHREAD/EPROCESS
And now:
I am pretty sure that MmGetSystemRoutine is not the source of your troubles,
My guess is that during a context-switch, interrupt or other thread, the FS
segment selector or the CR3 register
points to illegal kernel mode value…
When I encounter this problem I played with the IDT entries and did some
low-level interrupt hooking…
Each bug results a crash which was similar to your bugcheck.
Perhaps you are doing something wrong such as playing with the scheduler,
IDT tables??
Can you tell me please what is the value of the FS register during the trap
(And not when during the TRAP_FRAME)?
Inisde kernel-mode it’s value should be 0x30.
Elad Raz
CTO
RazTech