OK. This makes more sense now - you have the IDLE thread. That’s why it
can’t get the IRP list (there’s no ETHREAD structure for the idle thread,
only a KTHREAD, since the rest of the executive doesn’t get involved in the
idle thread.) The KiRetireDpcList makes sense, too. That probably is the
entire stack trace you have there - the “dword ptr ECX” is probably the
pointer to the DPC routine. If that is the case, it is very likely that the
first argument (the address of the KDPC) is probably embedded within the
device object (most DPCs are, although drivers can create additional KDPC
objects…) So, try !pool on that address and if you get back the ‘Devi’
tag, find the beginning of the device object ("!kdex2x86.strct DEVICE_OBJECT
will give you the offset to the KDPC and that in turn will give you the
number to subtract from the KDPC address to get the DEVICE_OBJECT address,
which you can then feed to !devobj.)
And, of course, IopfCompleteRequest is just IoCompleteRequest in sheep’s
clothing. Try doing “u IoCompleteRequest” sometime and you’ll see the
sequence - jump through a pointer and the pointer is… ta-dah!
IopfCompleteRequest. The names have been changed to confuse the developer!
IF that is right, your IRP would be 8046EFA0 (no guarantees here, but when
groveling around in memory like this there never are.) If not, try tracking
backwards from the call to MmUnlockPages and see if you can find where the
MDL came from because THAT is going to be your IRP. This sequence makes
sense - a DPC calling IoCompleteRequest which then unlocks the MDL in the
IRP, which means you should be able to unravel it - at least to figure out
which driver it is!
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Hope to see you at the next OSR file systems class in San Jose, CA September
16, 2002!
-----Original Message-----
From: xxxxx@charter.net [mailto:xxxxx@charter.net]
Sent: Thursday, September 05, 2002 11:45 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Deciphering a PFN_LIST_CORRUPT bugcheck
I tried !thread and !kdex2x86.stack (see below) but they were not much
help either (unable to get IRP object). Thanks for your help, I
appreciate your input. Looks like more drudging for me!
kd> !kdex2x86.stack
T. Address RetAddr Called Procedure
*2 80473154 8044C988 nt!KeBugCheckEx(0000004E, 00000007, 00001122,…);
*1 80473174 804373D6 nt!MiDecrementReferenceCount(8124F288, 81126A68,
804731AC,…);
*1 8047318C 8041F922 nt!MmUnlockPages(8124F202, 811BF428, 8185236C,…);
*1 804731B0 BFF6C57A nt!IopfCompleteRequest(8046EFA0, 8046F230,
FFDFF000,…);
*1 804731C4 80463EE5 dword ptr ECX(81852428, 008520E0, 811BF428,…);
*1 804731D8 80463E7F nt!KiRetireDpcList(0000000E, 00000000, 00000000,…);
kd> !thread
THREAD 8046f230 Cid 0.0 Teb: 00000000 Win32Thread: 00000000 RUNNING
IRP List:
unable to get IRP object
Not impersonating
Owning Process 8046efa0
WaitTime (seconds) 0
Context Switch Count 2017
UserTime 0:00:00.0000
KernelTime 0:00:16.0687
Start Address 0x00000000
Stack Init 80473480 Current 804731d0 Base 80473480 Limit 80470480 Call 0
Priority 16 BasePriority 0 PriorityDecrement 0 DecrementCount 0
The debugger isn’t the most recent, but new enough it shouldn’t manifest
serious problems in this regard. I’m wondering if what you have is
something/someone damaging the stack here. This is not going to be an
easy
find, since you don’t really have much to go on. Did you look at the
thread? At the stack boundaries? Did you try “!kdex2x86.stack”? It
automates this whole stack groveling (so you can sift through the detritus
and see if there is anything good in it.)
The PFN_LIST_CORRUPT problem is probably just an MDL mis-handling issue.
What is going to be more interesting is to see if you can figure out where
it originated. Does !thread show any in-progress IRPs?
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Hope to see you at the next OSR file systems class in San Jose, CA
September
16, 2002!
-----Original Message-----
From: xxxxx@charter.net [mailto:xxxxx@charter.net]
Sent: Wednesday, September 04, 2002 6:00 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Deciphering a PFN_LIST_CORRUPT bugcheck
I’m using windbg 6.0.0007.0 on W2K (client and host). No warning messages
were displayed when I opened the crash dump.
On further inspection, the stack does show a large jump in the childEBP:
kd> dd esp
80473158 0000004e 00000007 00001122 00000001
80473168 00000000 818ecb30 8124f288 804373d6
80473178 8124f288 81126a68 804731ac 00000000
80473188 00100000 8041f922 8124f202 811bf428
80473198 8185236c 81126a68 804731c0 00000000
804731a8 0085236c 804731c0 bff6c57a 8046efa0
804731b8 8046f230 ffdff000 ffdff800 80463ee5
804731c8 81852428 008520e0 811bf428 818524e8
Location 80473174 contains the return address to nt!MmUnlockPages+0x10f so
the child EBP is 8124f288 (assuming the stack is correct, and assuming I
know what I’m doing!). Any ideas what the value 818ecb30 at location
8047316c is? The remaining five dwords are the params to KeBugCheckEx()
so they’re good. But, the values at 8047316c and 80473170 seem odd.
I walked the stack by hand (as you suggested) and got similar results to
the “kv” option (see below). I got a few references to
nt!KiDoubleFaultStack() but they didn’t initiate from “calls” so I assume
I can just ignore them.
kd> ln 804373d6
(804372c5) nt!MmUnlockPages+0x10f | (8043b6ed)
nt!MiGetPageForHeader
kd> ln 804731ac
(80470480) nt!KiDoubleFaultStack+0x2d2c | (80473e38)
nt!MmHiberPages
kd> ln 8041f922
(8041f72c) nt!IopfCompleteRequest+0x1e9 | (80420c95)
nt!IoReleaseVpbSpinLock
kd> ln 804731c0
(80470480) nt!KiDoubleFaultStack+0x2d40 | (80473e38)
nt!MmHiberPages
kd> ln 80463ee5
(80463eb4) nt!KiRetireDpcList+0x31 | (804022d0)
nt!KeInitializeSpinLock
kd> ln 80463e7f
(80463e59) nt!KiIdleLoop+0x26 | (804022d0) nt!KeInitializeSpinLock
> This stack looks pretty bogus - I find it hard to believe that you have
a
> 13MB call frame (the jump from the ChildEBP address in
IopfCompleteRequest
> to the address in MmUnlockPages.)
>
> What version of the debugger are you using? Do you get any warning
messages
> out of it? What version of the OS? If you are using W2K or NT 4.0, try
> using “!kdex2x86.stack” - this will walk through the entire thread
stack
> and look for anything that MIGHT be a call frame (then again, it might
be
> garbage as well, so use this call with care.)
>
> Check the limits of the stack as well (!thread). You may have to walk
the
> stack manually to reconstruct the call chain (use the “kv” command with
the
> optional arguments - EBP EIP and ESP. I usually do this by identifying
a
> frame boundary and then feeding the results from that (eip = the call
> instruction, ebp = the value pushed on the stack after the call usually,
esp
> = the stack address at the time of the call, so the memory location
where
> the return address (just after eip) came from.)
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Hope to see you at the next OSR file systems class in San Jose, CA
September
> 16, 2002!
>
> -----Original Message-----
> From: xxxxx@charter.net [mailto:xxxxx@charter.net]
> Sent: Wednesday, September 04, 2002 11:52 AM
> To: Kernel Debugging Interest List
> Subject: [windbg] Deciphering a PFN_LIST_CORRUPT bugcheck
>
> I have a memory dump showing a 0x4e fault (PFN_LIST_CORRUPT, attempt to
> unlock an unlocked page) with the following stack:
>
> STACK_TEXT:
> 80473170 804373d6 8124f288 81126a68 804731ac
> nt!MiDecrementReferenceCount+0xbf
> 80473188 8041f922 8124f202 811bf428 8185236c nt!MmUnlockPages+0x10f
> 81126a68 8124f288 00000070 8186a668 81121c4c
nt!IopfCompleteRequest+0x1e9
> 00b80006 00000000 00000000 00000000 00000000 0x8124f288
>
> How can I find out who called IopfCompleteRequest()? (does this odd
stack
> simply show memory corruption?)
>
> Thanks.
>
> —
> You are currently subscribed to windbg as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to windbg as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to windbg as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%