views:

16

answers:

1

We are developing an NDIS protocol and miniport driver. When the driver is in-use and the system hibernates we get a bug check (blue screen) with the following error:

LOCKED_PAGES_TRACKER_CORRUPTION (d9)
Arguments:
Arg1: 00000001, The MDL is being inserted twice on the same process list.
Arg2: 875da420, Address of internal lock tracking structure.
Arg3: 87785728, Address of memory descriptor list.
Arg4: 00000013, Number of pages locked for the current process.

The stack trace is not especially helpful as our driver does not appear in the listing:

nt!RtlpBreakWithStatusInstruction
nt!KiBugCheckDebugBreak+0x19
nt!KeBugCheck2+0x574
nt!KeBugCheckEx+0x1b
nt!MiAddMdlTracker+0xd8
nt!MmProbeAndLockPages+0x629
nt!NtWriteFile+0x55c
nt!KiFastCallEntry+0xfc
ntdll!KiFastSystemCallRet
ntdll!ZwWriteFile+0xc
kernel32!WriteFile+0xa9

What types of issues could cause this MDL error?

+1  A: 

It turns out the problem was related to this code in our IRP_MJ_WRITE handler:

/* If not in D0 state, don't attempt transmits */
if (ndisProtocolOpenContext && 
    ndisProtocolOpenContext->powerState > NetDeviceStateD0)
{
   DEBUG_PRINT(("NPD: system in sleep mode, so no TX\n"));
   return STATUS_UNSUCCESSFUL;
}

This meant that we weren't fully completing the IRP and NDIS was likely doing something funny as a result. The addition of a call to IoCompleteRequest fixed the issue.

/* If not in D0 state, don't attempt transmits */
if (ndisProtocolOpenContext && 
    ndisProtocolOpenContext->powerState > NetDeviceStateD0)
{
   DEBUG_PRINT(("NPD: system in sleep mode, so no TX\n"));
   pIrp->IoStatus.Status = STATUS_UNSUCCESSFUL;
   IoCompleteRequest(pIrp, IO_NO_INCREMENT);
   return STATUS_UNSUCCESSFUL;
}
Tom