什么可能导致“MDL 在同一进程列表上插入两次”？

发布于 2024-09-15 10:50:30 字数 760 浏览 12 评论 0原文

我们正在开发 NDIS 协议和微型端口驱动程序。当驱动程序正在使用并且系统休眠时，我们会收到错误检查（蓝屏）并显示以下错误：

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.

堆栈跟踪不是特别有用，因为我们的驱动程序没有出现在列表中：

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

哪些类型的问题可能导致此 MDL错误？

原文

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?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

鹿童谣 2024-09-22 10:50:30

事实证明，问题与 IRP_MJ_WRITE 处理程序中的这段代码有关：

/* 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;
}

这意味着我们没有完全完成 IRP，因此 NDIS 可能会做一些有趣的事情。添加对 IoCompleteRequest 的调用解决了该问题。

/* 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;
}

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

回复收藏 0 原文

~没有更多了~