DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9) 224

[OSR_Community_User]

Hi,

Recently, driver verifier starts to trigger an interesting violation in
our driver. The dump is listed below. I looked at the address, and it
appears to be our dispatch routine.

I have three questions regarding how to identify the root cause of this
problem.

1. I am unable to find the IRP, IRP’s status, and returned status as
   indicated in the message (I only have the crash dump files).

2. I went through the code and could not find out where the indicated
   problem can occur: i.e., all our return paths have matching status code.

3. Lastly, the address of the IRP routine given in the dump points to
   the first line of our main dispatch routine, which in turn calls one of
   three sub dispatch routines (one for network, one for file system, and
   one for our internal device control). Right now, it appears that this
   problem is pointing at the network dispatch routine (tdi), but I am not
   100% sure.

Since I can’t find any other posts with similar error, I am wondering
what I can do to resolve this problem.

Thanks,

Hao

************************************************************************
*******

*
*

* Bugcheck Analysis
*

*
*

************************************************************************
*******

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)

The IO manager has caught a misbehaving driver.

Arguments:

Arg1: 00000224, (Fatal error) An IRP dispatch handler has returned a
status that is inconsistent

with the IRP’s IoStatus.Status field. (Dispatch handler routine,
IRP, IRP’s

IoStatus.Status, and returned Status specified.)

Arg2: f495d6d8

Arg3: 00000000

Arg4: 00000000

Debugging Details:

---

Unable to load image NSKernel.sys, Win32 error 0n2

*** ERROR: Module load completed but symbols could not be loaded for
NSKernel.sys

ERROR_CODE: (NTSTATUS) 0xc9 - The operating system cannot run %1.

BUGCHECK_STR: 0xc9_224

DRIVER_VERIFIER_IO_VIOLATION_TYPE: 224

FAULTING_IP:

NSKernel+6d8

f495d6d8 8bff mov edi,edi

FOLLOWUP_IP:

NSKernel+6d8

f495d6d8 8bff mov edi,edi

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from 8067c258 to 8053738a

STACK_TEXT:

b9dca07c 8067c258 0000004c 000000c9 b9dca09c nt!KeBugCheckEx+0x1b

b9dca204 8067ca24 b9dca4f0 806a8077 00040000 nt!ViBugcheckHalt+0xc3

b9dca4a8 8067cb10 806ac630 00000224 b9dca4d4
nt!VfBugcheckThrowException+0xa1

b9dca598 8067f476 00000224 00002041 f495d6d8
nt!VfBugcheckThrowIoException+0xb5

b9dca5d4 80672155 00a6cf70 91c0ef58 91c0ef48 nt!IovpCallDriver2+0x292

b9dca5fc 8057cc89 85d65158 859dce04 b9dca794 nt!IovCallDriver+0xb0

b9dca6dc 8056c063 85d65170 00000000 859dcd60 nt!IopParseDevice+0xa12

b9dca754 8056f2a8 00000000 b9dca794 00000040
nt!ObpLookupObjectName+0x53c

b9dca7a8 8057d2e2 00000000 00000000 c0003c00 nt!ObOpenObjectByName+0xea

b9dca824 8057d3b1 b9dca9ec c0100000 b9dca9ac nt!IopCreateFile+0x407

b9dca880 8057d3f4 b9dca9ec c0100000 b9dca9ac nt!IoCreateFile+0x8e

b9dca8c0 804dd99f b9dca9ec c0100000 b9dca9ac nt!NtCreateFile+0x30

b9dca8c0 804e3577 b9dca9ec c0100000 b9dca9ac nt!KiFastCallEntry+0xfc

b9dca964 f4951bbc b9dca9ec c0100000 b9dca9ac nt!ZwCreateFile+0x11

b9dcaa10 f493ad6f 85a02fc4 b9dcaa40 85a02fbc
netbt!NbtTdiOpenAddress+0x227

b9dcaa44 f493a244 00000000 85897b58 85897b68
netbt!NbtOpenAndAssocConnection+0xe1

b9dcaaa8 f493a3d3 02dcaae8 f48f1ad0 028cc690
netbt!NbtConnectCommon+0x47a

b9dcaac4 f493ab56 b9dcaae8 f48f1ad0 858cc690 netbt!NbtConnect+0xb1

b9dcab14 f4936cf9 85d9b7f8 920c8f20 858cc600 netbt!NTConnect+0x119

b9dcab30 804e13d9 e0d9b7f8 920c8fd8 806ff428
netbt!NbtDispatchInternalCtrl+0x101

b9dcab40 80672145 858cc6a8 00000000 858cc680 nt!IopfCallDriver+0x31

b9dcab64 f4951f33 00000000 858cc680 920c8f20 nt!IovCallDriver+0xa0

b9dcab7c f493abc5 00000000 920c8f20 00000000
netbt!DelayedNbtProcessConnect+0xfc

b9dcabcc f4936cf9 85d9b7f8 92302f20 00000000 netbt!NTConnect+0xbc

b9dcabe8 804e13d9 e0d9b7f8 92302fd8 806ff428
netbt!NbtDispatchInternalCtrl+0x101

b9dcabf8 80672145 92302f20 b9dcac30 00000000 nt!IopfCallDriver+0x31

b9dcac1c f48e9867 85d6c6b4 92302f20 00000000 nt!IovCallDriver+0xa0

b9dcac44 f48ebb91 85d9b7f8 92302f20 00000000
rdbss!RxCeSubmitTdiRequest+0x4b

b9dcac8c f48fd8c2 00000000 85d6c6dc 858d1894 rdbss!RxTdiConnect+0x154

b9dcacd4 f48fd9b6 858d18cc 858d1894 85d6c6a8 rdbss!RxCeBuildVC+0x59

b9dcad10 f48b35ff 85d6c6dc 85a09078 f4898360
rdbss!RxCeBuildConnection+0x4d

b9dcad50 f487ed7c 85d6aef0 85d79c00 f48f1ec0
mrxsmb!VctInstantiateServerTransport+0x18a

b9dcad6c f48e84b1 85d6aef0 00000000 85c39020
mrxsmb!SmbCeConstructServerTransport+0xc6

b9dcad9c f48f2845 008f1ec0 f48f2140 b9dcaddc
rdbss!RxpWorkerThreadDispatcher+0x93

b9dcadac 80574128 f48f1ec0 00000000 00000000
rdbss!RxWorkerThreadDispatcher+0x1a

b9dcaddc 804ec781 f48f282b f48f1ec0 00000000
nt!PspSystemThreadStartup+0x34

00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: .bugcheck ; kb

SYMBOL_NAME: NSKernel+6d8

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: NSKernel

IMAGE_NAME: NSKernel.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 48935687

FAILURE_BUCKET_ID: 0xc9_224_NSKernel+6d8

BUCKET_ID: 0xc9_224_NSKernel+6d8

Followup: MachineOwner

[Scott_Noone_OSR]

Odd that it’s not showing the other info.

It should be relatively straightforward to find the offending IRP in this
case. The caller used ZwCreateFile to send the create, and that routine
creates an IRP that is queued to the current thread. Because it hasn’t
really completed yet, I’d expect to find that IRP still on the thread’s IRP
list.

Just do a !thread and you should find it in the output (an example from my
VM):

kd> !thread
THREAD 85b55da0 Cid 3ac.344 Teb: 7ffdb000 Win32Thread: e1c2fde8 RUNNING
IRP List:
85b314e8: (0006,016c) Flags: 00000884 Mdl: 00000000

Finding the IRP should at least allow you to inspect the I/O status block
and see the code in it, which might lead you in the right direction (you
could also find the IOSB on the stack from the ZwCreateFile call, it should
be at b9dca964+14).

HTH,

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Hao Wang” wrote in message news:xxxxx@ntdev…
Hi,

Recently, driver verifier starts to trigger an interesting violation in our
driver. The dump is listed below. I looked at the address, and it appears to
be our dispatch routine.

I have three questions regarding how to identify the root cause of this
problem.

1. I am unable to find the IRP, IRP’s status, and returned status as
indicated in the message (I only have the crash dump files).

2. I went through the code and could not find out where the indicated
problem can occur: i.e., all our return paths have matching status code.

3. Lastly, the address of the IRP routine given in the dump points to the
first line of our main dispatch routine, which in turn calls one of three
sub dispatch routines (one for network, one for file system, and one for our
internal device control). Right now, it appears that this problem is
pointing at the network dispatch routine (tdi), but I am not 100% sure.

Since I can’t find any other posts with similar error, I am wondering what I
can do to resolve this problem.

Thanks,
Hao




Bugcheck Analysis



******

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 00000224, (Fatal error) An IRP dispatch handler has returned a status
that is inconsistent
with the IRP’s IoStatus.Status field. (Dispatch handler routine, IRP,
IRP’s
IoStatus.Status, and returned Status specified.)
Arg2: f495d6d8
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------

Unable to load image NSKernel.sys, Win32 error 0n2
*** ERROR: Module load completed but symbols could not be loaded for
NSKernel.sys

ERROR_CODE: (NTSTATUS) 0xc9 - The operating system cannot run %1.

BUGCHECK_STR: 0xc9_224

DRIVER_VERIFIER_IO_VIOLATION_TYPE: 224

FAULTING_IP:
NSKernel+6d8
f495d6d8 8bff mov edi,edi

FOLLOWUP_IP:
NSKernel+6d8
f495d6d8 8bff mov edi,edi

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from 8067c258 to 8053738a

STACK_TEXT:
b9dca07c 8067c258 0000004c 000000c9 b9dca09c nt!KeBugCheckEx+0x1b
b9dca204 8067ca24 b9dca4f0 806a8077 00040000 nt!ViBugcheckHalt+0xc3
b9dca4a8 8067cb10 806ac630 00000224 b9dca4d4
nt!VfBugcheckThrowException+0xa1
b9dca598 8067f476 00000224 00002041 f495d6d8
nt!VfBugcheckThrowIoException+0xb5
b9dca5d4 80672155 00a6cf70 91c0ef58 91c0ef48 nt!IovpCallDriver2+0x292
b9dca5fc 8057cc89 85d65158 859dce04 b9dca794 nt!IovCallDriver+0xb0
b9dca6dc 8056c063 85d65170 00000000 859dcd60 nt!IopParseDevice+0xa12
b9dca754 8056f2a8 00000000 b9dca794 00000040 nt!ObpLookupObjectName+0x53c
b9dca7a8 8057d2e2 00000000 00000000 c0003c00 nt!ObOpenObjectByName+0xea
b9dca824 8057d3b1 b9dca9ec c0100000 b9dca9ac nt!IopCreateFile+0x407
b9dca880 8057d3f4 b9dca9ec c0100000 b9dca9ac nt!IoCreateFile+0x8e
b9dca8c0 804dd99f b9dca9ec c0100000 b9dca9ac nt!NtCreateFile+0x30
b9dca8c0 804e3577 b9dca9ec c0100000 b9dca9ac nt!KiFastCallEntry+0xfc
b9dca964 f4951bbc b9dca9ec c0100000 b9dca9ac nt!ZwCreateFile+0x11
b9dcaa10 f493ad6f 85a02fc4 b9dcaa40 85a02fbc netbt!NbtTdiOpenAddress+0x227
b9dcaa44 f493a244 00000000 85897b58 85897b68
netbt!NbtOpenAndAssocConnection+0xe1
b9dcaaa8 f493a3d3 02dcaae8 f48f1ad0 028cc690 netbt!NbtConnectCommon+0x47a
b9dcaac4 f493ab56 b9dcaae8 f48f1ad0 858cc690 netbt!NbtConnect+0xb1
b9dcab14 f4936cf9 85d9b7f8 920c8f20 858cc600 netbt!NTConnect+0x119
b9dcab30 804e13d9 e0d9b7f8 920c8fd8 806ff428
netbt!NbtDispatchInternalCtrl+0x101
b9dcab40 80672145 858cc6a8 00000000 858cc680 nt!IopfCallDriver+0x31
b9dcab64 f4951f33 00000000 858cc680 920c8f20 nt!IovCallDriver+0xa0
b9dcab7c f493abc5 00000000 920c8f20 00000000
netbt!DelayedNbtProcessConnect+0xfc
b9dcabcc f4936cf9 85d9b7f8 92302f20 00000000 netbt!NTConnect+0xbc
b9dcabe8 804e13d9 e0d9b7f8 92302fd8 806ff428
netbt!NbtDispatchInternalCtrl+0x101
b9dcabf8 80672145 92302f20 b9dcac30 00000000 nt!IopfCallDriver+0x31
b9dcac1c f48e9867 85d6c6b4 92302f20 00000000 nt!IovCallDriver+0xa0
b9dcac44 f48ebb91 85d9b7f8 92302f20 00000000 rdbss!RxCeSubmitTdiRequest+0x4b
b9dcac8c f48fd8c2 00000000 85d6c6dc 858d1894 rdbss!RxTdiConnect+0x154
b9dcacd4 f48fd9b6 858d18cc 858d1894 85d6c6a8 rdbss!RxCeBuildVC+0x59
b9dcad10 f48b35ff 85d6c6dc 85a09078 f4898360 rdbss!RxCeBuildConnection+0x4d
b9dcad50 f487ed7c 85d6aef0 85d79c00 f48f1ec0
mrxsmb!VctInstantiateServerTransport+0x18a
b9dcad6c f48e84b1 85d6aef0 00000000 85c39020
mrxsmb!SmbCeConstructServerTransport+0xc6
b9dcad9c f48f2845 008f1ec0 f48f2140 b9dcaddc
rdbss!RxpWorkerThreadDispatcher+0x93
b9dcadac 80574128 f48f1ec0 00000000 00000000
rdbss!RxWorkerThreadDispatcher+0x1a
b9dcaddc 804ec781 f48f282b f48f1ec0 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: .bugcheck ; kb

SYMBOL_NAME: NSKernel+6d8

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: NSKernel

IMAGE_NAME: NSKernel.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 48935687

FAILURE_BUCKET_ID: 0xc9_224_NSKernel+6d8

BUCKET_ID: 0xc9_224_NSKernel+6d8

Followup: MachineOwner

[OSR_Community_User]

Hi Scott,

Because we only have the core dumps, not live debugging data, we don’t
have access to the IRP information as you suggested. We are trying to
replicate the problem on a machine that we can debug. However, because
the problem only occurs once in a while, it is hard to get it happen
when we want it to (so far it hasn’t.)

Best regards,
Hao

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Thursday, August 07, 2008 9:37 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9) 224

Odd that it’s not showing the other info.

It should be relatively straightforward to find the offending IRP in
this
case. The caller used ZwCreateFile to send the create, and that routine
creates an IRP that is queued to the current thread. Because it hasn’t
really completed yet, I’d expect to find that IRP still on the thread’s
IRP
list.

Just do a !thread and you should find it in the output (an example from
my
VM):

kd> !thread
THREAD 85b55da0 Cid 3ac.344 Teb: 7ffdb000 Win32Thread: e1c2fde8
RUNNING
IRP List:
85b314e8: (0006,016c) Flags: 00000884 Mdl: 00000000

Finding the IRP should at least allow you to inspect the I/O status
block
and see the code in it, which might lead you in the right direction (you

could also find the IOSB on the stack from the ZwCreateFile call, it
should
be at b9dca964+14).

HTH,

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Hao Wang” wrote in message news:xxxxx@ntdev…
Hi,

Recently, driver verifier starts to trigger an interesting violation in
our
driver. The dump is listed below. I looked at the address, and it
appears to
be our dispatch routine.

I have three questions regarding how to identify the root cause of this
problem.

1. I am unable to find the IRP, IRP’s status, and returned status as
indicated in the message (I only have the crash dump files).

2. I went through the code and could not find out where the indicated
problem can occur: i.e., all our return paths have matching status code.

3. Lastly, the address of the IRP routine given in the dump points to
the
first line of our main dispatch routine, which in turn calls one of
three
sub dispatch routines (one for network, one for file system, and one for
our
internal device control). Right now, it appears that this problem is
pointing at the network dispatch routine (tdi), but I am not 100% sure.

Since I can’t find any other posts with similar error, I am wondering
what I
can do to resolve this problem.

Thanks,
Hao

***********************************************************



Bugcheck Analysis



**************************************************************


DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 00000224, (Fatal error) An IRP dispatch handler has returned a
status
that is inconsistent
with the IRP’s IoStatus.Status field. (Dispatch handler routine,
IRP,
IRP’s
IoStatus.Status, and returned Status specified.)
Arg2: f495d6d8
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------

Unable to load image NSKernel.sys, Win32 error 0n2
ERROR: Module load completed but symbols could not be loaded for
NSKernel.sys

ERROR_CODE: (NTSTATUS) 0xc9 - The operating system cannot run %1.

BUGCHECK_STR: 0xc9_224

DRIVER_VERIFIER_IO_VIOLATION_TYPE: 224

FAULTING_IP:
NSKernel+6d8
f495d6d8 8bff mov edi,edi

FOLLOWUP_IP:
NSKernel+6d8
f495d6d8 8bff mov edi,edi

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from 8067c258 to 8053738a

STACK_TEXT:
b9dca07c 8067c258 0000004c 000000c9 b9dca09c nt!KeBugCheckEx+0x1b
b9dca204 8067ca24 b9dca4f0 806a8077 00040000 nt!ViBugcheckHalt+0xc3
b9dca4a8 8067cb10 806ac630 00000224 b9dca4d4
nt!VfBugcheckThrowException+0xa1
b9dca598 8067f476 00000224 00002041 f495d6d8
nt!VfBugcheckThrowIoException+0xb5
b9dca5d4 80672155 00a6cf70 91c0ef58 91c0ef48 nt!IovpCallDriver2+0x292
b9dca5fc 8057cc89 85d65158 859dce04 b9dca794 nt!IovCallDriver+0xb0
b9dca6dc 8056c063 85d65170 00000000 859dcd60 nt!IopParseDevice+0xa12
b9dca754 8056f2a8 00000000 b9dca794 00000040
nt!ObpLookupObjectName+0x53c
b9dca7a8 8057d2e2 00000000 00000000 c0003c00 nt!ObOpenObjectByName+0xea
b9dca824 8057d3b1 b9dca9ec c0100000 b9dca9ac nt!IopCreateFile+0x407
b9dca880 8057d3f4 b9dca9ec c0100000 b9dca9ac nt!IoCreateFile+0x8e
b9dca8c0 804dd99f b9dca9ec c0100000 b9dca9ac nt!NtCreateFile+0x30
b9dca8c0 804e3577 b9dca9ec c0100000 b9dca9ac nt!KiFastCallEntry+0xfc
b9dca964 f4951bbc b9dca9ec c0100000 b9dca9ac nt!ZwCreateFile+0x11
b9dcaa10 f493ad6f 85a02fc4 b9dcaa40 85a02fbc
netbt!NbtTdiOpenAddress+0x227
b9dcaa44 f493a244 00000000 85897b58 85897b68
netbt!NbtOpenAndAssocConnection+0xe1
b9dcaaa8 f493a3d3 02dcaae8 f48f1ad0 028cc690
netbt!NbtConnectCommon+0x47a
b9dcaac4 f493ab56 b9dcaae8 f48f1ad0 858cc690 netbt!NbtConnect+0xb1
b9dcab14 f4936cf9 85d9b7f8 920c8f20 858cc600 netbt!NTConnect+0x119
b9dcab30 804e13d9 e0d9b7f8 920c8fd8 806ff428
netbt!NbtDispatchInternalCtrl+0x101
b9dcab40 80672145 858cc6a8 00000000 858cc680 nt!IopfCallDriver+0x31
b9dcab64 f4951f33 00000000 858cc680 920c8f20 nt!IovCallDriver+0xa0
b9dcab7c f493abc5 00000000 920c8f20 00000000
netbt!DelayedNbtProcessConnect+0xfc
b9dcabcc f4936cf9 85d9b7f8 92302f20 00000000 netbt!NTConnect+0xbc
b9dcabe8 804e13d9 e0d9b7f8 92302fd8 806ff428
netbt!NbtDispatchInternalCtrl+0x101
b9dcabf8 80672145 92302f20 b9dcac30 00000000 nt!IopfCallDriver+0x31
b9dcac1c f48e9867 85d6c6b4 92302f20 00000000 nt!IovCallDriver+0xa0
b9dcac44 f48ebb91 85d9b7f8 92302f20 00000000
rdbss!RxCeSubmitTdiRequest+0x4b
b9dcac8c f48fd8c2 00000000 85d6c6dc 858d1894 rdbss!RxTdiConnect+0x154
b9dcacd4 f48fd9b6 858d18cc 858d1894 85d6c6a8 rdbss!RxCeBuildVC+0x59
b9dcad10 f48b35ff 85d6c6dc 85a09078 f4898360
rdbss!RxCeBuildConnection+0x4d
b9dcad50 f487ed7c 85d6aef0 85d79c00 f48f1ec0
mrxsmb!VctInstantiateServerTransport+0x18a
b9dcad6c f48e84b1 85d6aef0 00000000 85c39020
mrxsmb!SmbCeConstructServerTransport+0xc6
b9dcad9c f48f2845 008f1ec0 f48f2140 b9dcaddc
rdbss!RxpWorkerThreadDispatcher+0x93
b9dcadac 80574128 f48f1ec0 00000000 00000000
rdbss!RxWorkerThreadDispatcher+0x1a
b9dcaddc 804ec781 f48f282b f48f1ec0 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: .bugcheck ; kb

SYMBOL_NAME: NSKernel+6d8

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: NSKernel

IMAGE_NAME: NSKernel.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 48935687

FAILURE_BUCKET_ID: 0xc9_224_NSKernel+6d8

BUCKET_ID: 0xc9_224_NSKernel+6d8

Followup: MachineOwner

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[Scott_Noone_OSR]

If you have a kernel summary dump or a full memory dump this info will be
available. If it’s a minidump then there isn’t much you can do except repro
it or have the customer send a summary dump.

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Hao Wang” wrote in message news:xxxxx@ntdev…

Hi Scott,

Because we only have the core dumps, not live debugging data, we don’t
have access to the IRP information as you suggested. We are trying to
replicate the problem on a machine that we can debug. However, because
the problem only occurs once in a while, it is hard to get it happen
when we want it to (so far it hasn’t.)

Best regards,
Hao

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Thursday, August 07, 2008 9:37 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9) 224

Odd that it’s not showing the other info.

It should be relatively straightforward to find the offending IRP in
this
case. The caller used ZwCreateFile to send the create, and that routine
creates an IRP that is queued to the current thread. Because it hasn’t
really completed yet, I’d expect to find that IRP still on the thread’s
IRP
list.

Just do a !thread and you should find it in the output (an example from
my
VM):

kd> !thread
THREAD 85b55da0 Cid 3ac.344 Teb: 7ffdb000 Win32Thread: e1c2fde8
RUNNING
IRP List:
85b314e8: (0006,016c) Flags: 00000884 Mdl: 00000000

Finding the IRP should at least allow you to inspect the I/O status
block
and see the code in it, which might lead you in the right direction (you

could also find the IOSB on the stack from the ZwCreateFile call, it
should
be at b9dca964+14).

HTH,

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Hao Wang” wrote in message news:xxxxx@ntdev…
Hi,

Recently, driver verifier starts to trigger an interesting violation in
our
driver. The dump is listed below. I looked at the address, and it
appears to
be our dispatch routine.

I have three questions regarding how to identify the root cause of this
problem.

1. I am unable to find the IRP, IRP’s status, and returned status as
indicated in the message (I only have the crash dump files).

2. I went through the code and could not find out where the indicated
problem can occur: i.e., all our return paths have matching status code.

3. Lastly, the address of the IRP routine given in the dump points to
the
first line of our main dispatch routine, which in turn calls one of
three
sub dispatch routines (one for network, one for file system, and one for
our
internal device control). Right now, it appears that this problem is
pointing at the network dispatch routine (tdi), but I am not 100% sure.

Since I can’t find any other posts with similar error, I am wondering
what I
can do to resolve this problem.

Thanks,
Hao

***********************************************************



Bugcheck Analysis



**************************************************************


DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 00000224, (Fatal error) An IRP dispatch handler has returned a
status
that is inconsistent
with the IRP’s IoStatus.Status field. (Dispatch handler routine,
IRP,
IRP’s
IoStatus.Status, and returned Status specified.)
Arg2: f495d6d8
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------

Unable to load image NSKernel.sys, Win32 error 0n2
ERROR: Module load completed but symbols could not be loaded for
NSKernel.sys

ERROR_CODE: (NTSTATUS) 0xc9 - The operating system cannot run %1.

BUGCHECK_STR: 0xc9_224

DRIVER_VERIFIER_IO_VIOLATION_TYPE: 224

FAULTING_IP:
NSKernel+6d8
f495d6d8 8bff mov edi,edi

FOLLOWUP_IP:
NSKernel+6d8
f495d6d8 8bff mov edi,edi

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from 8067c258 to 8053738a

STACK_TEXT:
b9dca07c 8067c258 0000004c 000000c9 b9dca09c nt!KeBugCheckEx+0x1b
b9dca204 8067ca24 b9dca4f0 806a8077 00040000 nt!ViBugcheckHalt+0xc3
b9dca4a8 8067cb10 806ac630 00000224 b9dca4d4
nt!VfBugcheckThrowException+0xa1
b9dca598 8067f476 00000224 00002041 f495d6d8
nt!VfBugcheckThrowIoException+0xb5
b9dca5d4 80672155 00a6cf70 91c0ef58 91c0ef48 nt!IovpCallDriver2+0x292
b9dca5fc 8057cc89 85d65158 859dce04 b9dca794 nt!IovCallDriver+0xb0
b9dca6dc 8056c063 85d65170 00000000 859dcd60 nt!IopParseDevice+0xa12
b9dca754 8056f2a8 00000000 b9dca794 00000040
nt!ObpLookupObjectName+0x53c
b9dca7a8 8057d2e2 00000000 00000000 c0003c00 nt!ObOpenObjectByName+0xea
b9dca824 8057d3b1 b9dca9ec c0100000 b9dca9ac nt!IopCreateFile+0x407
b9dca880 8057d3f4 b9dca9ec c0100000 b9dca9ac nt!IoCreateFile+0x8e
b9dca8c0 804dd99f b9dca9ec c0100000 b9dca9ac nt!NtCreateFile+0x30
b9dca8c0 804e3577 b9dca9ec c0100000 b9dca9ac nt!KiFastCallEntry+0xfc
b9dca964 f4951bbc b9dca9ec c0100000 b9dca9ac nt!ZwCreateFile+0x11
b9dcaa10 f493ad6f 85a02fc4 b9dcaa40 85a02fbc
netbt!NbtTdiOpenAddress+0x227
b9dcaa44 f493a244 00000000 85897b58 85897b68
netbt!NbtOpenAndAssocConnection+0xe1
b9dcaaa8 f493a3d3 02dcaae8 f48f1ad0 028cc690
netbt!NbtConnectCommon+0x47a
b9dcaac4 f493ab56 b9dcaae8 f48f1ad0 858cc690 netbt!NbtConnect+0xb1
b9dcab14 f4936cf9 85d9b7f8 920c8f20 858cc600 netbt!NTConnect+0x119
b9dcab30 804e13d9 e0d9b7f8 920c8fd8 806ff428
netbt!NbtDispatchInternalCtrl+0x101
b9dcab40 80672145 858cc6a8 00000000 858cc680 nt!IopfCallDriver+0x31
b9dcab64 f4951f33 00000000 858cc680 920c8f20 nt!IovCallDriver+0xa0
b9dcab7c f493abc5 00000000 920c8f20 00000000
netbt!DelayedNbtProcessConnect+0xfc
b9dcabcc f4936cf9 85d9b7f8 92302f20 00000000 netbt!NTConnect+0xbc
b9dcabe8 804e13d9 e0d9b7f8 92302fd8 806ff428
netbt!NbtDispatchInternalCtrl+0x101
b9dcabf8 80672145 92302f20 b9dcac30 00000000 nt!IopfCallDriver+0x31
b9dcac1c f48e9867 85d6c6b4 92302f20 00000000 nt!IovCallDriver+0xa0
b9dcac44 f48ebb91 85d9b7f8 92302f20 00000000
rdbss!RxCeSubmitTdiRequest+0x4b
b9dcac8c f48fd8c2 00000000 85d6c6dc 858d1894 rdbss!RxTdiConnect+0x154
b9dcacd4 f48fd9b6 858d18cc 858d1894 85d6c6a8 rdbss!RxCeBuildVC+0x59
b9dcad10 f48b35ff 85d6c6dc 85a09078 f4898360
rdbss!RxCeBuildConnection+0x4d
b9dcad50 f487ed7c 85d6aef0 85d79c00 f48f1ec0
mrxsmb!VctInstantiateServerTransport+0x18a
b9dcad6c f48e84b1 85d6aef0 00000000 85c39020
mrxsmb!SmbCeConstructServerTransport+0xc6
b9dcad9c f48f2845 008f1ec0 f48f2140 b9dcaddc
rdbss!RxpWorkerThreadDispatcher+0x93
b9dcadac 80574128 f48f1ec0 00000000 00000000
rdbss!RxWorkerThreadDispatcher+0x1a
b9dcaddc 804ec781 f48f282b f48f1ec0 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: .bugcheck ; kb

SYMBOL_NAME: NSKernel+6d8

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: NSKernel

IMAGE_NAME: NSKernel.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 48935687

FAILURE_BUCKET_ID: 0xc9_224_NSKernel+6d8

BUCKET_ID: 0xc9_224_NSKernel+6d8

Followup: MachineOwner

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[Tim_Roberts]

Hao Wang wrote:

Because we only have the core dumps, not live debugging data, we don’t
have access to the IRP information as you suggested.

What makes you think so? If you have a full kernel dump, then you
should have all the information you need to find this. At the very
least, you might start by assuming that the parameters to IovCallDriver
match the parameters to IoCallDriver, meaning a device object and an IRP
pointer.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[OSR_Community_User]

>> Because we only have the core dumps, not live debugging data, we
don’t

> have access to the IRP information as you suggested.

What makes you think so? If you have a full kernel dump, then you
should have all the information you need to find this. At the very
least, you might start by assuming that the parameters to
IovCallDriver
match the parameters to IoCallDriver, meaning a device object and an
IRP
pointer.

Sorry I didn’t make it clear earlier. We only have the mini dumps, not
the full kernel dump. I have tried !thread and it wasn’t able to get any
valid data from the IRP specified in the minidump.

My understanding of this problem is that the dispatch routine returned
an error code that is different from what is stored in the IRP upon
returning from the dispatch routine.

This seems to be a fairly easy bug to locate, and I was hoping that we
can spot where the problem may be without waiting for the test machine
to eventually replicate the bug. But I guess there is no easy way around
it.

Thanks,
Hao