From: Jamie Hanrahan [jeh@cmkrnl.com]
Sent: Thursday, April 25, 2002 6:54 PM
To: NT Developers Interest List
Subject: [ntdev] RE: BugCheck 7F

Contrary to what the doc suggests, "double faults" are almost always due
to a blown kernel stack.  

A double fault happens when the processor raises an exception while in
the various first stages of handling of previous exception.  How this
happens with a blown stack is as follows:  

You try to do a PUSH of something while ESP is already at the top of the
last page of kernel stack.  The next page earlier in memory "off the
top" of every kernel stack is set up as a no-access page, to catch this
very thing.  Since the PTE for that page has its valid bit clear, the
processor sees this as a page fault.  As with all other faults it tries
to push EIP (and the faulted-to address) onto the stack and then vector
off through the appropriate entry in the IDT.  Whups, pushing EIP on the
stack caused a fault!  That's the "double fault".  There's a special
entry in the IDT just for double faults, specifying its own task state
segment with its own kernel stack reserved just for this purpose.  

Look at the stack with kv and see if there isn't either a task gate or
trap frame recorded... either:  

805366e0 805338eb 0000007f 00000008 80042000 nt!KiTrap08+0x57
 (FPO: TaskGate 28:0)
       ^^^^^^^^^^^^^

or 

f5826360 804e16de 00000000 e4ed9528 00000000 nt!KiTrap0E+0xbc
 (FPO: [0,0] TrapFrame @ f5826378)
             ^^^^^^^^^^^^^^^^^^^^

(lines manually wrapped for clarity) 

In the former case, use .tss on the part before the colon (e.g. .tss
28), in the latter case, use .trap on the trap frame address (e.g. .trap
f5826378).  These commands will restore the debugger's register context
to that recorded just before each task switch or trap, and let you see
what was happening previously on the stack.   You may find several of
these on the stack - do them in reverse sequence (newest to oldest, top
to bottom) to walk back through the stack.  .thread (no arguments)
resets the debugger's register context back to the original.  

I'm looking at one of these that came through KiTrap08 (and seems to
have been caused, btw, by one of the more popular virus scanners...)
The disassembly just before the call to KeBugCheckEx shows that the
address in the second bugcheck argument (third argument to
KeBugCheckEx), 80042000, is the previous task state segment address
saved from the PCR.  The current TSS is the one for handling the double
fault.  In other words, if you had done a !pcr prior to the double
fault, it would have shown this value in the TSS field.  It's the same
address in this crash; I haven't found this to be a useful piece of
information for analyzing these crashes, but there it is.  

See the ia32 Software Developer's Manual, volume 3, for more info on the
hardware mechanisms.  Download it for free here:
http://developer.intel.com/design/pentium4/manuals/245472.htm  The stuff
about the double fault is on page 5-33 of the current edition.  If you
haven't seen this stuff at this level before, I'd read all of the
"introductory" material in chapter 5, up through section 5-13. 

       --- Jamie Hanrahan

 


> -----Original Message-----
> From: bounce-ntdev-2233@lists.osr.com 
> [mailto:bounce-ntdev-2233@lists.osr.com] On Behalf Of Jos Scherders
> Sent: Thursday, April 25, 2002 14:16
> To: NT Developers Interest List
> Subject: [ntdev] BugCheck 7F
> 
> 
> Hi,
>  
> After making some changes to my filter driver (so I handle 
> MJ_POWER ) to make it work on XP and 2000 I suddenly get 
> Bugcheck 7F with these parameters:
>  
>     8    80042000    0    0
>  
> In the call stack all I see is KeBugCheck and Kei386EoiHelper.
>  
> Does anyone have a clue where I should look for the problem ? 
> I know the first parameter indicates a double fault and 
> apparently it is usually related to a hardware problem but I 
> don't think this is the case here, because when I don't load 
> my driver the problem disappears. All I changed was some code 
> related to IRP_MJ_POWER. I added calls to PoCallDriver and 
> PoStartNextPowerIrp because I got a bugcheck related to POWER 
> management.
>  
> Jos.
>  
> PS: Does anyone know what the second parameter means and 
> where this is documented ?
> --- 
> You are currently subscribed to ntdev as: jeh@cmkrnl.com 
> To unsubscribe send a blank email to %%email.unsub%% 
> 


---
You are currently subscribed to ntdev as: GlennEverhart@FirstUSA.com
To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com