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
> >>
> >>
> >
> >
> >
>
>
>