Bartjan,
I don’t know for sure, but I suspect your symbols are not set up properly.
I say this because the bug check you give (0xc2 - BAD_POOL_CALLER) would
indicate a bug in ExFreePoolWithTag. Here’s the disassembly:
ntkrnlmp!ExFreePoolWithTag+193:
80168b63 53 push ebx
80168b64 56 push esi
80168b65 68680b0000 push 0xb68
80168b6a 6a07 push 0x7
80168b6c 68c2000000 push 0xc2
80168b71 e81217fcff call ntkrnlmp!KeBugCheckEx (8012a288)
(The whole point here is that the first parameter of the bug check - 0x7, is
unique to this particular call to KeBugCheckEx, which is why we know this is
where it is coming from.)
The ESI register is supposed to contain the pointer to the pool block, and
the EBX register is the original pool block passed in to the function (you
can walk backwards through the disassembly to confirm this. That is, as
they say, left as an exercise to the reader.)
This would suggest your stack trace is screwed up in some way - and what you
have is pool corruption. The other hint here is the condition it uses to
skip (or run) this block of code:
80168b5d f6460180 test byte ptr [esi+0x1],0x80
80168b61 7513 jnz ntkrnlmp!ExFreePoolWithTag+0x1a6
(80168b76)
Now, having spent lots of time wandering through crash dumps, I’ve become
pretty decent at decoding the “flags” from a pool block (essentially, a pool
block has a two DWORD header - the first DWORD are various flags/size
information, the second DWORD is the tag. If the pool block is FREE the
next two DWORDS are the flink/blink pointer from the free list. If the pool
block is ALLOCATED the next two DWORDS are part of the data region.) This
bit (the one being tested) corresponds to a block being “free” or a block
being “allocated”. The first DWORD is also used for other attributes (e.g.,
protected, the size of the current block, and the size of the previous
block.)
Thus, this suggests that you (or someone) is freeing a block of memory which
has already been freed. One thing to do is use the “!pool” command on either
of the last two parameters (it should resolve to the same pool block) and
check the tag - that will give you a hint as to the actual data structure
and confirm if it is freed or allocated (again, I suspect you will find it
has already been freed.) Knowing which data structure it is will likely give
you a better mechanism for finding and fixing this problem.
I hope this helps.
Regards,
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Bartjan Wattel [mailto:xxxxx@zeelandnet.nl]
Sent: Friday, April 13, 2001 3:05 AM
To: File Systems Developers
Subject: [ntfsd] Re: Stack corruption ?
I guess I had to include more information. Sorry about that.
I’m working on a file filter driver. This happened on W2K, no service pack
installed. I run Driver Verifier. In fact, DV caught this guy. The error
was found during are home-baked filter test when we executed Word97 about
20 times using an auto-start macro.
I am worried about the two lower lines in the stack trace:
fc76cd64 5d5d5d5d 5d5d5d5d 5d5d5d5d 5d5d5d5d
ntoskrnl!MmFlushImageSection+0x1ab
5d5d5d5d 00000000 00000000 00000000 00000000 0x5d5d5d5d
We are now trying to reproduce this on a W2K/SP1 system. This seems more
stable though.
If someone can spare the time, I would appreciate any help on this.
–
Bartjan.
At 10:08 AM 4/12/2001 +0200, you wrote:
What’s happening here ? Am I facing a stack corruption ? How do I debug
this to trace the error in my driver ?
*** Fatal System Error: 0x000000c2
(0x00000007,0x00000B68,0xE134D300,0xE134D308)
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
eax=00000003 ebx=000000c2 ecx=fc76cd40 edx=00000000 esi=00000007
edi=fc76c590
eip=80452e70 esp=fc76c54c ebp=fc76c578 iopl=0 nv up ei pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00000246
ntoskrnl!MmLockPagableSectionByHandle+5a:
80452e70 cc int 3
ChildEBP RetAddr Args to Child
fc76c578 8042c068 00000003 814d6008 e134d300
ntoskrnl!MmLockPagableSectionByHandle+0x5a
fc76c900 804674c6 00000000 00000007 00000b68
ntoskrnl!IopWriteSummaryHeader+0x67
fc76c93c 8049dfd4 e134d308 e24e4d43 e21b52a8
ntoskrnl!MmOutSwapProcess+0x564
fc76cb48 8044e27e e1488008 814ad701 fc76cbf4 ntoskrnl!DbgPrint+0xc8
fc76cbb4 804957ae 00000000 fc76cc00 00000040
ntoskrnl!MiEmptyWorkingSet+0x9e
fc76ccc4 804aa608 00000000 814ad7c0 e2277a01
ntoskrnl!NtWaitForMultipleObjects+0x266
fc76cd50 80461691 0012d7f8 02000000 0012d3d0
ntoskrnl!PnPBiosCollectLegacyDeviceResources+0x1a
fc76cd64 5d5d5d5d 5d5d5d5d 5d5d5d5d 5d5d5d5d
ntoskrnl!MmFlushImageSection+0x1ab
5d5d5d5d 00000000 00000000 00000000 00000000 0x5d5d5d5d
Bugcheck code 000000C2
Arguments 00000007 00000b68 e134d300 e134d308
ntoskrnl!MmLockPagableSectionByHandle+5a:
80452e70 cc int 3
kd> !pool E134D300
Block E134D300 is a corrupted special pool allocation
–
Bartjan Wattel.
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com