我已经阅读了这个主题很多小时，并尝试了许多不同的策略，但无法以稳定的方式使其发挥作用。
我在 Windows 内核中运行。我已经为一个进程分配了用户空间内存供他们使用。该内存需要是可执行的。我得到最远的解决方案是遍历页表以找到分配的用户空间内存的匹配 PTE 并清除 NX 位。这“有效”，但系统最终会冻结。 WinDbg 内核调试器有时会报告死锁。
我认为这是因为 Windows 内核使用某些内部结构来操作这些表，但我当然无权访问。有人知道如何安全地找到 PTE 并对其进行操作吗？ 我强调，当我不运行这段代码时，这个问题根本不会发生。我 100% 确定此 PTE 修改，而不是我的代码的其他部分导致此问题。
【问题讨论】：
标签： windows wdk windows-kernel page-tables
听起来操作系统在尝试访问您正在修改的相同页面时将您锁定为死锁。以前的内核版本有一个超空间锁，可以通过 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，你不应该陷入僵局。请务必尽快将其降低回被动级别，因为您正在处理一些严重的资源。
【讨论】：