DRIVER_VERIFIER_IOMANAGER_VIOLATION

Hi All !

I am working on an Intermediate Driver. When the driver has been
installed and i try to dial-up my ISP my machine crashes with BSOD.
The following is the detailed crash dump analysis.
I am new to WinDBG and so am facing problems on where to begin futher
investigation. Any clues would be helpful.
Please help.

Thanks for your help and time in advance !!!

kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 00000005, Irql not equal across call to the driver dispatch
routine
Arg2: ffb96870, the device object associated with the offending driver
Arg3: 00000000, the Irql before the call
Arg4: 00000002, the Irql after the call

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


DRIVER_VERIFIER_IO_VIOLATION_TYPE: 5

PREVIOUS_IRQL: 0

CURRENT_IRQL: 2

DEVICE_OBJECT: ffb96870

DRIVER_OBJECT: ffb987e0

IMAGE_NAME: mvstdi5x.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41377210

FAULTING_MODULE: f8e00000 tcpip

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xC9

LAST_CONTROL_TRANSFER: from 80669d06 to 8053331e

STACK_TEXT:
fc91756c 80669d06 000000c9 00000005 ffb96870 nt!KeBugCheckEx+0x1b
fc9175a4 fa4a5ca0 fc9175c8 fa4a9506 ffb96870 nt!IovCallDriver+0xe1
WARNING: Stack unwind information not available. Following frames may
be wrong.
fc9175ac fa4a9506 ffb96870 81ed4f20 81ed4f20 mvstdi5x+0x6ca0
fc9175c8 fa4a9a41 ffb885f0 ffb96870 81ed4f20 mvstdi5x+0xa506
fc9175e0 fa4a499d ffb885f0 81ed4f20 ffb885f0 mvstdi5x+0xaa41
fc9175f8 fa4a4a42 ffb885f0 81ed4f20 0000000f mvstdi5x+0x599d
fc91760c 804e37f7 ffb885f0 81ed4f20 806ed2a4 mvstdi5x+0x5a42
fc91761c 80669cc5 fc91768c 00000044 819a0b48 nt!IopfCallDriver+0x31
fc917640 f8dda544 ff819ef8 ff87d820 f8df398c nt!IovCallDriver+0xa0
fc917664 f8dda391 fc91768c ff819fc8 00000044
netbt!TdiSendDatagram+0x1b8
fc9176a8 f8dde149 ff819ef8 ac190a0f 00000044
netbt!UdpSendDatagram+0x14c
fc9176f0 f8de2421 ff819ef8 ff843fb8 00b72de8 netbt!UdpSendNSBcast+0x288
fc917740 f8de2deb 00000000 00000000 81942abb
netbt!NbtRegisterName+0x2d6
fc91779c f8df587d fc9177c8 00942ab5 c0a80109 netbt!NbtOpenAddress+0x3f2
fc9177dc f8df57f1 ff713848 82204f20 0000001a netbt!NTOpenAddr+0x95
fc9177fc 804e37f7 ff713848 00204f20 806ed2a4
netbt!NbtDispatchCreate+0x92
fc91780c 80669cc5 82204f30 82204f20 ff879bb8 nt!IopfCallDriver+0x31
fc917830 8057069a ff8e9960 ff866fa0 fc917a10 nt!IovCallDriver+0xa0
fc917910 80571ba0 ff713848 00000000 ff88a870 nt!IopParseDevice+0xa58
fc917948 805674b5 ff8e9960 00000000 ff88a870 nt!IopParseFile+0x46
fc9179d0 8056729a 000002ec fc917a10 00000040
nt!ObpLookupObjectName+0x119
fc917a24 80570b73 00000000 00000000 55ebe000 nt!ObOpenObjectByName+0xeb
fc917aa0 80570c42 ff830fe4 c0100000 fc917c20 nt!IopCreateFile+0x407
fc917afc 80570d78 ff830fe4 c0100000 fc917c20 nt!IoCreateFile+0x8e
fc917b3c 804de7ec ff830fe4 c0100000 fc917c20 nt!NtCreateFile+0x30
fc917b3c 804dc9b1 ff830fe4 c0100000 fc917c20 nt!KiFastCallEntry+0xf8
fc917be0 f8d6ba3f ff830fe4 c0100000 fc917c20 nt!ZwCreateFile+0x11
fc917c44 f8d80088 ff830fa4 e14bb690 ff830fcc
rdbss!RxTdiOpenAddress+0x80
fc917c80 f8d2bded ff830fcc ff830fa4 fc917cbc
rdbss!RxCeBuildAddress+0xb6
fc917ce4 f8d29a91 fc917cfc ff81ee70 ff9aa8d0
mrxsmb!MRxSmbpBindTransportCallback+0x11d
fc917d10 fc77dc62 00000001 00000009 ff9a3c28
mrxsmb!MRxSmbPnPBindingHandler+0x11f
fc917d34 fc77e2e8 fc77f208 ff81ee70 00000001
TDI!TdiNotifyPnpClientList+0x164
fc917d58 fc77c3e4 fc77f220 00954d68 fc77f230
TDI!TdiExecuteRequest+0x382
fc917d74 804e426b ff954d68 00000000 81a88b30 TDI!CTEpEventHandler+0x32
fc917dac 8057be15 fc77f220 00000000 00000000 nt!ExpWorkerThread+0x100
fc917ddc 804fa4da 804e4196 00000001 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


FOLLOWUP_IP:
mvstdi5x+6ca0
fa4a5ca0 5d pop ebp

SYMBOL_STACK_INDEX: 2

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: mvstdi5x+6ca0

MODULE_NAME: mvstdi5x

STACK_COMMAND: kb

FAILURE_BUCKET_ID: 0xC9_mvstdi5x+6ca0

BUCKET_ID: 0xC9_mvstdi5x+6ca0

Followup: MachineOwner
---------

BR
Sukhvinder

gauravl
Mon Aug 08 00:47:47 CDT 2005

You need to point WinDBG to the symbol path for your driver (it needs
to be accessible from the machine that you're running Windbg on). Read
up about the command .sympath in the ddk help, but briefly, you need to
do
.sympath+ <path>
.reload

Also point Windbg to your src code by using the .srcpatch command

If the symbols load correctly, you will see the functions in the stack.
(Look at the windbg window called call stack). Now click on the
topmost function on the stack inside your driver. (This is "fc9175ac
fa4a9506 ffb96870 81ed4f20 81ed4f20 mvstdi5x+0x6ca0")
It should take you to the offending source code line causing the
bugcheck.

Its important to get the symbols to load up, otherwise the debugger
cant get the symbol names from the driver, nor can it associate the
source code lines to the assembly.

Gaurav

skaur
Mon Aug 08 01:12:25 CDT 2005

Thanks for your reply Gaurav.

I have set the symbol and source paths correctly. I verified this as
follows:

kd> .sympath
Symbol search path is:
srv*h:\symbols\websymbols*http://msdl.microsoft.com/download/symbols;G:\sentinel\pdb\
kd> .srcpath
Source search path is: G:\sentinel\src

The above commands show the symbol and source paths for my driver in
G:\sentinel.
Infact i can even view the Call Stack, but clicking on the functions
doesn't lead me anywhere, no source code files open.

Perhaps if anyone has encountered such a bugcheck earlier, then they
would have clues on how to analyse such a Stack Text.

But, thanks anyways for your help

BR
Sukhvinder

Mark
Mon Aug 08 06:21:09 CDT 2005

skaur@in.safenet-inc.com wrote:
> Hi All !
>
> I am working on an Intermediate Driver. When the driver has been
> installed and i try to dial-up my ISP my machine crashes with BSOD.
> The following is the detailed crash dump analysis.
> I am new to WinDBG and so am facing problems on where to begin futher
> investigation. Any clues would be helpful.
> Please help.
>
> Thanks for your help and time in advance !!!
>
> kd> !analyze -v
> *******************************************************************************
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> *******************************************************************************
>
> DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
> The IO manager has caught a misbehaving driver.
> Arguments:
> Arg1: 00000005, Irql not equal across call to the driver dispatch
> routine
> Arg2: ffb96870, the device object associated with the offending driver
> Arg3: 00000000, the Irql before the call
> Arg4: 00000002, the Irql after the call
>


Well that is pretty clear to me. You received an IRP in your dispatch
routine at IRQL PASSIVE_LEVEL and you raised IRQL to DISPATCH_LEVEL and
forwarded the IRP on down the stack at DISPATCH_LEVEL rather than
PASSIVE_LEVEL. Don't do that.

Also as another poster pointed out your symbols for your driver are
incorrect. "mvstdi5x" is your driver, right? Perhaps your current source
code does not match the pdb you are pointing windbg to.

> Debugging Details:
> ------------------
>
>
> DRIVER_VERIFIER_IO_VIOLATION_TYPE: 5
>
> PREVIOUS_IRQL: 0
>
> CURRENT_IRQL: 2
>
> DEVICE_OBJECT: ffb96870
>
> DRIVER_OBJECT: ffb987e0
>
> IMAGE_NAME: mvstdi5x.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 41377210
>
> FAULTING_MODULE: f8e00000 tcpip
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xC9
>
> LAST_CONTROL_TRANSFER: from 80669d06 to 8053331e
>
> STACK_TEXT:
> fc91756c 80669d06 000000c9 00000005 ffb96870 nt!KeBugCheckEx+0x1b
> fc9175a4 fa4a5ca0 fc9175c8 fa4a9506 ffb96870 nt!IovCallDriver+0xe1
> WARNING: Stack unwind information not available. Following frames may
> be wrong.
> fc9175ac fa4a9506 ffb96870 81ed4f20 81ed4f20 mvstdi5x+0x6ca0
> fc9175c8 fa4a9a41 ffb885f0 ffb96870 81ed4f20 mvstdi5x+0xa506
> fc9175e0 fa4a499d ffb885f0 81ed4f20 ffb885f0 mvstdi5x+0xaa41
> fc9175f8 fa4a4a42 ffb885f0 81ed4f20 0000000f mvstdi5x+0x599d
> fc91760c 804e37f7 ffb885f0 81ed4f20 806ed2a4 mvstdi5x+0x5a42
> fc91761c 80669cc5 fc91768c 00000044 819a0b48 nt!IopfCallDriver+0x31
> fc917640 f8dda544 ff819ef8 ff87d820 f8df398c nt!IovCallDriver+0xa0
> fc917664 f8dda391 fc91768c ff819fc8 00000044
> netbt!TdiSendDatagram+0x1b8
> fc9176a8 f8dde149 ff819ef8 ac190a0f 00000044
> netbt!UdpSendDatagram+0x14c
> fc9176f0 f8de2421 ff819ef8 ff843fb8 00b72de8 netbt!UdpSendNSBcast+0x288
> fc917740 f8de2deb 00000000 00000000 81942abb
> netbt!NbtRegisterName+0x2d6
> fc91779c f8df587d fc9177c8 00942ab5 c0a80109 netbt!NbtOpenAddress+0x3f2
> fc9177dc f8df57f1 ff713848 82204f20 0000001a netbt!NTOpenAddr+0x95
> fc9177fc 804e37f7 ff713848 00204f20 806ed2a4
> netbt!NbtDispatchCreate+0x92
> fc91780c 80669cc5 82204f30 82204f20 ff879bb8 nt!IopfCallDriver+0x31
> fc917830 8057069a ff8e9960 ff866fa0 fc917a10 nt!IovCallDriver+0xa0
> fc917910 80571ba0 ff713848 00000000 ff88a870 nt!IopParseDevice+0xa58
> fc917948 805674b5 ff8e9960 00000000 ff88a870 nt!IopParseFile+0x46
> fc9179d0 8056729a 000002ec fc917a10 00000040
> nt!ObpLookupObjectName+0x119
> fc917a24 80570b73 00000000 00000000 55ebe000 nt!ObOpenObjectByName+0xeb
> fc917aa0 80570c42 ff830fe4 c0100000 fc917c20 nt!IopCreateFile+0x407
> fc917afc 80570d78 ff830fe4 c0100000 fc917c20 nt!IoCreateFile+0x8e
> fc917b3c 804de7ec ff830fe4 c0100000 fc917c20 nt!NtCreateFile+0x30
> fc917b3c 804dc9b1 ff830fe4 c0100000 fc917c20 nt!KiFastCallEntry+0xf8
> fc917be0 f8d6ba3f ff830fe4 c0100000 fc917c20 nt!ZwCreateFile+0x11
> fc917c44 f8d80088 ff830fa4 e14bb690 ff830fcc
> rdbss!RxTdiOpenAddress+0x80
> fc917c80 f8d2bded ff830fcc ff830fa4 fc917cbc
> rdbss!RxCeBuildAddress+0xb6
> fc917ce4 f8d29a91 fc917cfc ff81ee70 ff9aa8d0
> mrxsmb!MRxSmbpBindTransportCallback+0x11d
> fc917d10 fc77dc62 00000001 00000009 ff9a3c28
> mrxsmb!MRxSmbPnPBindingHandler+0x11f
> fc917d34 fc77e2e8 fc77f208 ff81ee70 00000001
> TDI!TdiNotifyPnpClientList+0x164
> fc917d58 fc77c3e4 fc77f220 00954d68 fc77f230
> TDI!TdiExecuteRequest+0x382
> fc917d74 804e426b ff954d68 00000000 81a88b30 TDI!CTEpEventHandler+0x32
> fc917dac 8057be15 fc77f220 00000000 00000000 nt!ExpWorkerThread+0x100
> fc917ddc 804fa4da 804e4196 00000001 00000000
> nt!PspSystemThreadStartup+0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> FOLLOWUP_IP:
> mvstdi5x+6ca0
> fa4a5ca0 5d pop ebp
>
> SYMBOL_STACK_INDEX: 2
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: mvstdi5x+6ca0
>
> MODULE_NAME: mvstdi5x
>
> STACK_COMMAND: kb
>
> FAILURE_BUCKET_ID: 0xC9_mvstdi5x+6ca0
>
> BUCKET_ID: 0xC9_mvstdi5x+6ca0
>
> Followup: MachineOwner
> ---------
>
> BR
> Sukhvinder
>


--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

skaur
Mon Aug 08 07:05:22 CDT 2005

Thanks Mark for your reply.

U wrote :
"Well that is pretty clear to me. You received an IRP in your dispatch
routine at IRQL PASSIVE_LEVEL and you raised IRQL to DISPATCH_LEVEL and
forwarded the IRP on down the stack at DISPATCH_LEVEL rather than
PASSIVE_LEVEL. Don't do that. "

You have written the final verdict, can you please spare a few minutes
to outline as to how you reached this conclusion. Obviously from the
Stack Text, but how....???
That's what i am interested in knowing basically. AT this stage even
after you have pointed out the exact error, i am not in a position to
solve it, since i don't know how we reached here in the first place.

Hoping you find the time to respond.
Thanks a ton in advance.

Rgds
Sukhvinder

Default
Mon Aug 08 14:35:04 CDT 2005

I reached the same conclusion as Mark by just reading the output that the
debugger spewed:

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 00000005, Irql not equal across call to the driver dispatch routine
Arg2: ffb96870, the device object associated with the offending driver
Arg3: 00000000, the Irql before the call
Arg4: 00000002, the Irql after the call

Argument 1 tells you what went wrong.
Argument 2 tells you the device object whose dispatch routien was called.
Argument 3 tells you that the dispatch routine was called at passive level.
Argument 4 tells you the IRQL when the call returned.

-p

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

<skaur@in.safenet-inc.com> wrote in message
news:1123502722.583107.10860@o13g2000cwo.googlegroups.com...
> Thanks Mark for your reply.
>
> U wrote :
> "Well that is pretty clear to me. You received an IRP in your dispatch
> routine at IRQL PASSIVE_LEVEL and you raised IRQL to DISPATCH_LEVEL and
> forwarded the IRP on down the stack at DISPATCH_LEVEL rather than
> PASSIVE_LEVEL. Don't do that. "
>
> You have written the final verdict, can you please spare a few minutes
> to outline as to how you reached this conclusion. Obviously from the
> Stack Text, but how....???
> That's what i am interested in knowing basically. AT this stage even
> after you have pointed out the exact error, i am not in a position to
> solve it, since i don't know how we reached here in the first place.
>
> Hoping you find the time to respond.
> Thanks a ton in advance.
>
> Rgds
> Sukhvinder
>

Mark
Mon Aug 08 19:10:41 CDT 2005

Default User wrote:
> I reached the same conclusion as Mark by just reading the output that
> the debugger spewed:
>
> DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
> The IO manager has caught a misbehaving driver.
> Arguments:
> Arg1: 00000005, Irql not equal across call to the driver dispatch routine
> Arg2: ffb96870, the device object associated with the offending driver
> Arg3: 00000000, the Irql before the call
> Arg4: 00000002, the Irql after the call
>
> Argument 1 tells you what went wrong.
> Argument 2 tells you the device object whose dispatch routien was called.
> Argument 3 tells you that the dispatch routine was called at passive level.
> Argument 4 tells you the IRQL when the call returned.
>
> -p
>
And let me add to that:

er, well there is nothing more to add :-)

--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com