C9 bugcheck....

NTFSD
1

I am getting a bugcheck during cleanup processing. It occurs when I
issue the following call:

CcUninitializeCacheMap(pFileObject, NULL,
&cacheUninitializeEvent);

Here is the analyze -v. The pFileObject looks fine,
SectionObjectPointer looks fine, cacheUninitializeEvent looks fine.

************************************************************************
*******
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
*******

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 0000000c, Invalid IOSB in IRP at APC IopCompleteRequest (appears
to be on
stack that was unwound)
Arg2: ba22b860, IOSB address
Arg3: 00000000, IRP address
Arg4: 00000000, 0

Debugging Details:

BUGCHECK_STR: 0xc9_c

DRIVER_VERIFIER_IO_VIOLATION_TYPE: c

IOSB_ADDRESS: ffffffffba22b860

IRP_ADDRESS: 82cf2e70

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: notepad.exe

CURRENT_IRQL: 1

DEVICE_OBJECT: 8288d9c0

DRIVER_OBJECT: 82816e10

IMAGE_NAME: disk.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 45d69bb7

MODULE_NAME: disk

FAULTING_MODULE: f74d7000 disk

LAST_CONTROL_TRANSFER: from 80826967 to 80871f20

STACK_TEXT:
ba22b584 80826967 00000003 00000000 00000000
nt!RtlpBreakWithStatusInstruction
ba22b5d0 8082786b 00000003 824f4450 82269b18
nt!KiBugCheckDebugBreak+0x19
ba22b968 80827c63 000000c9 0000000c ba22b860 nt!KeBugCheck2+0x5e1
ba22b988 809b56da 000000c9 0000000c ba22b860 nt!KeBugCheckEx+0x1b
ba22b9a4 808215b6 82cf2eb0 ba22ba40 ba22ba44 nt!IovpCompleteRequest+0x4e
ba22b9fc 8082dfc3 82cf2eb0 ba22ba48 ba22ba3c nt!IopCompleteRequest+0x3a
ba22ba4c 80a5c199 00000000 00000000 ba22baa4 nt!KiDeliverApc+0xbb
ba22ba6c 80a5c3d9 ffdffa01 ba22baa4 ba22baa4
hal!HalpDispatchSoftwareInterrupt+0x49
ba22ba88 80a5c577 82843c2c ba22baa4 8088d89d
hal!HalpCheckForSoftwareInterrupt+0x81
ba22ba94 8088d89d e123f100 000001a3 ba22bb20
hal!HalEndSystemInterrupt+0x67
ba22ba94 80a5a4d0 e123f100 000001a3 ba22bb20 nt!KiInterruptDispatch+0x5d
ba22bb14 808439cd 00000000 ba22bb38 80925975 hal!KeAcquireQueuedSpinLock
ba22bb20 80925975 824e9980 00000000 00000000
nt!MiDereferenceControlAreaBySection+0xf
ba22bb38 80933914 824e9980 80a5bf00 e18cde00 nt!MiSectionDelete+0xe7
ba22bb54 8086c955 e18cde18 00000000 824f4344
nt!ObpRemoveObjectRoutine+0xdc
ba22bb74 808108d8 824f46e8 824f42e0 00000000
nt!ObfDereferenceObject+0x67
ba22bba0 80811039 00000000 82677f00 00000012
nt!CcDeleteSharedCacheMap+0xde
ba22bbbc bae9c07d 00000000 00000000 ba22bbd8
nt!CcUninitializeCacheMap+0x12d
ba22bbfc bae94757 824f46e8 c0000001 01ffff00
Xxxxxxxx!XxxCleanupCommonCleanup+0x1ad
ba22bc14 bae4a65c 7d9b7798 837cef48 80a5bf00
Xxxxxxxx!XxxHandleIrpMjCleanup+0x47
ba22bc70 8081df33 808f9732 ba22bcac 808f9732 nt!IovCallDriver+0x112
ba22bc7c 808f9732 824f46d0 8289eca0 824f46e8 nt!IofCallDriver+0x13
ba22bcac 80934bac 825273d8 82677f00 0012019f nt!IopCloseFile+0x2ae
ba22bcdc 809344ad 825273d8 00000001 8289eca0
nt!ObpDecrementHandleCount+0xcc
ba22bd04 80934546 e17bd248 824f46e8 00000750
nt!ObpCloseHandleTableEntry+0x131
ba22bd48 80934663 00000750 00000001 ba22bd64 nt!ObpCloseHandle+0x82
ba22bd58 8088978c 00000750 0007faf8 7c8285ec nt!NtClose+0x1b
ba22bd58 7c8285ec 00000750 0007faf8 7c8285ec nt!KiFastCallEntry+0xfc
0007fae8 7c826d2b 77e63eb3 00000750 0007fb24 ntdll!KiFastSystemCallRet
0007faec 77e63eb3 00000750 0007fb24 01005166 ntdll!ZwClose+0xc
0007faf8 01005166 00000750 00000000 00000000 kernel32!CloseHandle+0x59
0007fb24 01002c4f 000100b2 0100ac00 000ae580 notepad!SaveFile+0x298
0007fda4 01003947 000100b2 00000003 00000000 notepad!NPCommand+0xa8
0007fdc8 7739b6e3 000100b2 00000111 00000003 notepad!NPWndProc+0x4fe
0007fdf4 7739b874 01003449 000100b2 00000111
USER32!InternalCallWinProc+0x28
0007fe6c 7739ba92 00000000 01003449 000100b2
USER32!UserCallWinProcCheckWow+0x151
0007fed4 7739bad0 0007fefc 00000000 0007ff1c
USER32!DispatchMessageWorker+0x327
0007fee4 01002a32 0007fefc 00000000 ffffffff USER32!DispatchMessageW+0xf
0007ff1c 01007527 01000000 00000000 000a2480 notepad!WinMain+0xdc
0007ffc0 77e6f23b 00000000 00000000 7ffd6000
notepad!WinMainCRTStartup+0x182
0007fff0 00000000 010073a5 00000000 78746341
kernel32!BaseProcessStart+0x23art+0x23

2

The problem is not with your call to CcUninitializeCacheMap. Note that the
I/O completion is the result of an APC delivery which interrupted CcUCM.

At some point a driver issued an I/O, specifying a stack based IOSB, and did
not wait for it. When the I/O completed, the stack was unwound.

This is usually a result of misuse of IoBuildXxxRequest(). If you use these
routines and don’t wait, or even if you wait e.g. for your completion
routine, but have APCs disabled, you’ll get this bugcheck when the APC
comes.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@emc.com
Sent: Tuesday, November 20, 2007 1:51 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] C9 bugcheck…

I am getting a bugcheck during cleanup processing. It occurs when I issue
the following call:

CcUninitializeCacheMap(pFileObject, NULL, &cacheUninitializeEvent);

Here is the analyze -v. The pFileObject looks fine, SectionObjectPointer
looks fine, cacheUninitializeEvent looks fine.

************************************************************************
*******
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
*******

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9) The IO manager has caught a
misbehaving driver.
Arguments:
Arg1: 0000000c, Invalid IOSB in IRP at APC IopCompleteRequest (appears to be
on
stack that was unwound)
Arg2: ba22b860, IOSB address
Arg3: 00000000, IRP address
Arg4: 00000000, 0

Debugging Details:

BUGCHECK_STR: 0xc9_c

DRIVER_VERIFIER_IO_VIOLATION_TYPE: c

IOSB_ADDRESS: ffffffffba22b860

IRP_ADDRESS: 82cf2e70

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: notepad.exe

CURRENT_IRQL: 1

DEVICE_OBJECT: 8288d9c0

DRIVER_OBJECT: 82816e10

IMAGE_NAME: disk.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 45d69bb7

MODULE_NAME: disk

FAULTING_MODULE: f74d7000 disk

LAST_CONTROL_TRANSFER: from 80826967 to 80871f20

STACK_TEXT:
ba22b584 80826967 00000003 00000000 00000000
nt!RtlpBreakWithStatusInstruction ba22b5d0 8082786b 00000003 824f4450
82269b18
nt!KiBugCheckDebugBreak+0x19
ba22b968 80827c63 000000c9 0000000c ba22b860 nt!KeBugCheck2+0x5e1
ba22b988 809b56da 000000c9 0000000c ba22b860 nt!KeBugCheckEx+0x1b
ba22b9a4 808215b6 82cf2eb0 ba22ba40 ba22ba44 nt!IovpCompleteRequest+0x4e
ba22b9fc 8082dfc3 82cf2eb0 ba22ba48 ba22ba3c nt!IopCompleteRequest+0x3a
ba22ba4c 80a5c199 00000000 00000000 ba22baa4 nt!KiDeliverApc+0xbb ba22ba6c
80a5c3d9 ffdffa01 ba22baa4 ba22baa4
hal!HalpDispatchSoftwareInterrupt+0x49
ba22ba88 80a5c577 82843c2c ba22baa4 8088d89d
hal!HalpCheckForSoftwareInterrupt+0x81
ba22ba94 8088d89d e123f100 000001a3 ba22bb20
hal!HalEndSystemInterrupt+0x67
ba22ba94 80a5a4d0 e123f100 000001a3 ba22bb20 nt!KiInterruptDispatch+0x5d
ba22bb14 808439cd 00000000 ba22bb38 80925975 hal!KeAcquireQueuedSpinLock
ba22bb20 80925975 824e9980 00000000 00000000
nt!MiDereferenceControlAreaBySection+0xf
ba22bb38 80933914 824e9980 80a5bf00 e18cde00 nt!MiSectionDelete+0xe7
ba22bb54 8086c955 e18cde18 00000000 824f4344 nt!ObpRemoveObjectRoutine+0xdc
ba22bb74 808108d8 824f46e8 824f42e0 00000000
nt!ObfDereferenceObject+0x67
ba22bba0 80811039 00000000 82677f00 00000012 nt!CcDeleteSharedCacheMap+0xde
ba22bbbc bae9c07d 00000000 00000000 ba22bbd8 nt!CcUninitializeCacheMap+0x12d
ba22bbfc bae94757 824f46e8 c0000001 01ffff00
Xxxxxxxx!XxxCleanupCommonCleanup+0x1ad
ba22bc14 bae4a65c 7d9b7798 837cef48 80a5bf00
Xxxxxxxx!XxxHandleIrpMjCleanup+0x47
ba22bc70 8081df33 808f9732 ba22bcac 808f9732 nt!IovCallDriver+0x112 ba22bc7c
808f9732 824f46d0 8289eca0 824f46e8 nt!IofCallDriver+0x13 ba22bcac 80934bac
825273d8 82677f00 0012019f nt!IopCloseFile+0x2ae ba22bcdc 809344ad 825273d8
00000001 8289eca0 nt!ObpDecrementHandleCount+0xcc
ba22bd04 80934546 e17bd248 824f46e8 00000750
nt!ObpCloseHandleTableEntry+0x131
ba22bd48 80934663 00000750 00000001 ba22bd64 nt!ObpCloseHandle+0x82
ba22bd58 8088978c 00000750 0007faf8 7c8285ec nt!NtClose+0x1b
ba22bd58 7c8285ec 00000750 0007faf8 7c8285ec nt!KiFastCallEntry+0xfc
0007fae8 7c826d2b 77e63eb3 00000750 0007fb24 ntdll!KiFastSystemCallRet
0007faec 77e63eb3 00000750 0007fb24 01005166 ntdll!ZwClose+0xc
0007faf8 01005166 00000750 00000000 00000000 kernel32!CloseHandle+0x59
0007fb24 01002c4f 000100b2 0100ac00 000ae580 notepad!SaveFile+0x298
0007fda4 01003947 000100b2 00000003 00000000 notepad!NPCommand+0xa8
0007fdc8 7739b6e3 000100b2 00000111 00000003 notepad!NPWndProc+0x4fe
0007fdf4 7739b874 01003449 000100b2 00000111
USER32!InternalCallWinProc+0x28
0007fe6c 7739ba92 00000000 01003449 000100b2
USER32!UserCallWinProcCheckWow+0x151
0007fed4 7739bad0 0007fefc 00000000 0007ff1c
USER32!DispatchMessageWorker+0x327
0007fee4 01002a32 0007fefc 00000000 ffffffff USER32!DispatchMessageW+0xf
0007ff1c 01007527 01000000 00000000 000a2480 notepad!WinMain+0xdc 0007ffc0
77e6f23b 00000000 00000000 7ffd6000
notepad!WinMainCRTStartup+0x182
0007fff0 00000000 010073a5 00000000 78746341
kernel32!BaseProcessStart+0x23art+0x23

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new fs
mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Dan beat me to it, but I was going to suggest that you do a !thread on the file object in question. That will search all the threads and find the one for which that address is on the stack.

Stack based file objects create nasty problems like this, but they are a fact of life. Bottom line - if you plan on using the file object for I/O and you are in a create path, don’t trust the file object. That means either create your own or use non-cached I/O.

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

4

Hi Tony,

You’ve confused me.

I agree that FOs on the stack are bad, bad, bad, I don’t see the relevance
here. The stack address in question in the crash is an IO_STATUS_BLOCK, and
it clearly belongs to the current thread.

Am I missing something?

Thanks,

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, November 20, 2007 5:05 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] C9 bugcheck…

Dan beat me to it, but I was going to suggest that you do a !thread on the
file object in question. That will search all the threads and find the one
for which that address is on the stack.

Stack based file objects create nasty problems like this, but they are a
fact of life. Bottom line - if you plan on using the file object for I/O
and you are in a create path, don’t trust the file object. That means
either create your own or use non-cached I/O.

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new fs
mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@privtek.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

5

That’ll teach me to quick read these questions anymore. I’d presumed it was the FO on the stack, not the status block. Different problem.

I shall now go back and continue learning more about the subtle joy and nuances of file system filters in Windows Vista…

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com