The strangest problem (BSOD 0xCC)

NTFSD
1

Hi,

I’m facing the strangest problem here… On a Windows 2000 Professional
(SP1) machine, the driver verifier catches a 0xCC bugcheck in our driver
(PAGE_FAULT_IN_FREED_SPECIAL_POOL), with the following arguments:

Arg1: bbbbbbc7, memory referenced
Arg2: 00000000, value 0 = read operation, 1 = write operation
Arg3: 80116556, if non-zero, the address which referenced memory.
Arg4: 00000000, Mm internal code.

The debugger says:

Fault occurred in driver ntoskrnl.exe ( nt!ExAcquireResourceExclusiveLite+0xd )
80116556 6683790c00 cmp word ptr [ecx+0xc],0x0

Now, the strack trace is as follows (for some reason, WinDbg 4.0 cannot
find/load the debugging symbols for our driver):

ChildEBP RetAddr
f143f5a4 8012bdfd nt!RtlpBreakWithStatusInstruction
f143f5d4 8012c1c1 nt!KiBugCheckDebugBreak+0x31
f143f960 80147cc5 nt!KeBugCheckEx+0x390
f143f9a8 80165fc6 nt!MmAccessFault+0x74e
f143f9a8 80116556 nt!KiTrap0E+0xc3
f143fa34 802328cb nt!ExAcquireResourceExclusiveLite+0xd
f143fa44 f039ae45 nt!VerifierExAcquireResourceExclusive+0x66
f143fa9c f039fede ThTrac2k+0x7e45
f143fac8 f03a5409 ThTrac2k+0xcede
f143fc5c f03a5515 ThTrac2k+0x12409
f143fc6c 8011f511 ThTrac2k+0x12515
f143fc80 8022cf9b nt!IopfCallDriver+0x35
f143fc9c bfea08d9 nt!IovCallDriver+0x77
f143fcc4 bfe9fe0d Mup!DnrRedirectFileOpen+0x1f1
f143fd3c bfea5b70 Mup!DnrNameResolve+0x5bf
f143fd78 80118b41 Mup!DfsFspDispatch+0x9e
f143fda8 8015336a nt!ExpWorkerThread+0xae
f143fddc 801671c2 nt!PspSystemThreadStartup+0x69
00000000 00000000 nt!KiThreadStartup+0x16

So the strangest thing is, that the strack traces for our driver (ThTrac2k)
do not correspond to any entry points of function calls in our driver at
all. For example, the code at ThTrack2K+0x7e45 is:

; 817 : {
; 818 : pFCB = (PFSRTL_COMMON_FCB_HEADER)FileObject->FsContext;

07E44 8b 77 0c mov esi, DWORD PTR [edi+12]
07E47 89 75 e4 mov DWORD PTR _pFCB$[ebp], esi

; 819 : if ( pFCB != NULL )

07E4A 3b f3 cmp esi, ebx
07E4C 74 3a je SHORT $L11517

; 820 : {
; 821 : if ( pFCB->Resource != NULL )

07E4E 39 5e 08 cmp DWORD PTR [esi+8], ebx
07E51 74 35 je SHORT $L11517

Do you guys have any clue what could cause this problem ? Any hints or tips
to track down and pinpoint the problem ? I would appreciate any help!

Thanks,

Bartjan Wattel.

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

2

Bartjan,

My best guess for the symbols not loading is that the driver you have running isn’t the driver you think you have running… in that case windbag won’t load the symbols because they don’t match. This would also explain why the code at ThTrac2k+0x7e45 doesn’t make sense. Disassemble it with windbag, and see if it has a call there - you may be running an older version of your binary by mistake.

Failing that, you’re down to adding trace points into your driver at various points from the last sane stack location. It could be you have a wild pointer that is scribbling onto the stack and corrupting it.

Andy.

FREE Personalized E-mail at Mail.com

http://www.mail.com/?sr=signup

Talk More, Pay Less with Net2Phone Direct(R), up to 1500 minutes free!

http://www.net2phone.com/cgi-bin/link.cgi?143

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

3

Andy guess is probably correct.

In addition remember that once you hit bad symbols the stack is not
guaranteed to be accurate after that point.

Make sure you are using the 4.0.11 debugger from
http://www.microsoft.com/ddk/debugging

Troubleshoot your symbols with “!sym noisy”

-----Original Message-----
From: Andy Champ [mailto:xxxxx@earthling.net]
Sent: Tuesday, October 23, 2001 1:57 AM
To: File Systems Developers
Subject: [ntfsd] RE: The strangest problem (BSOD 0xCC)

Bartjan,

My best guess for the symbols not loading is that the driver you have
running isn’t the driver you think you have running… in that case
windbag won’t load the symbols because they don’t match. This would
also explain why the code at ThTrac2k+0x7e45 doesn’t make sense.
Disassemble it with windbag, and see if it has a call there - you may be
running an older version of your binary by mistake.

Failing that, you’re down to adding trace points into your driver at
various points from the last sane stack location. It could be you have
a wild pointer that is scribbling onto the stack and corrupting it.

Andy.

FREE Personalized E-mail at Mail.com

http://www.mail.com/?sr=signup

Talk More, Pay Less with Net2Phone Direct(R), up to 1500 minutes free!

http://www.net2phone.com/cgi-bin/link.cgi?143

You are currently subscribed to ntfsd as: xxxxx@microsoft.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

4

Looks like pool corruption - some code is writing to the memory which is already free.

This can be - in a primitive case - due to buggy pointer manipulation or - in complex case - by freeing some entity which is referenced not only by your code, but by the kernel too. In this case, the kernel corrupts the pool writing to the entity which you have freed.
The second is usually a reference counting bug, and is EXTREMELY hard to find.

It would be great to have a “pool consistency checker” tool in WinDbg, which will scan the whole pool and check the free/busy blocks headers and lists.

Max
----- Original Message -----
From: Bartjan Wattel
To: File Systems Developers
Sent: Tuesday, October 23, 2001 12:45 PM
Subject: [ntfsd] The strangest problem (BSOD 0xCC)

Hi,

I’m facing the strangest problem here… On a Windows 2000 Professional (SP1) machine, the driver verifier catches a 0xCC bugcheck in our driver (PAGE_FAULT_IN_FREED_SPECIAL_POOL), with the following arguments:

Arg1: bbbbbbc7, memory referenced
Arg2: 00000000, value 0 = read operation, 1 = write operation
Arg3: 80116556, if non-zero, the address which referenced memory.
Arg4: 00000000, Mm internal code.

The debugger says:

Fault occurred in driver ntoskrnl.exe ( nt!ExAcquireResourceExclusiveLite+0xd )
80116556 6683790c00 cmp word ptr [ecx+0xc],0x0

Now, the strack trace is as follows (for some reason, WinDbg 4.0 cannot find/load the debugging symbols for our driver):

ChildEBP RetAddr
f143f5a4 8012bdfd nt!RtlpBreakWithStatusInstruction
f143f5d4 8012c1c1 nt!KiBugCheckDebugBreak+0x31
f143f960 80147cc5 nt!KeBugCheckEx+0x390
f143f9a8 80165fc6 nt!MmAccessFault+0x74e
f143f9a8 80116556 nt!KiTrap0E+0xc3
f143fa34 802328cb nt!ExAcquireResourceExclusiveLite+0xd
f143fa44 f039ae45 nt!VerifierExAcquireResourceExclusive+0x66
f143fa9c f039fede ThTrac2k+0x7e45
f143fac8 f03a5409 ThTrac2k+0xcede
f143fc5c f03a5515 ThTrac2k+0x12409
f143fc6c 8011f511 ThTrac2k+0x12515
f143fc80 8022cf9b nt!IopfCallDriver+0x35
f143fc9c bfea08d9 nt!IovCallDriver+0x77
f143fcc4 bfe9fe0d Mup!DnrRedirectFileOpen+0x1f1
f143fd3c bfea5b70 Mup!DnrNameResolve+0x5bf
f143fd78 80118b41 Mup!DfsFspDispatch+0x9e
f143fda8 8015336a nt!ExpWorkerThread+0xae
f143fddc 801671c2 nt!PspSystemThreadStartup+0x69
00000000 00000000 nt!KiThreadStartup+0x16

So the strangest thing is, that the strack traces for our driver (ThTrac2k) do not correspond to any entry points of function calls in our driver at all. For example, the code at ThTrack2K+0x7e45 is:

; 817 : {
; 818 : pFCB = (PFSRTL_COMMON_FCB_HEADER)FileObject->FsContext;

07E44 8b 77 0c mov esi, DWORD PTR [edi+12]
07E47 89 75 e4 mov DWORD PTR _pFCB$[ebp], esi

; 819 : if ( pFCB != NULL )

07E4A 3b f3 cmp esi, ebx
07E4C 74 3a je SHORT $L11517

; 820 : {
; 821 : if ( pFCB->Resource != NULL )

07E4E 39 5e 08 cmp DWORD PTR [esi+8], ebx
07E51 74 35 je SHORT $L11517

Do you guys have any clue what could cause this problem ? Any hints or tips to track down and pinpoint the problem ? I would appreciate any help!

Thanks,

Bartjan Wattel.

You are currently subscribed to ntfsd as: xxxxx@storagecraft.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