NO_MORE_SYSTEM_PTES（0x0000003F）本质是系统页表条目（PTE）耗尽，需通过调用链确认是否为ntkrpamp!MmMapLockedPages或mrxsmb!SmbMmAllocateSessionEntry失败所致；禁用SMB客户端缓存、卸载高PTE消耗的备份/同步工具、手动设置SystemPageTablePages值可缓解，但驱动硬编码PTE需求须更新驱动或降低显示配置。
这是 NO_MORE_SYSTEM_PTES（错误代码 0x0000003F）的变体提示，本质仍是系统页表条目（PTE）耗尽，不是驱动“滥用”，而是内核内存管理资源被大量、持续占用后彻底枯竭——必须立刻干预，否则每次启动都可能在加载阶段就蓝屏。
怎么确认真是PTE耗尽而不是其他驱动问题
不能只看蓝屏文字。关键要看调用链是否指向 PTE 分配失败的内核路径：
- 强制三次关机进 WinRE → “命令提示符” → 运行
ver确认是 Windows 11 22H2 或更新版本 - 执行
driverquery /v | findstr /i "nvlddmkm\|mrxsmb\|rdbss\|netbt" - 如果输出中反复出现
ntkrpamp!MmMapLockedPages或mrxsmb!SmbMmAllocateSessionEntry，基本锁定为 PTE 分配失败 - 此时
MEMORY_MANAGEMENT或IRQL_NOT_LESS_OR_EQUAL等附带错误码，只是崩溃时的表象，根源仍是 PTE 不足
禁用高PTE消耗的SMB客户端缓存
Windows 自带的 SMB 客户端（LanmanWorkstation）在访问网络共享时会为每个目录项、文件句柄预分配大量 PTE，尤其当挂载多个 NAS 或 OneDrive/SharePoint 映射盘时极易触发。关闭缓存能立竿见影降低压力：
- 以管理员身份运行 PowerShell
- 执行：
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" -Name "DirectoryCacheEntries" -Value 0 -Type DWord - 再执行：
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" -Name "FileNotFoundCacheEntries" -Value 0 -Type DWord - 重启生效。无需卸载 SMB 功能，也不影响基本文件访问
卸载近期安装的备份/同步工具
Acronis True Image、EaseUS Todo Backup、GoodSync、Syncthing（启用了内核级文件监控）等工具，在后台服务中会长期锁定数百 MB 至数 GB 的物理内存，并持续申请 PTE 块。它们即使没在界面上运行，也会在系统启动早期加载驱动并占坑。
- 打开“控制面板 → 程序和功能” → 按“安装日期”排序
- 重点排查过去 7 天内安装的备份、同步、加密、虚拟光驱类软件
- 卸载时务必勾选“删除此设备的驱动程序软件”，否则残留的.sys仍会在下次启动时抢注 PTE
- 卸载后不要立即重启，先进安全模式验证是否稳定；若仍蓝屏，说明还有未识别的 PTE 消耗源
调整注册表中的SystemPageTablePages值
Windows 默认 PTE 池大小由物理内存自动估算，但对 16GB+ 内存、多显示器+高分辨率场景常严重低估。手动设为固定值可绕过估算缺陷：
- 以管理员身份打开注册表编辑器，定位到：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management - 新建一个
DWORD (32位)值，名称为SystemPageTablePages - 双击该值，将“数值数据”设为
16384（十进制），即 64MB PTE 表空间 - 仅适用于 16GB 及以上内存设备；低于 16GB 建议设为
8192，过高反而引发其他内存碎片问题 - 该设置需重启才生效，且不会覆盖驱动硬编码的 PTE 需求——若仍蓝屏，说明显卡驱动或某.sys 文件存在不可协商的 PTE 依赖，必须换驱动
真正麻烦的是那些把 PTE 需求写死在驱动二进制里的模块，比如某些老版本 NVIDIA 驱动在 4K@144Hz 多屏下会直接索要 32768 个 PTE。这时候注册表调整只是延缓崩溃，不换驱动或降显示配置，问题必然复现。
