Debugging DRIVER_IRQL_NOT_LESS_OR_EQUAL

Hi,

I’m one lucky guy. My NDIS miniport driver has started spitting out
DRIVER_IRQL_NOT_LESS_OR_EQUAL exceptions.

I know it is my driver that causes the system to do a bugcheck, but viewing
the crash dump doesn’t reveal anything of what went wrong. Windows can’t
even identify which driver was the culprit.

As I am still relatively new to driver development, I have no idea of how to
go about identifying the exact cause of the bug check, hence why I am
turning to you guys.
Below I have inserted part of the crash dump report generated by WinDbg.

I hope you have some ideas on what I can do to identify the problem.

Thanks!


DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 71a5d7a8, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 71a5d7a8, address which referenced memory

Debugging Details:

READ_ADDRESS: 71a5d7a8

CURRENT_IRQL: 2

FAULTING_IP:
+71a5d7a8
71a5d7a8 ?? ???

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 804dce53 to 805266db

TRAP_FRAME: f626bd64 – (.trap fffffffff626bd64)
ErrCode = 00000004
eax=00000000 ebx=01a5fb9c ecx=00000000 edx=7ffe0304 esi=01a5fd7c
edi=00000e18
eip=71a5d7a8 esp=01a5fb34 ebp=01a5fc00 iopl=0 nv up ei pl nz na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
efl=00010202
001b:71a5d7a8 ?? ???
Resetting default scope

STACK_TEXT:
f626bd48 804dce53 0000000a 71a5d7a8 00000002 nt!KeBugCheckEx+0x19
f626bd48 71a5d7a8 0000000a 71a5d7a8 00000002 nt!KiTrap0E+0x2ad
WARNING: Frame IP not in any known module. Following frames may be wrong.
01a5fc00 00000000 00000000 00000000 00000000 0x71a5d7a8

FAILED_INSTRUCTION_ADDRESS:
+71a5d7a8
71a5d7a8 ?? ???

FOLLOWUP_IP:
nt!KiTrap0E+2ad
804dce53 cc int 3

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!KiTrap0E+2ad

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: kb

BUCKET_ID: RAISED_IRQL_USER_FAULT

MODULE_NAME: Unknown_Module

Followup: MachineOwner

Søren Dreijer wrote:

Hi,

I’m one lucky guy. My NDIS miniport driver has started spitting out
DRIVER_IRQL_NOT_LESS_OR_EQUAL exceptions.

I know it is my driver that causes the system to do a bugcheck, but viewing
the crash dump doesn’t reveal anything of what went wrong. Windows can’t
even identify which driver was the culprit.

IMHO, it’s likely to be a system call you make. Check the parts of your code
running at DISPATCH_LEVEL for calls to functions which need a lower IRQL (like
PASSIVE_LEVEL).
It could be waiting for an event etc as well, but thats essentially the same
thing: at DISPATCH_LEVEL, you may not block (wait).

You’ll find the information about the functions and their respective IRQL inside
the SDK documentation. Some introduction to IRQL and similar topics can be found
at http://msdn.microsoft.com/library/en-us/dndevice/html/IRQL_Sched.asp

Since you wrote you’re new to driver development, I think you should start with
this. Detailled debugging will help finding the exact cause of the bluescreen,
but above is something you’ll need to know and take care of in any case.

HTH

At a guess you probably trashed the stack with a buffer overrun in some
routine. Examining the raw stack as bytes a little above the trap frame
might show a recognizable data pattern.

Irql-less-or-equal is almost always actually caused by a bad address that
causes an address exception, and this gets you into the exception handler at
a high irql. Typically you would see a bad data address. In this case
though it looks like you have a bad code address: 71a5d7a8. The most likely
way to get something like that would be to have a buffer on the stack and
overrun the end, and overwrite the return address for the procedure. Then
when you return from the procedure you go off into never-never land.

Loren

----- Original Message -----
From: “Søren Dreijer”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Saturday, February 25, 2006 6:08 AM
Subject: [ntdev] Debugging DRIVER_IRQL_NOT_LESS_OR_EQUAL

> Hi,
>
> I’m one lucky guy. My NDIS miniport driver has started spitting out
> DRIVER_IRQL_NOT_LESS_OR_EQUAL exceptions.
>
> I know it is my driver that causes the system to do a bugcheck, but
viewing
> the crash dump doesn’t reveal anything of what went wrong. Windows can’t
> even identify which driver was the culprit.
>
> As I am still relatively new to driver development, I have no idea of how
to
> go about identifying the exact cause of the bug check, hence why I am
> turning to you guys.
> Below I have inserted part of the crash dump report generated by WinDbg.
>
> I hope you have some ideas on what I can do to identify the problem.
>
> Thanks!
>
> ---------------------------------------------------------
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> An attempt was made to access a pageable (or completely invalid) address
at
> an
> interrupt request level (IRQL) that is too high. This is usually
> caused by drivers using improper addresses.
> If kernel debugger is available get stack backtrace.
> Arguments:
> Arg1: 71a5d7a8, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: 71a5d7a8, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 71a5d7a8
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> +71a5d7a8
> 71a5d7a8 ?? ???
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> LAST_CONTROL_TRANSFER: from 804dce53 to 805266db
>
> TRAP_FRAME: f626bd64 – (.trap fffffffff626bd64)
> ErrCode = 00000004
> eax=00000000 ebx=01a5fb9c ecx=00000000 edx=7ffe0304 esi=01a5fd7c
> edi=00000e18
> eip=71a5d7a8 esp=01a5fb34 ebp=01a5fc00 iopl=0 nv up ei pl nz na pe
> nc
> cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
> efl=00010202
> 001b:71a5d7a8 ?? ???
> Resetting default scope
>
> STACK_TEXT:
> f626bd48 804dce53 0000000a 71a5d7a8 00000002 nt!KeBugCheckEx+0x19
> f626bd48 71a5d7a8 0000000a 71a5d7a8 00000002 nt!KiTrap0E+0x2ad
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 01a5fc00 00000000 00000000 00000000 00000000 0x71a5d7a8
>
>
> FAILED_INSTRUCTION_ADDRESS:
> +71a5d7a8
> 71a5d7a8 ?? ???
>
> FOLLOWUP_IP:
> nt!KiTrap0E+2ad
> 804dce53 cc int 3
>
> SYMBOL_STACK_INDEX: 1
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: nt!KiTrap0E+2ad
>
> IMAGE_NAME: Unknown_Image
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> STACK_COMMAND: kb
>
> BUCKET_ID: RAISED_IRQL_USER_FAULT
>
> MODULE_NAME: Unknown_Module
>
> Followup: MachineOwner
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Thanks for the quick reply both!

While waiting for replies I enabled the driver verifier on my driver and I
got the crash analysis shown below.

Some more information: The driver is currently copying packets which are
transmittted on it to a user-mode application. The latter issues
asynchronous read requests to the driver, which are completed whenever a
packet is received.
Furthermore, packets can be “injected” from user-mode. That is, the
user-mode application can write packets to the driver, which then indicates
up that it has “received” a packet from the network.

Thanks,

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: 81767e08, 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: 81767e08

DRIVER_OBJECT: 816b31e0

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAULTING_MODULE: 00000000

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0xC9

LAST_CONTROL_TRANSFER: from 80647152 to 805266db

STACK_TEXT:
f6111c38 80647152 000000c9 00000005 81767e08 nt!KeBugCheckEx+0x19
f6111c70 8058b076 82aa2fd8 00000000 82aa2f68 nt!IovCallDriver+0xdf
f6111c84 8058dfc2 81767e08 82aa2f68 81632d28
nt!IopSynchronousServiceTail+0x5e
f6111d38 804da140 00000720 00000714 00000000 nt!NtWriteFile+0x5de
f6111d38 7ffe0304 00000720 00000714 00000000 nt!KiSystemService+0xc4
01a5fa08 00000000 00000000 00000000 00000000
SharedUserData!SystemCallStub+0x4

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
804da0ce-804da0d2 5 bytes - nt!KiSystemService+52
[0f 85 d6 fe ff:e9 f4 8f 17 01]
804da151-804da155 5 bytes - nt!KiServiceExit (+0x83)
[fa f7 45 70 00:e9 8d 8f 17 01]
804da23d-804da241 5 bytes - nt!KiSystemCallExitBranch+2 (+0xec)
[5a 59 9d ff e2:e9 11 07 29 01]
804da2f1-804da2f5 5 bytes - nt!KiServiceExit2 (+0xb4)
[fa f7 45 70 00:e9 44 8e 17 01]
804da937-804da93b 5 bytes - nt!KiExceptionExit (+0x646)
[fa f7 45 70 00:e9 c4 87 17 01]
804dcc36-804dcc3b 6 bytes - nt!KiTrap0E+90 (+0x22ff)
[fb f7 45 70 00 02:90 e9 e1 64 17 01]
804eca47-804eca4b 5 bytes - nt!ExAcquireResourceSharedLite+f (+0xfe11)
[fa 8b 75 08 33:e9 60 66 16 01]
804ecab7-804ecabb 5 bytes - nt!ExReleaseResourceLite+d (+0x70)
[fa 8b 55 fc f6:e9 98 65 16 01]
804ecbb5-804ecbb9 5 bytes - nt!ExAcquireResourceExclusiveLite+5 (+0xfe)
[64 a1 24 01 00:e9 b7 64 16 01]
804ecbd6-804ecbda 5 bytes - nt!ExAcquireResourceExclusiveLite+45
(+0x21)
[89 46 1c 66 89:e9 b4 64 16 01]
804f5129-804f512d 5 bytes - nt!ExIsResourceAcquiredExclusiveLite+6
(+0x8553)
[fa 8b 4c 24 04:e9 83 e0 15 01]
805025ec-805025ef 4 bytes - nt!KiServiceTable+64 (+0xd4c3)
[55 13 58 80:28 50 fc ba]
8050262c-8050262f 4 bytes - nt!KiServiceTable+a4 (+0x40)
[2e aa 57 80:e0 4f fc ba]
8050263c-8050263f 4 bytes - nt!KiServiceTable+b4 (+0x10)
[a0 b7 5a 80:00 8b fb ba]
805026a4-805026a7 4 bytes - nt!KiServiceTable+11c (+0x68)
[23 d3 57 80:dc 95 fb ba]
805026ac-805026af 4 bytes - nt!KiServiceTable+124 (+0x08)
[f7 a5 56 80:20 51 fc ba]
80502758-8050275b 4 bytes - nt!KiServiceTable+1d0 (+0xac)
[33 52 58 80:40 8b fb ba]
80502764-80502767 4 bytes - nt!KiServiceTable+1dc (+0x0c)
[2f 27 58 80:a4 4f fc ba]
80502808-8050280b 4 bytes - nt!KiServiceTable+280 (+0xa4)
[60 34 57 80:fc 95 fb ba]
8050284c-8050284f 4 bytes - nt!KiServiceTable+2c4 (+0x44)
[fb 33 58 80:76 50 fc ba]
8050294c-8050294f 4 bytes - nt!KiServiceTable+3c4 (+0x100)
[4c 2b 64 80:50 45 fc ba]
805120ca-805120ce 5 bytes - nt!KeUpdateSystemTime+114 (+0xf77e)
[fa ff 15 dc 45:e9 68 11 14 01]
80636708-8063670a 3 bytes - nt!MiVerifierThunks
[5c 6e 63:17 bf 4e]
80636710-80636712 3 bytes - nt!MiVerifierThunks+8 (+0x08)
[40 6e 63:bc 28 51]
80636718-8063671a 3 bytes - nt!MiVerifierThunks+10 (+0x08)
[24 6e 63:da 28 51]
80636720-80636722 3 bytes - nt!MiVerifierThunks+18 (+0x08)
[04 6e 63:b0 cb 4e]
80636728-8063672a 3 bytes - nt!MiVerifierThunks+20 (+0x08)
[ec 6d 63:aa ca 4e]
80636730-80636732 3 bytes - nt!MiVerifierThunks+28 (+0x08)
[d8 6d 63:4e e4 4e]
80636738-8063673a 3 bytes - nt!MiVerifierThunks+30 (+0x08)
[bc 6d 63:0c 6c 5c]
80636740-80636742 3 bytes - nt!MiVerifierThunks+38 (+0x08)
[ac 6d 63:2f 9e 50]
80636748-8063674a 3 bytes - nt!MiVerifierThunks+40 (+0x08)
[98 6d 63:55 f0 4f]
80636750-80636752 3 bytes - nt!MiVerifierThunks+48 (+0x08)
[78 6d 63:2a d0 4e]
80636758-8063675a 3 bytes - nt!MiVerifierThunks+50 (+0x08)
[68 6d 63:ce e6 4e]
80636760-80636762 3 bytes - nt!MiVerifierThunks+58 (+0x08)
[54 6d 63:a3 d7 4e]
80636768-8063676a 3 bytes - nt!MiVerifierThunks+60 (+0x08)
[44 6d 63:5c 9f 50]
80636770-80636772 3 bytes - nt!MiVerifierThunks+68 (+0x08)
[30 6d 63:98 80 6c]
80636778-8063677a 3 bytes - nt!MiVerifierThunks+70 (+0x08)
[18 6d 63:c8 80 6c]
80636780-80636782 3 bytes - nt!MiVerifierThunks+78 (+0x08)
[04 6d 63:f8 80 6c]
80636788-8063678a 3 bytes - nt!MiVerifierThunks+80 (+0x08)
[f8 6c 63:58 bb 6c]
80636790-80636792 3 bytes - nt!MiVerifierThunks+88 (+0x08)
[ec 6c 63:6a bb 6c]
80636798-8063679a 3 bytes - nt!MiVerifierThunks+90 (+0x08)
[d8 6c 63:76 bb 6c]
806367a0-806367a2 3 bytes - nt!MiVerifierThunks+98 (+0x08)
[c4 6c 63:88 bb 6c]
806367a8-806367aa 3 bytes - nt!MiVerifierThunks+a0 (+0x08)
[a4 6c 63:27 1f 51]
806367b0-806367b2 3 bytes - nt!MiVerifierThunks+a8 (+0x08)
[84 6c 63:2b 1f 51]
806367b8-806367ba 3 bytes - nt!MiVerifierThunks+b0 (+0x08)
[6c 6c 63:dc b8 4e]
806367c0-806367c2 3 bytes - nt!MiVerifierThunks+b8 (+0x08)
[58 6c 63:22 62 4f]
806367c8-806367ca 3 bytes - nt!MiVerifierThunks+c0 (+0x08)
[44 6c 63:14 62 4f]
806367d0-806367d2 3 bytes - nt!MiVerifierThunks+c8 (+0x08)
[2c 6c 63:2b c8 4e]
806367d8-806367da 3 bytes - nt!MiVerifierThunks+d0 (+0x08)
[20 6c 63:70 7f 6c]
806367e0-806367e2 3 bytes - nt!MiVerifierThunks+d8 (+0x08)
[08 6c 63:ac 7f 6c]
806367e8-806367ea 3 bytes - nt!MiVerifierThunks+e0 (+0x08)
[fc 6b 63:e0 7f 6c]
806367f0-806367f2 3 bytes - nt!MiVerifierThunks+e8 (+0x08)
[e8 6b 63:28 80 6c]
806367f8-806367fa 3 bytes - nt!MiVerifierThunks+f0 (+0x08)
[d4 6b 63:50 80 6c]
80636800-80636802 3 bytes - nt!MiVerifierThunks+f8 (+0x08)
[c8 6b 63:bb c9 4e]
80636808-8063680a 3 bytes - nt!MiVerifierThunks+100 (+0x08)
[b8 6b 63:50 d8 4e]
80636810-80636812 3 bytes - nt!MiVerifierThunks+108 (+0x08)
[a4 6b 63:9d d7 4e]
80636818-8063681a 3 bytes - nt!MiVerifierThunks+110 (+0x08)
[84 6b 63:74 52 4e]
80636820-80636822 3 bytes - nt!MiVerifierThunks+118 (+0x08)
[64 6b 63:56 d8 4e]
80636828-8063682a 3 bytes - nt!MiVerifierThunks+120 (+0x08)
[50 6b 63:dc 65 5b]
80636830-80636832 3 bytes - nt!MiVerifierThunks+128 (+0x08)
[34 6b 63:3c c8 6c]
80636838-8063683a 3 bytes - nt!MiVerifierThunks+130 (+0x08)
[24 6b 63:a4 c0 56]
80636840-80636842 3 bytes - nt!MiVerifierThunks+138 (+0x08)
[04 6b 63:bc a1 6c]
80636848-8063684a 3 bytes - nt!MiVerifierThunks+140 (+0x08)
[e8 6a 63:ee e7 57]
80636850-80636852 3 bytes - nt!MiVerifierThunks+148 (+0x08)
[d8 6a 63:ad ce 4e]
80636858-8063685a 3 bytes - nt!MiVerifierThunks+150 (+0x08)
[c4 6a 63:8b 1d 4e]
80636860-80636862 3 bytes - nt!MiVerifierThunks+158 (+0x08)
[b4 6a 63:4b c5 4e]
80636868-8063686a 3 bytes - nt!MiVerifierThunks+160 (+0x08)
[a0 6a 63:d2 92 4f]
80636870-80636872 3 bytes - nt!MiVerifierThunks+168 (+0x08)
[88 6a 63:1a 1f 51]
80636878-8063687a 3 bytes - nt!MiVerifierThunks+170 (+0x08)
[78 6a 63:a4 1f 6d]
80636880-80636882 3 bytes - nt!MiVerifierThunks+178 (+0x08)
[68 6a 63:c0 a8 6c]
80636888-8063688a 3 bytes - nt!MiVerifierThunks+180 (+0x08)
[50 6a 63:28 a9 6c]
80636890-80636892 3 bytes - nt!MiVerifierThunks+188 (+0x08)
[38 6a 63:1c 97 6c]
WARNING: !chkimg output was truncated to 50 lines. Invoke !chkimg without
‘-lo [num_lines]’ to view entire output.
293 errors : !nt (804da0ce-8063690a)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

MEMORY_CORRUPTOR: LARGE

STACK_COMMAND: kb

FAILURE_BUCKET_ID: MEMORY_CORRUPTION_LARGE

BUCKET_ID: MEMORY_CORRUPTION_LARGE

Followup: memory_corruption

“J.Wilkes” wrote in message
news:xxxxx@ntdev…
> Søren Dreijer wrote:
> > Hi,
> >
> > I’m one lucky guy. My NDIS miniport driver has started spitting out
> > DRIVER_IRQL_NOT_LESS_OR_EQUAL exceptions.
> >
> > I know it is my driver that causes the system to do a bugcheck, but
viewing
> > the crash dump doesn’t reveal anything of what went wrong. Windows can’t
> > even identify which driver was the culprit.
>
> IMHO, it’s likely to be a system call you make. Check the parts of your
code
> running at DISPATCH_LEVEL for calls to functions which need a lower IRQL
(like
> PASSIVE_LEVEL).
> It could be waiting for an event etc as well, but thats essentially the
same
> thing: at DISPATCH_LEVEL, you may not block (wait).
>
> You’ll find the information about the functions and their respective IRQL
inside
> the SDK documentation. Some introduction to IRQL and similar topics can be
found
> at http://msdn.microsoft.com/library/en-us/dndevice/html/IRQL_Sched.asp
>
> Since you wrote you’re new to driver development, I think you should start
with
> this. Detailled debugging will help finding the exact cause of the
bluescreen,
> but above is something you’ll need to know and take care of in any case.
>
> HTH
>
>

S?ren Dreijer wrote:

Thanks for the quick reply both!

While waiting for replies I enabled the driver verifier on my driver and I
got the crash analysis shown below.

Some more information: The driver is currently copying packets which are
transmittted on it to a user-mode application. The latter issues
asynchronous read requests to the driver, which are completed whenever a
packet is received.
Furthermore, packets can be “injected” from user-mode. That is, the
user-mode application can write packets to the driver, which then indicates
up that it has “received” a packet from the network.

Hi S?ren,

I think Loren had a good hunch on this one, it really looks like a
buffer overflow. How do you “inject” packets from user-mode ? Buffered,
direct or neither ?

By the way do you start all the functions that you assume to run at
PASSIVE_LEVEL with the macro PAGED_CODE()? It helps a lot. It sure
helped me a lot with my drivers.

Edouard

Update:

It appears the problem occurs when calling WriteFile() from user-mode to
write a packet to the driver.

When I commented out the code in the driver which indicates up to NDIS that
a packet has been received, the bug check didn’t occur.

I’m using direct I/O to transfer the data to the driver. In the code below
‘pPacket’ points to address returned from MmGetSystemAddressForMdlSafe(). I
*am* making sure that ‘pPacket’ isn’t NULL.


NdisMEthIndicateReceive(pAdapter->hAdapterHandle,
pAdapter,
pPacket,
ETH_HEADER_SIZE,
pPacket + ETH_HEADER_SIZE,

pIrpStack->Parameters.Write.Length -
ETH_HEADER_SIZE,

pIrpStack->Parameters.Write.Length -
ETH_HEADER_SIZE);

// Indicate that the entire packet has been received
NdisMEthIndicateReceiveComplete(pAdapter->hAdapterHandle);

“Søren Dreijer” wrote in message news:xxxxx@ntdev…
> Thanks for the quick reply both!
>
> While waiting for replies I enabled the driver verifier on my driver and I
> got the crash analysis shown below.
>
> Some more information: The driver is currently copying packets which are
> transmittted on it to a user-mode application. The latter issues
> asynchronous read requests to the driver, which are completed whenever a
> packet is received.
> Furthermore, packets can be “injected” from user-mode. That is, the
> user-mode application can write packets to the driver, which then
indicates
> up that it has “received” a packet from the network.
>
> Thanks,
> ---------------------------------------------------------------
>
> 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: 81767e08, 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: 81767e08
>
> DRIVER_OBJECT: 816b31e0
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> FAULTING_MODULE: 00000000
>
> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>
> BUGCHECK_STR: 0xC9
>
> LAST_CONTROL_TRANSFER: from 80647152 to 805266db
>
> STACK_TEXT:
> f6111c38 80647152 000000c9 00000005 81767e08 nt!KeBugCheckEx+0x19
> f6111c70 8058b076 82aa2fd8 00000000 82aa2f68 nt!IovCallDriver+0xdf
> f6111c84 8058dfc2 81767e08 82aa2f68 81632d28
> nt!IopSynchronousServiceTail+0x5e
> f6111d38 804da140 00000720 00000714 00000000 nt!NtWriteFile+0x5de
> f6111d38 7ffe0304 00000720 00000714 00000000 nt!KiSystemService+0xc4
> 01a5fa08 00000000 00000000 00000000 00000000
> SharedUserData!SystemCallStub+0x4
>
>
> CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
> 804da0ce-804da0d2 5 bytes - nt!KiSystemService+52
> [0f 85 d6 fe ff:e9 f4 8f 17 01]
> 804da151-804da155 5 bytes - nt!KiServiceExit (+0x83)
> [fa f7 45 70 00:e9 8d 8f 17 01]
> 804da23d-804da241 5 bytes - nt!KiSystemCallExitBranch+2 (+0xec)
> [5a 59 9d ff e2:e9 11 07 29 01]
> 804da2f1-804da2f5 5 bytes - nt!KiServiceExit2 (+0xb4)
> [fa f7 45 70 00:e9 44 8e 17 01]
> 804da937-804da93b 5 bytes - nt!KiExceptionExit (+0x646)
> [fa f7 45 70 00:e9 c4 87 17 01]
> 804dcc36-804dcc3b 6 bytes - nt!KiTrap0E+90 (+0x22ff)
> [fb f7 45 70 00 02:90 e9 e1 64 17 01]
> 804eca47-804eca4b 5 bytes - nt!ExAcquireResourceSharedLite+f
(+0xfe11)
> [fa 8b 75 08 33:e9 60 66 16 01]
> 804ecab7-804ecabb 5 bytes - nt!ExReleaseResourceLite+d (+0x70)
> [fa 8b 55 fc f6:e9 98 65 16 01]
> 804ecbb5-804ecbb9 5 bytes - nt!ExAcquireResourceExclusiveLite+5
(+0xfe)
> [64 a1 24 01 00:e9 b7 64 16 01]
> 804ecbd6-804ecbda 5 bytes - nt!ExAcquireResourceExclusiveLite+45
> (+0x21)
> [89 46 1c 66 89:e9 b4 64 16 01]
> 804f5129-804f512d 5 bytes - nt!ExIsResourceAcquiredExclusiveLite+6
> (+0x8553)
> [fa 8b 4c 24 04:e9 83 e0 15 01]
> 805025ec-805025ef 4 bytes - nt!KiServiceTable+64 (+0xd4c3)
> [55 13 58 80:28 50 fc ba]
> 8050262c-8050262f 4 bytes - nt!KiServiceTable+a4 (+0x40)
> [2e aa 57 80:e0 4f fc ba]
> 8050263c-8050263f 4 bytes - nt!KiServiceTable+b4 (+0x10)
> [a0 b7 5a 80:00 8b fb ba]
> 805026a4-805026a7 4 bytes - nt!KiServiceTable+11c (+0x68)
> [23 d3 57 80:dc 95 fb ba]
> 805026ac-805026af 4 bytes - nt!KiServiceTable+124 (+0x08)
> [f7 a5 56 80:20 51 fc ba]
> 80502758-8050275b 4 bytes - nt!KiServiceTable+1d0 (+0xac)
> [33 52 58 80:40 8b fb ba]
> 80502764-80502767 4 bytes - nt!KiServiceTable+1dc (+0x0c)
> [2f 27 58 80:a4 4f fc ba]
> 80502808-8050280b 4 bytes - nt!KiServiceTable+280 (+0xa4)
> [60 34 57 80:fc 95 fb ba]
> 8050284c-8050284f 4 bytes - nt!KiServiceTable+2c4 (+0x44)
> [fb 33 58 80:76 50 fc ba]
> 8050294c-8050294f 4 bytes - nt!KiServiceTable+3c4 (+0x100)
> [4c 2b 64 80:50 45 fc ba]
> 805120ca-805120ce 5 bytes - nt!KeUpdateSystemTime+114 (+0xf77e)
> [fa ff 15 dc 45:e9 68 11 14 01]
> 80636708-8063670a 3 bytes - nt!MiVerifierThunks
> [5c 6e 63:17 bf 4e]
> 80636710-80636712 3 bytes - nt!MiVerifierThunks+8 (+0x08)
> [40 6e 63:bc 28 51]
> 80636718-8063671a 3 bytes - nt!MiVerifierThunks+10 (+0x08)
> [24 6e 63:da 28 51]
> 80636720-80636722 3 bytes - nt!MiVerifierThunks+18 (+0x08)
> [04 6e 63:b0 cb 4e]
> 80636728-8063672a 3 bytes - nt!MiVerifierThunks+20 (+0x08)
> [ec 6d 63:aa ca 4e]
> 80636730-80636732 3 bytes - nt!MiVerifierThunks+28 (+0x08)
> [d8 6d 63:4e e4 4e]
> 80636738-8063673a 3 bytes - nt!MiVerifierThunks+30 (+0x08)
> [bc 6d 63:0c 6c 5c]
> 80636740-80636742 3 bytes - nt!MiVerifierThunks+38 (+0x08)
> [ac 6d 63:2f 9e 50]
> 80636748-8063674a 3 bytes - nt!MiVerifierThunks+40 (+0x08)
> [98 6d 63:55 f0 4f]
> 80636750-80636752 3 bytes - nt!MiVerifierThunks+48 (+0x08)
> [78 6d 63:2a d0 4e]
> 80636758-8063675a 3 bytes - nt!MiVerifierThunks+50 (+0x08)
> [68 6d 63:ce e6 4e]
> 80636760-80636762 3 bytes - nt!MiVerifierThunks+58 (+0x08)
> [54 6d 63:a3 d7 4e]
> 80636768-8063676a 3 bytes - nt!MiVerifierThunks+60 (+0x08)
> [44 6d 63:5c 9f 50]
> 80636770-80636772 3 bytes - nt!MiVerifierThunks+68 (+0x08)
> [30 6d 63:98 80 6c]
> 80636778-8063677a 3 bytes - nt!MiVerifierThunks+70 (+0x08)
> [18 6d 63:c8 80 6c]
> 80636780-80636782 3 bytes - nt!MiVerifierThunks+78 (+0x08)
> [04 6d 63:f8 80 6c]
> 80636788-8063678a 3 bytes - nt!MiVerifierThunks+80 (+0x08)
> [f8 6c 63:58 bb 6c]
> 80636790-80636792 3 bytes - nt!MiVerifierThunks+88 (+0x08)
> [ec 6c 63:6a bb 6c]
> 80636798-8063679a 3 bytes - nt!MiVerifierThunks+90 (+0x08)
> [d8 6c 63:76 bb 6c]
> 806367a0-806367a2 3 bytes - nt!MiVerifierThunks+98 (+0x08)
> [c4 6c 63:88 bb 6c]
> 806367a8-806367aa 3 bytes - nt!MiVerifierThunks+a0 (+0x08)
> [a4 6c 63:27 1f 51]
> 806367b0-806367b2 3 bytes - nt!MiVerifierThunks+a8 (+0x08)
> [84 6c 63:2b 1f 51]
> 806367b8-806367ba 3 bytes - nt!MiVerifierThunks+b0 (+0x08)
> [6c 6c 63:dc b8 4e]
> 806367c0-806367c2 3 bytes - nt!MiVerifierThunks+b8 (+0x08)
> [58 6c 63:22 62 4f]
> 806367c8-806367ca 3 bytes - nt!MiVerifierThunks+c0 (+0x08)
> [44 6c 63:14 62 4f]
> 806367d0-806367d2 3 bytes - nt!MiVerifierThunks+c8 (+0x08)
> [2c 6c 63:2b c8 4e]
> 806367d8-806367da 3 bytes - nt!MiVerifierThunks+d0 (+0x08)
> [20 6c 63:70 7f 6c]
> 806367e0-806367e2 3 bytes - nt!MiVerifierThunks+d8 (+0x08)
> [08 6c 63:ac 7f 6c]
> 806367e8-806367ea 3 bytes - nt!MiVerifierThunks+e0 (+0x08)
> [fc 6b 63:e0 7f 6c]
> 806367f0-806367f2 3 bytes - nt!MiVerifierThunks+e8 (+0x08)
> [e8 6b 63:28 80 6c]
> 806367f8-806367fa 3 bytes - nt!MiVerifierThunks+f0 (+0x08)
> [d4 6b 63:50 80 6c]
> 80636800-80636802 3 bytes - nt!MiVerifierThunks+f8 (+0x08)
> [c8 6b 63:bb c9 4e]
> 80636808-8063680a 3 bytes - nt!MiVerifierThunks+100 (+0x08)
> [b8 6b 63:50 d8 4e]
> 80636810-80636812 3 bytes - nt!MiVerifierThunks+108 (+0x08)
> [a4 6b 63:9d d7 4e]
> 80636818-8063681a 3 bytes - nt!MiVerifierThunks+110 (+0x08)
> [84 6b 63:74 52 4e]
> 80636820-80636822 3 bytes - nt!MiVerifierThunks+118 (+0x08)
> [64 6b 63:56 d8 4e]
> 80636828-8063682a 3 bytes - nt!MiVerifierThunks+120 (+0x08)
> [50 6b 63:dc 65 5b]
> 80636830-80636832 3 bytes - nt!MiVerifierThunks+128 (+0x08)
> [34 6b 63:3c c8 6c]
> 80636838-8063683a 3 bytes - nt!MiVerifierThunks+130 (+0x08)
> [24 6b 63:a4 c0 56]
> 80636840-80636842 3 bytes - nt!MiVerifierThunks+138 (+0x08)
> [04 6b 63:bc a1 6c]
> 80636848-8063684a 3 bytes - nt!MiVerifierThunks+140 (+0x08)
> [e8 6a 63:ee e7 57]
> 80636850-80636852 3 bytes - nt!MiVerifierThunks+148 (+0x08)
> [d8 6a 63:ad ce 4e]
> 80636858-8063685a 3 bytes - nt!MiVerifierThunks+150 (+0x08)
> [c4 6a 63:8b 1d 4e]
> 80636860-80636862 3 bytes - nt!MiVerifierThunks+158 (+0x08)
> [b4 6a 63:4b c5 4e]
> 80636868-8063686a 3 bytes - nt!MiVerifierThunks+160 (+0x08)
> [a0 6a 63:d2 92 4f]
> 80636870-80636872 3 bytes - nt!MiVerifierThunks+168 (+0x08)
> [88 6a 63:1a 1f 51]
> 80636878-8063687a 3 bytes - nt!MiVerifierThunks+170 (+0x08)
> [78 6a 63:a4 1f 6d]
> 80636880-80636882 3 bytes - nt!MiVerifierThunks+178 (+0x08)
> [68 6a 63:c0 a8 6c]
> 80636888-8063688a 3 bytes - nt!MiVerifierThunks+180 (+0x08)
> [50 6a 63:28 a9 6c]
> 80636890-80636892 3 bytes - nt!MiVerifierThunks+188 (+0x08)
> [38 6a 63:1c 97 6c]
> WARNING: !chkimg output was truncated to 50 lines. Invoke !chkimg without
> ‘-lo [num_lines]’ to view entire output.
> 293 errors : !nt (804da0ce-8063690a)
>
> MODULE_NAME: memory_corruption
>
> IMAGE_NAME: memory_corruption
>
> FOLLOWUP_NAME: memory_corruption
>
> MEMORY_CORRUPTOR: LARGE
>
> STACK_COMMAND: kb
>
> FAILURE_BUCKET_ID: MEMORY_CORRUPTION_LARGE
>
> BUCKET_ID: MEMORY_CORRUPTION_LARGE
>
> Followup: memory_corruption
>
>
> “J.Wilkes” wrote in message
> news:xxxxx@ntdev…
> > Søren Dreijer wrote:
> > > Hi,
> > >
> > > I’m one lucky guy. My NDIS miniport driver has started spitting out
> > > DRIVER_IRQL_NOT_LESS_OR_EQUAL exceptions.
> > >
> > > I know it is my driver that causes the system to do a bugcheck, but
> viewing
> > > the crash dump doesn’t reveal anything of what went wrong. Windows
can’t
> > > even identify which driver was the culprit.
> >
> > IMHO, it’s likely to be a system call you make. Check the parts of your
> code
> > running at DISPATCH_LEVEL for calls to functions which need a lower IRQL
> (like
> > PASSIVE_LEVEL).
> > It could be waiting for an event etc as well, but thats essentially the
> same
> > thing: at DISPATCH_LEVEL, you may not block (wait).
> >
> > You’ll find the information about the functions and their respective
IRQL
> inside
> > the SDK documentation. Some introduction to IRQL and similar topics can
be
> found
> > at http://msdn.microsoft.com/library/en-us/dndevice/html/IRQL_Sched.asp
> >
> > Since you wrote you’re new to driver development, I think you should
start
> with
> > this. Detailled debugging will help finding the exact cause of the
> bluescreen,
> > but above is something you’ll need to know and take care of in any case.
> >
> > HTH
> >
> >
>
>
>

Hi Edouard,

How do you “inject” packets from user-mode ? Buffered, direct or neither ?
Check the entry I just posted.

By the way do you start all the functions that you assume to run at
PASSIVE_LEVEL with the macro PAGED_CODE()? It helps a lot. It sure
helped me a lot with my drivers.
I only use it on some of my functions. How is it going to help me?

Thanks,

“Edouard A.” wrote in message
news:xxxxx@ntdev…
Søren Dreijer wrote:
> Thanks for the quick reply both!
>
> While waiting for replies I enabled the driver verifier on my driver and I
> got the crash analysis shown below.
>
> Some more information: The driver is currently copying packets which are
> transmittted on it to a user-mode application. The latter issues
> asynchronous read requests to the driver, which are completed whenever a
> packet is received.
> Furthermore, packets can be “injected” from user-mode. That is, the
> user-mode application can write packets to the driver, which then
indicates
> up that it has “received” a packet from the network.

Hi Søren,

I think Loren had a good hunch on this one, it really looks like a
buffer overflow. How do you “inject” packets from user-mode ? Buffered,
direct or neither ?

By the way do you start all the functions that you assume to run at
PASSIVE_LEVEL with the macro PAGED_CODE()? It helps a lot. It sure
helped me a lot with my drivers.



Edouard

What is interesting is that the memory referenced and the address which
referenced the memory are both the same. That seems to indicate some kind of
memory corruption?
“Søren Dreijer” wrote in message news:xxxxx@ntdev…
> Hi,
>
> I’m one lucky guy. My NDIS miniport driver has started spitting out
> DRIVER_IRQL_NOT_LESS_OR_EQUAL exceptions.
>
> I know it is my driver that causes the system to do a bugcheck, but
> viewing
> the crash dump doesn’t reveal anything of what went wrong. Windows can’t
> even identify which driver was the culprit.
>
> As I am still relatively new to driver development, I have no idea of how
> to
> go about identifying the exact cause of the bug check, hence why I am
> turning to you guys.
> Below I have inserted part of the crash dump report generated by WinDbg.
>
> I hope you have some ideas on what I can do to identify the problem.
>
> Thanks!
>
> ---------------------------------------------------------
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> An attempt was made to access a pageable (or completely invalid) address
> at
> an
> interrupt request level (IRQL) that is too high. This is usually
> caused by drivers using improper addresses.
> If kernel debugger is available get stack backtrace.
> Arguments:
> Arg1: 71a5d7a8, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: 71a5d7a8, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 71a5d7a8
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> +71a5d7a8
> 71a5d7a8 ?? ???
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> LAST_CONTROL_TRANSFER: from 804dce53 to 805266db
>
> TRAP_FRAME: f626bd64 – (.trap fffffffff626bd64)
> ErrCode = 00000004
> eax=00000000 ebx=01a5fb9c ecx=00000000 edx=7ffe0304 esi=01a5fd7c
> edi=00000e18
> eip=71a5d7a8 esp=01a5fb34 ebp=01a5fc00 iopl=0 nv up ei pl nz na pe
> nc
> cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
> efl=00010202
> 001b:71a5d7a8 ?? ???
> Resetting default scope
>
> STACK_TEXT:
> f626bd48 804dce53 0000000a 71a5d7a8 00000002 nt!KeBugCheckEx+0x19
> f626bd48 71a5d7a8 0000000a 71a5d7a8 00000002 nt!KiTrap0E+0x2ad
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 01a5fc00 00000000 00000000 00000000 00000000 0x71a5d7a8
>
>
> FAILED_INSTRUCTION_ADDRESS:
> +71a5d7a8
> 71a5d7a8 ?? ???
>
> FOLLOWUP_IP:
> nt!KiTrap0E+2ad
> 804dce53 cc int 3
>
> SYMBOL_STACK_INDEX: 1
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: nt!KiTrap0E+2ad
>
> IMAGE_NAME: Unknown_Image
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> STACK_COMMAND: kb
>
> BUCKET_ID: RAISED_IRQL_USER_FAULT
>
> MODULE_NAME: Unknown_Module
>
> Followup: MachineOwner
>
>
>

Yeah, I’ve been wondering the same thing…

“Mayank Ajmera” wrote in message news:xxxxx@ntdev…
> What is interesting is that the memory referenced and the address which
> referenced the memory are both the same. That seems to indicate some kind
of
> memory corruption?
> “Søren Dreijer” wrote in message news:xxxxx@ntdev…
> > Hi,
> >
> > I’m one lucky guy. My NDIS miniport driver has started spitting out
> > DRIVER_IRQL_NOT_LESS_OR_EQUAL exceptions.
> >
> > I know it is my driver that causes the system to do a bugcheck, but
> > viewing
> > the crash dump doesn’t reveal anything of what went wrong. Windows can’t
> > even identify which driver was the culprit.
> >
> > As I am still relatively new to driver development, I have no idea of
how
> > to
> > go about identifying the exact cause of the bug check, hence why I am
> > turning to you guys.
> > Below I have inserted part of the crash dump report generated by WinDbg.
> >
> > I hope you have some ideas on what I can do to identify the problem.
> >
> > Thanks!
> >
> > ---------------------------------------------------------
> >
> > DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> > An attempt was made to access a pageable (or completely invalid) address
> > at
> > an
> > interrupt request level (IRQL) that is too high. This is usually
> > caused by drivers using improper addresses.
> > If kernel debugger is available get stack backtrace.
> > Arguments:
> > Arg1: 71a5d7a8, memory referenced
> > Arg2: 00000002, IRQL
> > Arg3: 00000000, value 0 = read operation, 1 = write operation
> > Arg4: 71a5d7a8, address which referenced memory
> >
> > Debugging Details:
> > ------------------
> >
> >
> > READ_ADDRESS: 71a5d7a8
> >
> > CURRENT_IRQL: 2
> >
> > FAULTING_IP:
> > +71a5d7a8
> > 71a5d7a8 ?? ???
> >
> > DEFAULT_BUCKET_ID: DRIVER_FAULT
> >
> > BUGCHECK_STR: 0xD1
> >
> > LAST_CONTROL_TRANSFER: from 804dce53 to 805266db
> >
> > TRAP_FRAME: f626bd64 – (.trap fffffffff626bd64)
> > ErrCode = 00000004
> > eax=00000000 ebx=01a5fb9c ecx=00000000 edx=7ffe0304 esi=01a5fd7c
> > edi=00000e18
> > eip=71a5d7a8 esp=01a5fb34 ebp=01a5fc00 iopl=0 nv up ei pl nz na
pe
> > nc
> > cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
> > efl=00010202
> > 001b:71a5d7a8 ?? ???
> > Resetting default scope
> >
> > STACK_TEXT:
> > f626bd48 804dce53 0000000a 71a5d7a8 00000002 nt!KeBugCheckEx+0x19
> > f626bd48 71a5d7a8 0000000a 71a5d7a8 00000002 nt!KiTrap0E+0x2ad
> > WARNING: Frame IP not in any known module. Following frames may be
wrong.
> > 01a5fc00 00000000 00000000 00000000 00000000 0x71a5d7a8
> >
> >
> > FAILED_INSTRUCTION_ADDRESS:
> > +71a5d7a8
> > 71a5d7a8 ?? ???
> >
> > FOLLOWUP_IP:
> > nt!KiTrap0E+2ad
> > 804dce53 cc int 3
> >
> > SYMBOL_STACK_INDEX: 1
> >
> > FOLLOWUP_NAME: MachineOwner
> >
> > SYMBOL_NAME: nt!KiTrap0E+2ad
> >
> > IMAGE_NAME: Unknown_Image
> >
> > DEBUG_FLR_IMAGE_TIMESTAMP: 0
> >
> > STACK_COMMAND: kb
> >
> > BUCKET_ID: RAISED_IRQL_USER_FAULT
> >
> > MODULE_NAME: Unknown_Module
> >
> > Followup: MachineOwner
> >
> >
> >
>
>
>

S?ren Dreijer wrote:

Update:

It appears the problem occurs when calling WriteFile() from user-mode to
write a packet to the driver.

When I commented out the code in the driver which indicates up to NDIS that
a packet has been received, the bug check didn’t occur.

I’m using direct I/O to transfer the data to the driver. In the code below
‘pPacket’ points to address returned from MmGetSystemAddressForMdlSafe(). I
*am* making sure that ‘pPacket’ isn’t NULL.


NdisMEthIndicateReceive(pAdapter->hAdapterHandle,
pAdapter,
pPacket,
ETH_HEADER_SIZE,
pPacket + ETH_HEADER_SIZE,

pIrpStack->Parameters.Write.Length -
ETH_HEADER_SIZE,

pIrpStack->Parameters.Write.Length -
ETH_HEADER_SIZE);

What happens if (pIrpStack->Parameters.Write.Length < ETH_HEADER_SIZE) ?

> By the way do you start all the functions that you assume to run at
> >PASSIVE_LEVEL with the macro PAGED_CODE()? It helps a lot. It sure
> >helped me a lot with my drivers.
I only use it on some of my functions. How is it going to help me?

Well it will assert if you execute your code in a non-pageable context.
It will also force you to ask yourself, for every function your write
“In which context may my code run ?”. There is not a single function
that doesn’t have an assertion related to the IRQL in my code, unless
that function may run at any level. I think it’s a good habit.

EA

Update:
Hmm, this is getting more and more weird. It seems I can successfully write
to the driver several times before the bugcheck occurs. And might I add, the
number of times vary.

Currently, the dead-certain approach to crash the driver is to send down an
ARP packet targeted for the driver’s adapter.
The crash dump is practically identical between every crash.

What happens if (pIrpStack->Parameters.Write.Length < ETH_HEADER_SIZE) ?
I already check for that, seems not to be the error.

Well it will assert if you execute your code in a non-pageable context.
It will also force you to ask yourself, for every function your write
“In which context may my code run ?”. There is not a single function
that doesn’t have an assertion related to the IRQL in my code, unless
that function may run at any level. I think it’s a good habit.
Yeah, I agree. As I’m still new to driver development I’m just afraid of
indicating a function as pagable if it isn’t. But I guess that’s what it’s
all about really… understanding what will happen when the code is executed.

“Edouard A.” wrote in message
news:xxxxx@ntdev…
Søren Dreijer wrote:
> Update:
>
> It appears the problem occurs when calling WriteFile() from user-mode to
> write a packet to the driver.
>
> When I commented out the code in the driver which indicates up to NDIS
that
> a packet has been received, the bug check didn’t occur.
>
> I’m using direct I/O to transfer the data to the driver. In the code below
> ‘pPacket’ points to address returned from MmGetSystemAddressForMdlSafe().
I
> am making sure that ‘pPacket’ isn’t NULL.
>
> -----------------------------------------------
> NdisMEthIndicateReceive(pAdapter->hAdapterHandle,
> pAdapter,
> pPacket,
> ETH_HEADER_SIZE,
> pPacket + ETH_HEADER_SIZE,
>
>
>
pIrpStack->Parameters.Write.Length -
> ETH_HEADER_SIZE,
>
>
>
pIrpStack->Parameters.Write.Length -
> ETH_HEADER_SIZE);

What happens if (pIrpStack->Parameters.Write.Length < ETH_HEADER_SIZE) ?

>> By the way do you start all the functions that you assume to run at
>> >PASSIVE_LEVEL with the macro PAGED_CODE()? It helps a lot. It sure
>> >helped me a lot with my drivers.
>I only use it on some of my functions. How is it going to help me?

Well it will assert if you execute your code in a non-pageable context.
It will also force you to ask yourself, for every function your write
“In which context may my code run ?”. There is not a single function
that doesn’t have an assertion related to the IRQL in my code, unless
that function may run at any level. I think it’s a good habit.



EA

Update:
I tried manually calling the write-method 128 times in a row without
problems.

The crash dumps still don’t indicate that my driver is at fault. Instead the
stack trace reveals:

f6604c38 80647152 000000c9 00000005 81666800 nt!KeBugCheckEx+0x19
f6604c70 8058b076 82086fd8 00000000 82086f68 nt!IovCallDriver+0xdf
f6604c84 8058dfc2 81666800 82086f68 ff964218
nt!IopSynchronousServiceTail+0x5e
f6604d38 804da140 00000f2c 00000f24 00000000 nt!NtWriteFile+0x5de
f6604d38 7ffe0304 00000f2c 00000f24 00000000 nt!KiSystemService+0xc4
01b8fa00 00000000 00000000 00000000 00000000
SharedUserData!SystemCallStub+0x4

So the problem is definitely upon calling WriteFile(). I just don’t
understand what is triggering the bug check…

–Soren

“Søren Dreijer” wrote in message news:xxxxx@ntdev…
> Update:
> Hmm, this is getting more and more weird. It seems I can successfully
write
> to the driver several times before the bugcheck occurs. And might I add,
the
> number of times vary.
>
> Currently, the dead-certain approach to crash the driver is to send down
an
> ARP packet targeted for the driver’s adapter.
> The crash dump is practically identical between every crash.
>
> >What happens if (pIrpStack->Parameters.Write.Length < ETH_HEADER_SIZE) ?
> I already check for that, seems not to be the error.
>
> >Well it will assert if you execute your code in a non-pageable context.
> >It will also force you to ask yourself, for every function your write
> >“In which context may my code run ?”. There is not a single function
> >that doesn’t have an assertion related to the IRQL in my code, unless
> >that function may run at any level. I think it’s a good habit.
> Yeah, I agree. As I’m still new to driver development I’m just afraid of
> indicating a function as pagable if it isn’t. But I guess that’s what it’s
> all about really… understanding what will happen when the code is
executed.
>
>
> “Edouard A.” wrote in message
> news:xxxxx@ntdev…
> Søren Dreijer wrote:
> > Update:
> >
> > It appears the problem occurs when calling WriteFile() from user-mode to
> > write a packet to the driver.
> >
> > When I commented out the code in the driver which indicates up to NDIS
> that
> > a packet has been received, the bug check didn’t occur.
> >
> > I’m using direct I/O to transfer the data to the driver. In the code
below
> > ‘pPacket’ points to address returned from
MmGetSystemAddressForMdlSafe().
> I
> > am making sure that ‘pPacket’ isn’t NULL.
> >
> > -----------------------------------------------
> > NdisMEthIndicateReceive(pAdapter->hAdapterHandle,
> > pAdapter,
> > pPacket,
> > ETH_HEADER_SIZE,
> > pPacket + ETH_HEADER_SIZE,
> >
> >
> >
>
pIrpStack->Parameters.Write.Length -
> > ETH_HEADER_SIZE,
> >
> >
> >
>
pIrpStack->Parameters.Write.Length -
> > ETH_HEADER_SIZE);
>
>
> What happens if (pIrpStack->Parameters.Write.Length < ETH_HEADER_SIZE) ?
>
> >> By the way do you start all the functions that you assume to run at
> >> >PASSIVE_LEVEL with the macro PAGED_CODE()? It helps a lot. It sure
> >> >helped me a lot with my drivers.
> >I only use it on some of my functions. How is it going to help me?
>
> Well it will assert if you execute your code in a non-pageable context.
> It will also force you to ask yourself, for every function your write
> “In which context may my code run ?”. There is not a single function
> that doesn’t have an assertion related to the IRQL in my code, unless
> that function may run at any level. I think it’s a good habit.
>
> –
>
> EA
>
>
>
>

S?ren Dreijer wrote:

Update:
I tried manually calling the write-method 128 times in a row without
problems.

The crash dumps still don’t indicate that my driver is at fault. Instead the
stack trace reveals:

f6604c38 80647152 000000c9 00000005 81666800 nt!KeBugCheckEx+0x19
f6604c70 8058b076 82086fd8 00000000 82086f68 nt!IovCallDriver+0xdf
f6604c84 8058dfc2 81666800 82086f68 ff964218
nt!IopSynchronousServiceTail+0x5e
f6604d38 804da140 00000f2c 00000f24 00000000 nt!NtWriteFile+0x5de
f6604d38 7ffe0304 00000f2c 00000f24 00000000 nt!KiSystemService+0xc4
01b8fa00 00000000 00000000 00000000 00000000
SharedUserData!SystemCallStub+0x4

So the problem is definitely upon calling WriteFile(). I just don’t
understand what is triggering the bug check…

Are you allocating memory with ExAllocatePoolWithTag() ? If yes, is the
ascii value of each character in the tag between 0 and 127 ? If not,
this could corrupt the pool.

EA

The tag I use when allocating memory during initialization of the driver is
‘1VBL’. Shouldn’t cause any problems…

“Edouard A.” wrote in message
news:xxxxx@ntdev…
Søren Dreijer wrote:
> Update:
> I tried manually calling the write-method 128 times in a row without
> problems.
>
> The crash dumps still don’t indicate that my driver is at fault. Instead
the
> stack trace reveals:
>
> f6604c38 80647152 000000c9 00000005 81666800 nt!KeBugCheckEx+0x19
> f6604c70 8058b076 82086fd8 00000000 82086f68 nt!IovCallDriver+0xdf
> f6604c84 8058dfc2 81666800 82086f68 ff964218
> nt!IopSynchronousServiceTail+0x5e
> f6604d38 804da140 00000f2c 00000f24 00000000 nt!NtWriteFile+0x5de
> f6604d38 7ffe0304 00000f2c 00000f24 00000000 nt!KiSystemService+0xc4
> 01b8fa00 00000000 00000000 00000000 00000000
> SharedUserData!SystemCallStub+0x4
>
> So the problem is definitely upon calling WriteFile(). I just don’t
> understand what is triggering the bug check…

Are you allocating memory with ExAllocatePoolWithTag() ? If yes, is the
ascii value of each character in the tag between 0 and 127 ? If not,
this could corrupt the pool.



EA

Whenever I see that the memory referenced is identical to the address which referenced memory, it tells me that I have pageable code that tried to run at a higher IRQL. You should verify that all code that uses a spin lock, or can be called at a higher IRQL than passive is non-paged.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of S?ren Dreijer
Sent: Saturday, February 25, 2006 6:08 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Debugging DRIVER_IRQL_NOT_LESS_OR_EQUAL

Hi,

I’m one lucky guy. My NDIS miniport driver has started spitting out
DRIVER_IRQL_NOT_LESS_OR_EQUAL exceptions.

I know it is my driver that causes the system to do a bugcheck, but viewing
the crash dump doesn’t reveal anything of what went wrong. Windows can’t
even identify which driver was the culprit.

As I am still relatively new to driver development, I have no idea of how to
go about identifying the exact cause of the bug check, hence why I am
turning to you guys.
Below I have inserted part of the crash dump report generated by WinDbg.

I hope you have some ideas on what I can do to identify the problem.

Thanks!


DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 71a5d7a8, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 71a5d7a8, address which referenced memory

Debugging Details:

READ_ADDRESS: 71a5d7a8

CURRENT_IRQL: 2

FAULTING_IP:
+71a5d7a8
71a5d7a8 ?? ???

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 804dce53 to 805266db

TRAP_FRAME: f626bd64 – (.trap fffffffff626bd64)
ErrCode = 00000004
eax=00000000 ebx=01a5fb9c ecx=00000000 edx=7ffe0304 esi=01a5fd7c
edi=00000e18
eip=71a5d7a8 esp=01a5fb34 ebp=01a5fc00 iopl=0 nv up ei pl nz na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
efl=00010202
001b:71a5d7a8 ?? ???
Resetting default scope

STACK_TEXT:
f626bd48 804dce53 0000000a 71a5d7a8 00000002 nt!KeBugCheckEx+0x19
f626bd48 71a5d7a8 0000000a 71a5d7a8 00000002 nt!KiTrap0E+0x2ad
WARNING: Frame IP not in any known module. Following frames may be wrong.
01a5fc00 00000000 00000000 00000000 00000000 0x71a5d7a8

FAILED_INSTRUCTION_ADDRESS:
+71a5d7a8
71a5d7a8 ?? ???

FOLLOWUP_IP:
nt!KiTrap0E+2ad
804dce53 cc int 3

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!KiTrap0E+2ad

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: kb

BUCKET_ID: RAISED_IRQL_USER_FAULT

MODULE_NAME: Unknown_Module

Followup: MachineOwner


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

Actually it almost always indicates trying to access paged code at raised IRQL.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mayank Ajmera
Sent: Saturday, February 25, 2006 8:40 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Debugging DRIVER_IRQL_NOT_LESS_OR_EQUAL

What is interesting is that the memory referenced and the address which
referenced the memory are both the same. That seems to indicate some kind of
memory corruption?
“S?ren Dreijer” wrote in message news:xxxxx@ntdev…
> Hi,
>
> I’m one lucky guy. My NDIS miniport driver has started spitting out
> DRIVER_IRQL_NOT_LESS_OR_EQUAL exceptions.
>
> I know it is my driver that causes the system to do a bugcheck, but
> viewing
> the crash dump doesn’t reveal anything of what went wrong. Windows can’t
> even identify which driver was the culprit.
>
> As I am still relatively new to driver development, I have no idea of how
> to
> go about identifying the exact cause of the bug check, hence why I am
> turning to you guys.
> Below I have inserted part of the crash dump report generated by WinDbg.
>
> I hope you have some ideas on what I can do to identify the problem.
>
> Thanks!
>
> ---------------------------------------------------------
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> An attempt was made to access a pageable (or completely invalid) address
> at
> an
> interrupt request level (IRQL) that is too high. This is usually
> caused by drivers using improper addresses.
> If kernel debugger is available get stack backtrace.
> Arguments:
> Arg1: 71a5d7a8, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: 71a5d7a8, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 71a5d7a8
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> +71a5d7a8
> 71a5d7a8 ?? ???
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> LAST_CONTROL_TRANSFER: from 804dce53 to 805266db
>
> TRAP_FRAME: f626bd64 – (.trap fffffffff626bd64)
> ErrCode = 00000004
> eax=00000000 ebx=01a5fb9c ecx=00000000 edx=7ffe0304 esi=01a5fd7c
> edi=00000e18
> eip=71a5d7a8 esp=01a5fb34 ebp=01a5fc00 iopl=0 nv up ei pl nz na pe
> nc
> cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
> efl=00010202
> 001b:71a5d7a8 ?? ???
> Resetting default scope
>
> STACK_TEXT:
> f626bd48 804dce53 0000000a 71a5d7a8 00000002 nt!KeBugCheckEx+0x19
> f626bd48 71a5d7a8 0000000a 71a5d7a8 00000002 nt!KiTrap0E+0x2ad
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 01a5fc00 00000000 00000000 00000000 00000000 0x71a5d7a8
>
>
> FAILED_INSTRUCTION_ADDRESS:
> +71a5d7a8
> 71a5d7a8 ?? ???
>
> FOLLOWUP_IP:
> nt!KiTrap0E+2ad
> 804dce53 cc int 3
>
> SYMBOL_STACK_INDEX: 1
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: nt!KiTrap0E+2ad
>
> IMAGE_NAME: Unknown_Image
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> STACK_COMMAND: kb
>
> BUCKET_ID: RAISED_IRQL_USER_FAULT
>
> MODULE_NAME: Unknown_Module
>
> Followup: MachineOwner
>
>
>


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

I’ll dig into it.

Thanks!

“Randy Aull” wrote in message
news:xxxxx@ntdev…
Whenever I see that the memory referenced is identical to the address which
referenced memory, it tells me that I have pageable code that tried to run
at a higher IRQL. You should verify that all code that uses a spin lock, or
can be called at a higher IRQL than passive is non-paged.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Søren Dreijer
Sent: Saturday, February 25, 2006 6:08 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Debugging DRIVER_IRQL_NOT_LESS_OR_EQUAL

Hi,

I’m one lucky guy. My NDIS miniport driver has started spitting out
DRIVER_IRQL_NOT_LESS_OR_EQUAL exceptions.

I know it is my driver that causes the system to do a bugcheck, but viewing
the crash dump doesn’t reveal anything of what went wrong. Windows can’t
even identify which driver was the culprit.

As I am still relatively new to driver development, I have no idea of how to
go about identifying the exact cause of the bug check, hence why I am
turning to you guys.
Below I have inserted part of the crash dump report generated by WinDbg.

I hope you have some ideas on what I can do to identify the problem.

Thanks!

---------------------------------------------------------

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 71a5d7a8, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 71a5d7a8, address which referenced memory

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

READ_ADDRESS: 71a5d7a8

CURRENT_IRQL: 2

FAULTING_IP:
+71a5d7a8
71a5d7a8 ?? ???

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 804dce53 to 805266db

TRAP_FRAME: f626bd64 – (.trap fffffffff626bd64)
ErrCode = 00000004
eax=00000000 ebx=01a5fb9c ecx=00000000 edx=7ffe0304 esi=01a5fd7c
edi=00000e18
eip=71a5d7a8 esp=01a5fb34 ebp=01a5fc00 iopl=0 nv up ei pl nz na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
efl=00010202
001b:71a5d7a8 ?? ???
Resetting default scope

STACK_TEXT:
f626bd48 804dce53 0000000a 71a5d7a8 00000002 nt!KeBugCheckEx+0x19
f626bd48 71a5d7a8 0000000a 71a5d7a8 00000002 nt!KiTrap0E+0x2ad
WARNING: Frame IP not in any known module. Following frames may be wrong.
01a5fc00 00000000 00000000 00000000 00000000 0x71a5d7a8

FAILED_INSTRUCTION_ADDRESS:
+71a5d7a8
71a5d7a8 ?? ???

FOLLOWUP_IP:
nt!KiTrap0E+2ad
804dce53 cc int 3

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!KiTrap0E+2ad

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: kb

BUCKET_ID: RAISED_IRQL_USER_FAULT

MODULE_NAME: Unknown_Module

Followup: MachineOwner


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

The most common reason for the driver verifier complaining this way is that
you take a lock and do not release it properly. This would also explain
your earlier crash, since if your driver exits with IRQL 2 DISPATCH_LEVEL
and the code expects IRQL 0 PASSIVE_LEVEL it will crash with the
DRIVER_IRQL_NOT_LESS_THAN_OR_EQUAL


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Søren Dreijer” wrote in message news:xxxxx@ntdev…
> Thanks for the quick reply both!
>
> While waiting for replies I enabled the driver verifier on my driver and I
> got the crash analysis shown below.
>
> Some more information: The driver is currently copying packets which are
> transmittted on it to a user-mode application. The latter issues
> asynchronous read requests to the driver, which are completed whenever a
> packet is received.
> Furthermore, packets can be “injected” from user-mode. That is, the
> user-mode application can write packets to the driver, which then
> indicates
> up that it has “received” a packet from the network.
>
> Thanks,
> ---------------------------------------------------------------
>
> 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: 81767e08, 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: 81767e08
>
> DRIVER_OBJECT: 816b31e0
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> FAULTING_MODULE: 00000000
>
> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>
> BUGCHECK_STR: 0xC9
>
> LAST_CONTROL_TRANSFER: from 80647152 to 805266db
>
> STACK_TEXT:
> f6111c38 80647152 000000c9 00000005 81767e08 nt!KeBugCheckEx+0x19
> f6111c70 8058b076 82aa2fd8 00000000 82aa2f68 nt!IovCallDriver+0xdf
> f6111c84 8058dfc2 81767e08 82aa2f68 81632d28
> nt!IopSynchronousServiceTail+0x5e
> f6111d38 804da140 00000720 00000714 00000000 nt!NtWriteFile+0x5de
> f6111d38 7ffe0304 00000720 00000714 00000000 nt!KiSystemService+0xc4
> 01a5fa08 00000000 00000000 00000000 00000000
> SharedUserData!SystemCallStub+0x4
>
>
> CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
> 804da0ce-804da0d2 5 bytes - nt!KiSystemService+52
> [0f 85 d6 fe ff:e9 f4 8f 17 01]
> 804da151-804da155 5 bytes - nt!KiServiceExit (+0x83)
> [fa f7 45 70 00:e9 8d 8f 17 01]
> 804da23d-804da241 5 bytes - nt!KiSystemCallExitBranch+2 (+0xec)
> [5a 59 9d ff e2:e9 11 07 29 01]
> 804da2f1-804da2f5 5 bytes - nt!KiServiceExit2 (+0xb4)
> [fa f7 45 70 00:e9 44 8e 17 01]
> 804da937-804da93b 5 bytes - nt!KiExceptionExit (+0x646)
> [fa f7 45 70 00:e9 c4 87 17 01]
> 804dcc36-804dcc3b 6 bytes - nt!KiTrap0E+90 (+0x22ff)
> [fb f7 45 70 00 02:90 e9 e1 64 17 01]
> 804eca47-804eca4b 5 bytes - nt!ExAcquireResourceSharedLite+f (+0xfe11)
> [fa 8b 75 08 33:e9 60 66 16 01]
> 804ecab7-804ecabb 5 bytes - nt!ExReleaseResourceLite+d (+0x70)
> [fa 8b 55 fc f6:e9 98 65 16 01]
> 804ecbb5-804ecbb9 5 bytes - nt!ExAcquireResourceExclusiveLite+5
> (+0xfe)
> [64 a1 24 01 00:e9 b7 64 16 01]
> 804ecbd6-804ecbda 5 bytes - nt!ExAcquireResourceExclusiveLite+45
> (+0x21)
> [89 46 1c 66 89:e9 b4 64 16 01]
> 804f5129-804f512d 5 bytes - nt!ExIsResourceAcquiredExclusiveLite+6
> (+0x8553)
> [fa 8b 4c 24 04:e9 83 e0 15 01]
> 805025ec-805025ef 4 bytes - nt!KiServiceTable+64 (+0xd4c3)
> [55 13 58 80:28 50 fc ba]
> 8050262c-8050262f 4 bytes - nt!KiServiceTable+a4 (+0x40)
> [2e aa 57 80:e0 4f fc ba]
> 8050263c-8050263f 4 bytes - nt!KiServiceTable+b4 (+0x10)
> [a0 b7 5a 80:00 8b fb ba]
> 805026a4-805026a7 4 bytes - nt!KiServiceTable+11c (+0x68)
> [23 d3 57 80:dc 95 fb ba]
> 805026ac-805026af 4 bytes - nt!KiServiceTable+124 (+0x08)
> [f7 a5 56 80:20 51 fc ba]
> 80502758-8050275b 4 bytes - nt!KiServiceTable+1d0 (+0xac)
> [33 52 58 80:40 8b fb ba]
> 80502764-80502767 4 bytes - nt!KiServiceTable+1dc (+0x0c)
> [2f 27 58 80:a4 4f fc ba]
> 80502808-8050280b 4 bytes - nt!KiServiceTable+280 (+0xa4)
> [60 34 57 80:fc 95 fb ba]
> 8050284c-8050284f 4 bytes - nt!KiServiceTable+2c4 (+0x44)
> [fb 33 58 80:76 50 fc ba]
> 8050294c-8050294f 4 bytes - nt!KiServiceTable+3c4 (+0x100)
> [4c 2b 64 80:50 45 fc ba]
> 805120ca-805120ce 5 bytes - nt!KeUpdateSystemTime+114 (+0xf77e)
> [fa ff 15 dc 45:e9 68 11 14 01]
> 80636708-8063670a 3 bytes - nt!MiVerifierThunks
> [5c 6e 63:17 bf 4e]
> 80636710-80636712 3 bytes - nt!MiVerifierThunks+8 (+0x08)
> [40 6e 63:bc 28 51]
> 80636718-8063671a 3 bytes - nt!MiVerifierThunks+10 (+0x08)
> [24 6e 63:da 28 51]
> 80636720-80636722 3 bytes - nt!MiVerifierThunks+18 (+0x08)
> [04 6e 63:b0 cb 4e]
> 80636728-8063672a 3 bytes - nt!MiVerifierThunks+20 (+0x08)
> [ec 6d 63:aa ca 4e]
> 80636730-80636732 3 bytes - nt!MiVerifierThunks+28 (+0x08)
> [d8 6d 63:4e e4 4e]
> 80636738-8063673a 3 bytes - nt!MiVerifierThunks+30 (+0x08)
> [bc 6d 63:0c 6c 5c]
> 80636740-80636742 3 bytes - nt!MiVerifierThunks+38 (+0x08)
> [ac 6d 63:2f 9e 50]
> 80636748-8063674a 3 bytes - nt!MiVerifierThunks+40 (+0x08)
> [98 6d 63:55 f0 4f]
> 80636750-80636752 3 bytes - nt!MiVerifierThunks+48 (+0x08)
> [78 6d 63:2a d0 4e]
> 80636758-8063675a 3 bytes - nt!MiVerifierThunks+50 (+0x08)
> [68 6d 63:ce e6 4e]
> 80636760-80636762 3 bytes - nt!MiVerifierThunks+58 (+0x08)
> [54 6d 63:a3 d7 4e]
> 80636768-8063676a 3 bytes - nt!MiVerifierThunks+60 (+0x08)
> [44 6d 63:5c 9f 50]
> 80636770-80636772 3 bytes - nt!MiVerifierThunks+68 (+0x08)
> [30 6d 63:98 80 6c]
> 80636778-8063677a 3 bytes - nt!MiVerifierThunks+70 (+0x08)
> [18 6d 63:c8 80 6c]
> 80636780-80636782 3 bytes - nt!MiVerifierThunks+78 (+0x08)
> [04 6d 63:f8 80 6c]
> 80636788-8063678a 3 bytes - nt!MiVerifierThunks+80 (+0x08)
> [f8 6c 63:58 bb 6c]
> 80636790-80636792 3 bytes - nt!MiVerifierThunks+88 (+0x08)
> [ec 6c 63:6a bb 6c]
> 80636798-8063679a 3 bytes - nt!MiVerifierThunks+90 (+0x08)
> [d8 6c 63:76 bb 6c]
> 806367a0-806367a2 3 bytes - nt!MiVerifierThunks+98 (+0x08)
> [c4 6c 63:88 bb 6c]
> 806367a8-806367aa 3 bytes - nt!MiVerifierThunks+a0 (+0x08)
> [a4 6c 63:27 1f 51]
> 806367b0-806367b2 3 bytes - nt!MiVerifierThunks+a8 (+0x08)
> [84 6c 63:2b 1f 51]
> 806367b8-806367ba 3 bytes - nt!MiVerifierThunks+b0 (+0x08)
> [6c 6c 63:dc b8 4e]
> 806367c0-806367c2 3 bytes - nt!MiVerifierThunks+b8 (+0x08)
> [58 6c 63:22 62 4f]
> 806367c8-806367ca 3 bytes - nt!MiVerifierThunks+c0 (+0x08)
> [44 6c 63:14 62 4f]
> 806367d0-806367d2 3 bytes - nt!MiVerifierThunks+c8 (+0x08)
> [2c 6c 63:2b c8 4e]
> 806367d8-806367da 3 bytes - nt!MiVerifierThunks+d0 (+0x08)
> [20 6c 63:70 7f 6c]
> 806367e0-806367e2 3 bytes - nt!MiVerifierThunks+d8 (+0x08)
> [08 6c 63:ac 7f 6c]
> 806367e8-806367ea 3 bytes - nt!MiVerifierThunks+e0 (+0x08)
> [fc 6b 63:e0 7f 6c]
> 806367f0-806367f2 3 bytes - nt!MiVerifierThunks+e8 (+0x08)
> [e8 6b 63:28 80 6c]
> 806367f8-806367fa 3 bytes - nt!MiVerifierThunks+f0 (+0x08)
> [d4 6b 63:50 80 6c]
> 80636800-80636802 3 bytes - nt!MiVerifierThunks+f8 (+0x08)
> [c8 6b 63:bb c9 4e]
> 80636808-8063680a 3 bytes - nt!MiVerifierThunks+100 (+0x08)
> [b8 6b 63:50 d8 4e]
> 80636810-80636812 3 bytes - nt!MiVerifierThunks+108 (+0x08)
> [a4 6b 63:9d d7 4e]
> 80636818-8063681a 3 bytes - nt!MiVerifierThunks+110 (+0x08)
> [84 6b 63:74 52 4e]
> 80636820-80636822 3 bytes - nt!MiVerifierThunks+118 (+0x08)
> [64 6b 63:56 d8 4e]
> 80636828-8063682a 3 bytes - nt!MiVerifierThunks+120 (+0x08)
> [50 6b 63:dc 65 5b]
> 80636830-80636832 3 bytes - nt!MiVerifierThunks+128 (+0x08)
> [34 6b 63:3c c8 6c]
> 80636838-8063683a 3 bytes - nt!MiVerifierThunks+130 (+0x08)
> [24 6b 63:a4 c0 56]
> 80636840-80636842 3 bytes - nt!MiVerifierThunks+138 (+0x08)
> [04 6b 63:bc a1 6c]
> 80636848-8063684a 3 bytes - nt!MiVerifierThunks+140 (+0x08)
> [e8 6a 63:ee e7 57]
> 80636850-80636852 3 bytes - nt!MiVerifierThunks+148 (+0x08)
> [d8 6a 63:ad ce 4e]
> 80636858-8063685a 3 bytes - nt!MiVerifierThunks+150 (+0x08)
> [c4 6a 63:8b 1d 4e]
> 80636860-80636862 3 bytes - nt!MiVerifierThunks+158 (+0x08)
> [b4 6a 63:4b c5 4e]
> 80636868-8063686a 3 bytes - nt!MiVerifierThunks+160 (+0x08)
> [a0 6a 63:d2 92 4f]
> 80636870-80636872 3 bytes - nt!MiVerifierThunks+168 (+0x08)
> [88 6a 63:1a 1f 51]
> 80636878-8063687a 3 bytes - nt!MiVerifierThunks+170 (+0x08)
> [78 6a 63:a4 1f 6d]
> 80636880-80636882 3 bytes - nt!MiVerifierThunks+178 (+0x08)
> [68 6a 63:c0 a8 6c]
> 80636888-8063688a 3 bytes - nt!MiVerifierThunks+180 (+0x08)
> [50 6a 63:28 a9 6c]
> 80636890-80636892 3 bytes - nt!MiVerifierThunks+188 (+0x08)
> [38 6a 63:1c 97 6c]
> WARNING: !chkimg output was truncated to 50 lines. Invoke !chkimg without
> ‘-lo [num_lines]’ to view entire output.
> 293 errors : !nt (804da0ce-8063690a)
>
> MODULE_NAME: memory_corruption
>
> IMAGE_NAME: memory_corruption
>
> FOLLOWUP_NAME: memory_corruption
>
> MEMORY_CORRUPTOR: LARGE
>
> STACK_COMMAND: kb
>
> FAILURE_BUCKET_ID: MEMORY_CORRUPTION_LARGE
>
> BUCKET_ID: MEMORY_CORRUPTION_LARGE
>
> Followup: memory_corruption
>
>
> “J.Wilkes” wrote in message
> news:xxxxx@ntdev…
>> Søren Dreijer wrote:
>> > Hi,
>> >
>> > I’m one lucky guy. My NDIS miniport driver has started spitting out
>> > DRIVER_IRQL_NOT_LESS_OR_EQUAL exceptions.
>> >
>> > I know it is my driver that causes the system to do a bugcheck, but
> viewing
>> > the crash dump doesn’t reveal anything of what went wrong. Windows
>> > can’t
>> > even identify which driver was the culprit.
>>
>> IMHO, it’s likely to be a system call you make. Check the parts of your
> code
>> running at DISPATCH_LEVEL for calls to functions which need a lower IRQL
> (like
>> PASSIVE_LEVEL).
>> It could be waiting for an event etc as well, but thats essentially the
> same
>> thing: at DISPATCH_LEVEL, you may not block (wait).
>>
>> You’ll find the information about the functions and their respective IRQL
> inside
>> the SDK documentation. Some introduction to IRQL and similar topics can
>> be
> found
>> at http://msdn.microsoft.com/library/en-us/dndevice/html/IRQL_Sched.asp
>>
>> Since you wrote you’re new to driver development, I think you should
>> start
> with
>> this. Detailled debugging will help finding the exact cause of the
> bluescreen,
>> but above is something you’ll need to know and take care of in any case.
>>
>> HTH
>>
>>
>
>
>

So, the lock could just as well be a lock from another routine which aren’t
released upon routine exit?

In the Write Dispatch routine I do hold a lock, but I also free it after
use. Just for clarity, I’ve shown the entire write request routine below. It
is called by the dispatch routine.

And might I add, this bug is driving me nuts! I can write several packets
successfully to the driver without a hint of a problem. And then suddenly,
everytime I attempt to write the aforementioned ARP request packet, the
system crashes…


NDIS_STATUS NICProcessWriteRequest(PIRP pIrp)
{
NDIS_STATUS status = STATUS_SUCCESS;
PNIC_ADAPTER pAdapter;
PUCHAR pPacket;
PIO_STACK_LOCATION pIrpStack;

DBGPRINT(LB_ENABLE, (“—> NICProcessWriteRequest()\n”));

pIrpStack = IoGetCurrentIrpStackLocation(pIrp);

do
{
if (pIrpStack->Parameters.Write.Length == 0)
{
DBGPRINT(LB_ENABLE, (“Cannot process write request. Input buffer is of
invalid length.\n”));
status = STATUS_INVALID_PARAMETER;
break;
}
else if (pIrpStack->Parameters.Write.Length < ETH_HEADER_SIZE)
{
DBGPRINT(LB_ENABLE, (“Cannot process write request. Input buffer is too
small.\n”));
status = STATUS_INVALID_PARAMETER;
break;
}
else if ((pPacket = GetDirectIoBuffer(pIrp)) == NULL)
{
status = pIrp->IoStatus.Status; // The status field of the IRP is set in
GetDirectIoBuffer()
break;
}

NdisAcquireSpinLock(&g_globalData.adapterLock);

pAdapter = g_globalData.pAdapter;

NdisMEthIndicateReceive(pAdapter->hAdapterHandle,
pAdapter,
pPacket,
ETH_HEADER_SIZE,
pPacket + ETH_HEADER_SIZE,
pIrpStack->Parameters.Write.Length - ETH_HEADER_SIZE,
pIrpStack->Parameters.Write.Length - ETH_HEADER_SIZE);

// Indicate that the entire packet has been received
NdisMEthIndicateReceiveComplete(pAdapter->hAdapterHandle);

NdisReleaseSpinLock(&g_globalData.adapterLock);

DBGPRINT(LB_ENABLE, (“Indicated up that packet was received (%d
bytes).\n”, pIrpStack->Parameters.Write.Length));

} while (FALSE);

DBGPRINT(LB_ENABLE, (“<— NICProcessWriteRequest() with status code
0x%08X\n”, status));

return status;
}

“Don Burn” wrote in message news:xxxxx@ntdev…
> The most common reason for the driver verifier complaining this way is
that
> you take a lock and do not release it properly. This would also explain
> your earlier crash, since if your driver exits with IRQL 2 DISPATCH_LEVEL
> and the code expects IRQL 0 PASSIVE_LEVEL it will crash with the
> DRIVER_IRQL_NOT_LESS_THAN_OR_EQUAL
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
> “Søren Dreijer” wrote in message news:xxxxx@ntdev…
> > Thanks for the quick reply both!
> >
> > While waiting for replies I enabled the driver verifier on my driver and
I
> > got the crash analysis shown below.
> >
> > Some more information: The driver is currently copying packets which are
> > transmittted on it to a user-mode application. The latter issues
> > asynchronous read requests to the driver, which are completed whenever a
> > packet is received.
> > Furthermore, packets can be “injected” from user-mode. That is, the
> > user-mode application can write packets to the driver, which then
> > indicates
> > up that it has “received” a packet from the network.
> >
> > Thanks,
> > ---------------------------------------------------------------
> >
> > 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: 81767e08, 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: 81767e08
> >
> > DRIVER_OBJECT: 816b31e0
> >
> > DEBUG_FLR_IMAGE_TIMESTAMP: 0
> >
> > FAULTING_MODULE: 00000000
> >
> > DEFAULT_BUCKET_ID: CODE_CORRUPTION
> >
> > BUGCHECK_STR: 0xC9
> >
> > LAST_CONTROL_TRANSFER: from 80647152 to 805266db
> >
> > STACK_TEXT:
> > f6111c38 80647152 000000c9 00000005 81767e08 nt!KeBugCheckEx+0x19
> > f6111c70 8058b076 82aa2fd8 00000000 82aa2f68 nt!IovCallDriver+0xdf
> > f6111c84 8058dfc2 81767e08 82aa2f68 81632d28
> > nt!IopSynchronousServiceTail+0x5e
> > f6111d38 804da140 00000720 00000714 00000000 nt!NtWriteFile+0x5de
> > f6111d38 7ffe0304 00000720 00000714 00000000 nt!KiSystemService+0xc4
> > 01a5fa08 00000000 00000000 00000000 00000000
> > SharedUserData!SystemCallStub+0x4
> >
> >
> > CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
> > 804da0ce-804da0d2 5 bytes - nt!KiSystemService+52
> > [0f 85 d6 fe ff:e9 f4 8f 17 01]
> > 804da151-804da155 5 bytes - nt!KiServiceExit (+0x83)
> > [fa f7 45 70 00:e9 8d 8f 17 01]
> > 804da23d-804da241 5 bytes - nt!KiSystemCallExitBranch+2 (+0xec)
> > [5a 59 9d ff e2:e9 11 07 29 01]
> > 804da2f1-804da2f5 5 bytes - nt!KiServiceExit2 (+0xb4)
> > [fa f7 45 70 00:e9 44 8e 17 01]
> > 804da937-804da93b 5 bytes - nt!KiExceptionExit (+0x646)
> > [fa f7 45 70 00:e9 c4 87 17 01]
> > 804dcc36-804dcc3b 6 bytes - nt!KiTrap0E+90 (+0x22ff)
> > [fb f7 45 70 00 02:90 e9 e1 64 17 01]
> > 804eca47-804eca4b 5 bytes - nt!ExAcquireResourceSharedLite+f
(+0xfe11)
> > [fa 8b 75 08 33:e9 60 66 16 01]
> > 804ecab7-804ecabb 5 bytes - nt!ExReleaseResourceLite+d (+0x70)
> > [fa 8b 55 fc f6:e9 98 65 16 01]
> > 804ecbb5-804ecbb9 5 bytes - nt!ExAcquireResourceExclusiveLite+5
> > (+0xfe)
> > [64 a1 24 01 00:e9 b7 64 16 01]
> > 804ecbd6-804ecbda 5 bytes - nt!ExAcquireResourceExclusiveLite+45
> > (+0x21)
> > [89 46 1c 66 89:e9 b4 64 16 01]
> > 804f5129-804f512d 5 bytes - nt!ExIsResourceAcquiredExclusiveLite+6
> > (+0x8553)
> > [fa 8b 4c 24 04:e9 83 e0 15 01]
> > 805025ec-805025ef 4 bytes - nt!KiServiceTable+64 (+0xd4c3)
> > [55 13 58 80:28 50 fc ba]
> > 8050262c-8050262f 4 bytes - nt!KiServiceTable+a4 (+0x40)
> > [2e aa 57 80:e0 4f fc ba]
> > 8050263c-8050263f 4 bytes - nt!KiServiceTable+b4 (+0x10)
> > [a0 b7 5a 80:00 8b fb ba]
> > 805026a4-805026a7 4 bytes - nt!KiServiceTable+11c (+0x68)
> > [23 d3 57 80:dc 95 fb ba]
> > 805026ac-805026af 4 bytes - nt!KiServiceTable+124 (+0x08)
> > [f7 a5 56 80:20 51 fc ba]
> > 80502758-8050275b 4 bytes - nt!KiServiceTable+1d0 (+0xac)
> > [33 52 58 80:40 8b fb ba]
> > 80502764-80502767 4 bytes - nt!KiServiceTable+1dc (+0x0c)
> > [2f 27 58 80:a4 4f fc ba]
> > 80502808-8050280b 4 bytes - nt!KiServiceTable+280 (+0xa4)
> > [60 34 57 80:fc 95 fb ba]
> > 8050284c-8050284f 4 bytes - nt!KiServiceTable+2c4 (+0x44)
> > [fb 33 58 80:76 50 fc ba]
> > 8050294c-8050294f 4 bytes - nt!KiServiceTable+3c4 (+0x100)
> > [4c 2b 64 80:50 45 fc ba]
> > 805120ca-805120ce 5 bytes - nt!KeUpdateSystemTime+114 (+0xf77e)
> > [fa ff 15 dc 45:e9 68 11 14 01]
> > 80636708-8063670a 3 bytes - nt!MiVerifierThunks
> > [5c 6e 63:17 bf 4e]
> > 80636710-80636712 3 bytes - nt!MiVerifierThunks+8 (+0x08)
> > [40 6e 63:bc 28 51]
> > 80636718-8063671a 3 bytes - nt!MiVerifierThunks+10 (+0x08)
> > [24 6e 63:da 28 51]
> > 80636720-80636722 3 bytes - nt!MiVerifierThunks+18 (+0x08)
> > [04 6e 63:b0 cb 4e]
> > 80636728-8063672a 3 bytes - nt!MiVerifierThunks+20 (+0x08)
> > [ec 6d 63:aa ca 4e]
> > 80636730-80636732 3 bytes - nt!MiVerifierThunks+28 (+0x08)
> > [d8 6d 63:4e e4 4e]
> > 80636738-8063673a 3 bytes - nt!MiVerifierThunks+30 (+0x08)
> > [bc 6d 63:0c 6c 5c]
> > 80636740-80636742 3 bytes - nt!MiVerifierThunks+38 (+0x08)
> > [ac 6d 63:2f 9e 50]
> > 80636748-8063674a 3 bytes - nt!MiVerifierThunks+40 (+0x08)
> > [98 6d 63:55 f0 4f]
> > 80636750-80636752 3 bytes - nt!MiVerifierThunks+48 (+0x08)
> > [78 6d 63:2a d0 4e]
> > 80636758-8063675a 3 bytes - nt!MiVerifierThunks+50 (+0x08)
> > [68 6d 63:ce e6 4e]
> > 80636760-80636762 3 bytes - nt!MiVerifierThunks+58 (+0x08)
> > [54 6d 63:a3 d7 4e]
> > 80636768-8063676a 3 bytes - nt!MiVerifierThunks+60 (+0x08)
> > [44 6d 63:5c 9f 50]
> > 80636770-80636772 3 bytes - nt!MiVerifierThunks+68 (+0x08)
> > [30 6d 63:98 80 6c]
> > 80636778-8063677a 3 bytes - nt!MiVerifierThunks+70 (+0x08)
> > [18 6d 63:c8 80 6c]
> > 80636780-80636782 3 bytes - nt!MiVerifierThunks+78 (+0x08)
> > [04 6d 63:f8 80 6c]
> > 80636788-8063678a 3 bytes - nt!MiVerifierThunks+80 (+0x08)
> > [f8 6c 63:58 bb 6c]
> > 80636790-80636792 3 bytes - nt!MiVerifierThunks+88 (+0x08)
> > [ec 6c 63:6a bb 6c]
> > 80636798-8063679a 3 bytes - nt!MiVerifierThunks+90 (+0x08)
> > [d8 6c 63:76 bb 6c]
> > 806367a0-806367a2 3 bytes - nt!MiVerifierThunks+98 (+0x08)
> > [c4 6c 63:88 bb 6c]
> > 806367a8-806367aa 3 bytes - nt!MiVerifierThunks+a0 (+0x08)
> > [a4 6c 63:27 1f 51]
> > 806367b0-806367b2 3 bytes - nt!MiVerifierThunks+a8 (+0x08)
> > [84 6c 63:2b 1f 51]
> > 806367b8-806367ba 3 bytes - nt!MiVerifierThunks+b0 (+0x08)
> > [6c 6c 63:dc b8 4e]
> > 806367c0-806367c2 3 bytes - nt!MiVerifierThunks+b8 (+0x08)
> > [58 6c 63:22 62 4f]
> > 806367c8-806367ca 3 bytes - nt!MiVerifierThunks+c0 (+0x08)
> > [44 6c 63:14 62 4f]
> > 806367d0-806367d2 3 bytes - nt!MiVerifierThunks+c8 (+0x08)
> > [2c 6c 63:2b c8 4e]
> > 806367d8-806367da 3 bytes - nt!MiVerifierThunks+d0 (+0x08)
> > [20 6c 63:70 7f 6c]
> > 806367e0-806367e2 3 bytes - nt!MiVerifierThunks+d8 (+0x08)
> > [08 6c 63:ac 7f 6c]
> > 806367e8-806367ea 3 bytes - nt!MiVerifierThunks+e0 (+0x08)
> > [fc 6b 63:e0 7f 6c]
> > 806367f0-806367f2 3 bytes - nt!MiVerifierThunks+e8 (+0x08)
> > [e8 6b 63:28 80 6c]
> > 806367f8-806367fa 3 bytes - nt!MiVerifierThunks+f0 (+0x08)
> > [d4 6b 63:50 80 6c]
> > 80636800-80636802 3 bytes - nt!MiVerifierThunks+f8 (+0x08)
> > [c8 6b 63:bb c9 4e]
> > 80636808-8063680a 3 bytes - nt!MiVerifierThunks+100 (+0x08)
> > [b8 6b 63:50 d8 4e]
> > 80636810-80636812 3 bytes - nt!MiVerifierThunks+108 (+0x08)
> > [a4 6b 63:9d d7 4e]
> > 80636818-8063681a 3 bytes - nt!MiVerifierThunks+110 (+0x08)
> > [84 6b 63:74 52 4e]
> > 80636820-80636822 3 bytes - nt!MiVerifierThunks+118 (+0x08)
> > [64 6b 63:56 d8 4e]
> > 80636828-8063682a 3 bytes - nt!MiVerifierThunks+120 (+0x08)
> > [50 6b 63:dc 65 5b]
> > 80636830-80636832 3 bytes - nt!MiVerifierThunks+128 (+0x08)
> > [34 6b 63:3c c8 6c]
> > 80636838-8063683a 3 bytes - nt!MiVerifierThunks+130 (+0x08)
> > [24 6b 63:a4 c0 56]
> > 80636840-80636842 3 bytes - nt!MiVerifierThunks+138 (+0x08)
> > [04 6b 63:bc a1 6c]
> > 80636848-8063684a 3 bytes - nt!MiVerifierThunks+140 (+0x08)
> > [e8 6a 63:ee e7 57]
> > 80636850-80636852 3 bytes - nt!MiVerifierThunks+148 (+0x08)
> > [d8 6a 63:ad ce 4e]
> > 80636858-8063685a 3 bytes - nt!MiVerifierThunks+150 (+0x08)
> > [c4 6a 63:8b 1d 4e]
> > 80636860-80636862 3 bytes - nt!MiVerifierThunks+158 (+0x08)
> > [b4 6a 63:4b c5 4e]
> > 80636868-8063686a 3 bytes - nt!MiVerifierThunks+160 (+0x08)
> > [a0 6a 63:d2 92 4f]
> > 80636870-80636872 3 bytes - nt!MiVerifierThunks+168 (+0x08)
> > [88 6a 63:1a 1f 51]
> > 80636878-8063687a 3 bytes - nt!MiVerifierThunks+170 (+0x08)
> > [78 6a 63:a4 1f 6d]
> > 80636880-80636882 3 bytes - nt!MiVerifierThunks+178 (+0x08)
> > [68 6a 63:c0 a8 6c]
> > 80636888-8063688a 3 bytes - nt!MiVerifierThunks+180 (+0x08)
> > [50 6a 63:28 a9 6c]
> > 80636890-80636892 3 bytes - nt!MiVerifierThunks+188 (+0x08)
> > [38 6a 63:1c 97 6c]
> > WARNING: !chkimg output was truncated to 50 lines. Invoke !chkimg
without
> > ‘-lo [num_lines]’ to view entire output.
> > 293 errors : !nt (804da0ce-8063690a)
> >
> > MODULE_NAME: memory_corruption
> >
> > IMAGE_NAME: memory_corruption
> >
> > FOLLOWUP_NAME: memory_corruption
> >
> > MEMORY_CORRUPTOR: LARGE
> >
> > STACK_COMMAND: kb
> >
> > FAILURE_BUCKET_ID: MEMORY_CORRUPTION_LARGE
> >
> > BUCKET_ID: MEMORY_CORRUPTION_LARGE
> >
> > Followup: memory_corruption
> >
> >
> > “J.Wilkes” wrote in message
> > news:xxxxx@ntdev…
> >> Søren Dreijer wrote:
> >> > Hi,
> >> >
> >> > I’m one lucky guy. My NDIS miniport driver has started spitting out
> >> > DRIVER_IRQL_NOT_LESS_OR_EQUAL exceptions.
> >> >
> >> > I know it is my driver that causes the system to do a bugcheck, but
> > viewing
> >> > the crash dump doesn’t reveal anything of what went wrong. Windows
> >> > can’t
> >> > even identify which driver was the culprit.
> >>
> >> IMHO, it’s likely to be a system call you make. Check the parts of your
> > code
> >> running at DISPATCH_LEVEL for calls to functions which need a lower
IRQL
> > (like
> >> PASSIVE_LEVEL).
> >> It could be waiting for an event etc as well, but thats essentially the
> > same
> >> thing: at DISPATCH_LEVEL, you may not block (wait).
> >>
> >> You’ll find the information about the functions and their respective
IRQL
> > inside
> >> the SDK documentation. Some introduction to IRQL and similar topics can
> >> be
> > found
> >> at http://msdn.microsoft.com/library/en-us/dndevice/html/IRQL_Sched.asp
> >>
> >> Since you wrote you’re new to driver development, I think you should
> >> start
> > with
> >> this. Detailled debugging will help finding the exact cause of the
> > bluescreen,
> >> but above is something you’ll need to know and take care of in any
case.
> >>
> >> HTH
> >>
> >>
> >
> >
> >
>
>
>

Below are extracts from working NDIS IM driver code (PCAUSA Packet
Redirector) that indicates user-mode packet “up the stack”. The missing
pieces aren’t really important.

In this particular implementation the user-mode app calls the driver at
IRP_MJ_WRITE and the I/O method is DO_BUFFERED_IO, which simplifies some
things.

No spin lock is in this path at all. Offhand, I don’t know why one would be
needed.

Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com

//
// Handle Writes On Virtual/Lower Adapter Differently
// --------------------------------------------------
// Virtual Adapter - Write data is indicated “up the stack” as if
// the data had been received from the network.
// Lower Adapter - Write data is sent “down the stack” to the lower
// MAC driver to be placed on the wire.
//
if( pW32NOpenContext->m_bIsVirtualAdapter )
{
NDIS_HANDLE MacReceiveContext = NULL;
PUCHAR HeaderBuffer;
UINT HeaderBufferSize;
PUCHAR LookAheadBuffer;
UINT LookAheadBufferSize;

HeaderBuffer = pIrp->AssociatedIrp.SystemBuffer;
HeaderBufferSize = pAdapt->HeaderSize;

LookAheadBuffer = &HeaderBuffer[HeaderBufferSize];
LookAheadBufferSize = TotalPacketLength - HeaderBufferSize;

switch( pAdapt->VirtualAdapterMediaType )
{
case NdisMedium802_3:
NdisMEthIndicateReceive(
pAdapt->MiniportHandle,
MacReceiveContext,
HeaderBuffer,
HeaderBufferSize,
LookAheadBuffer,
LookAheadBufferSize,
LookAheadBufferSize // PacketSize == LookAheadBufferSize
);
break;

case NdisMedium802_5:
NdisMTrIndicateReceive(
pAdapt->MiniportHandle,
MacReceiveContext,
HeaderBuffer,
HeaderBufferSize,
LookAheadBuffer,
LookAheadBufferSize,
LookAheadBufferSize // PacketSize == LookAheadBufferSize
);
break;

case NdisMediumFddi:
NdisMFddiIndicateReceive(
pAdapt->MiniportHandle,
MacReceiveContext,
HeaderBuffer,
HeaderBufferSize,
LookAheadBuffer,
LookAheadBufferSize,
LookAheadBufferSize // PacketSize == LookAheadBufferSize
);
break;

default:
ASSERT(0);
break;
}

CLReceiveComplete( (NDIS_HANDLE )pAdapt );

nBytesWritten = TotalPacketLength;

//
// Complete The IRP
//
pIrp->IoStatus.Status = Status;
pIrp->IoStatus.Information = nBytesWritten;

IoCompleteRequest(pIrp, IO_NETWORK_INCREMENT);

return( Status );
}
else
{
}