问题描述
我已经阅读了很多小时的关于这个主题的文章,并尝试了大量不同的策略,但无法使其以稳定的方式工作。
我在 Windows 内核中运行。我已经为一个进程分配了用户空间内存供他们使用。该内存需要是可执行的。我得到的最远的解决方案是遍历页表以找到分配的用户空间内存的匹配 PTE 并清除 NX 位。这“有效”,但系统最终冻结。 WinDbg 内核调试器有时会报告死锁。
我认为这是因为 Windows 内核使用一些内部结构来对这些表进行操作,但我当然无权访问。有人知道如何安全地查找和操作 PTE 吗? 我强调,当我不运行此代码时,这个问题根本不会发生。我 100% 肯定是这个 PTE 修改,而不是我的代码的其他部分导致了这个。
解决方法
听起来好像操作系统在尝试访问您正在修改的相同页面时死锁了您。以前的内核版本具有可通过 EPROCESS 结构 but this is no longer required 访问的超空间锁。
...现在映射到“超空间”所需的唯一“锁”是提高 IRQL:不再需要 HyperSpaceLock。
如果 IRQL 的死锁问题(好像 Geoff Chappell 的话还不够)来自微软文档“Locks,Deadlocks,and Synchronization”
考虑这样一种情况,在低 IRQL 下运行的代码成功获取锁,但线程被中断以在更高的 IRQL 下运行代码。如果更高的 IRQL 代码尝试获取相同的锁,线程可能会永远挂起。在较高 IRQL 代码退出之前,较低 IRQL 代码无法运行,但在较低 IRQL 代码释放锁定之前,较高 IRQL 代码无法退出。只涉及一个线程。为防止出现此问题,获取锁的代码通常会将其 IRQL 提升到任何获取锁的驱动程序代码都可以运行的最高 IRQL。
所以,提高你的 IRQL,你不应该死锁。请务必尽快将其降低到被动级别,因为您正在处理一些严重的资源。