windows 11 26h2 沙盒内dxgkrnl.sys尝试访问非法内存地址

Question

windows 11 26h2 沙盒内dxgkrnl.sys尝试访问非法内存地址

子田王 0

26h2的沙盒内打开任务管理器立刻崩溃

dump竟然创建后立刻删除

想办法拿到dump后发现dxgkrnl.sys在获取Hyperv显卡驱动信息时访问了一个指针时获得了null，却直接加上偏移读取，直接内核违规内存访问蓝屏

GitHub issue 上https://github.com/microsoft/Windows-Sandbox/issues/131有大量案例

具体内存分析稍后附上

已经从映像修复系统，未发现问题

0 个注释

1 个答案

你的答案

Answer 1

Kai-H 28,525 Microsoft 外部员工审查方

( 免责声明：本文信息系通过自动翻译工具翻译而成；尽管我们力求准确，但译文未必能完全体现原文的含义、语境或意图。）

你好，子田王

从你提供的分析来看，更像是沙盒图形内核路径中的缺陷，而不是普通的系统文件损坏。GitHub issue #131 中也有打开任务管理器就崩溃的案例，目前该问题仍未关闭，也没有确认有效的修复方案。

建议你接下来这样处理：

在 Microsoft Store 的“更新和下载”中检查 Windows Sandbox 更新。沙盒应用可以单独更新，不过不能保证应用更新能解决这次内核崩溃。

既然已经拿到 dump，先在沙盒外保存一份。建议把系统内部版本号、沙盒版本、崩溃分析、出错指令和调用堆栈补充到现有 issue 中。不要直接公开完整内存转储。

在宿主机按 Windows + F，选择“报告问题”，通过反馈中心录制复现过程，并注明 issue 编号和 dump 创建后消失的情况。

你已经做过映像修复，暂时不建议重复操作。关闭 vGPU 也不能当作可靠解决办法，因为该 issue 中关闭后仍然会崩溃。

子田王 0 信誉分

2026-10-12T13:14:04.0933333+00:00

Sorry about the information

The Issue ID is 132.We have Crashes caused by Using Microsoft Edge or opening the task manager.Looking into the detail

Further information will be provided in the issue 132
子田王 0 信誉分

2026-10-12T13:52:39.7633333+00:00

editing reply for issue 132
子田王 0 信誉分

2026-10-12T14:47:28.4933333+00:00

https://github.com/microsoft/Windows-Sandbox/issues/132#issuecomment-6126730305

identified cause please help me check
子田王 0 信誉分

2026-10-12T15:32:05.4866667+00:00

also need attention，code that reads null data exists before 26h2 update，missing data might be another problem
Kai-H 28,525 信誉分 Microsoft 外部员工审查方

2026-10-13T08:27:35.7333333+00:00

Hi, 子田王

I could read issue #132, including the null-pointer finding, but the specific comment you linked was not available in the retrieved page, so I cannot verify its full analysis yet.

Your distinction is important: if the same unchecked read exists in older builds, that identifies the crash mechanism, not necessarily the change that caused it. Why the pointer now becomes null needs separate investigation.

Rather than repeating repairs, I recommend adding a before-and-after comparison to the issue: the affected function and instruction, register values, call stack, module versions, and where the missing pointer should have been populated. Keep “confirmed null-pointer access” separate from “suspected cause of missing data.”

The thread also documents Task Manager, Edge, and dxdiag triggering crashes, including with vGPU disabled. That supports investigating the shared display-information query path, but does not establish which component supplied the missing data.

Please paste the linked comment’s debugger output here so I can check the conclusion against the actual evidence.
子田王 0 信誉分

2026-10-13T16:48:43.0466667+00:00

found issue 26h2 update introduces new features that dxdiag would quest,so it quests a wrong driver a feature that needs the host to answer,but the driver does not have a vm bus,and code missed the check and caused problem full analysis later
子田王 0 信誉分

2026-10-13T22:58:09.73+00:00

new brief analysis posted
子田王 0 信誉分

2026-10-13T23:00:58.1933333+00:00

It seems that a newly introduced feature query is attempting to be sent to a adapter that has no vmbus
Kai-H 28,525 信誉分 Microsoft 外部员工审查方

2026-10-14T09:09:24.83+00:00

Hi, 子田王

Thanks for continuing the investigation and posting the updated analysis. Your current finding gives the issue a much clearer direction: the crash may occur when a newly introduced 26H2 query is sent to an adapter that does not have a VM bus, and the receiving code does not validate the returned pointer before using it.

The next step is to document enough evidence in issue #132 for the Windows Sandbox or graphics team to reproduce and verify that path. In particular, please include the failing instruction, the surrounding call stack, the adapter involved, the exact query being issued, and a comparison with the previous working build.

If possible, also test whether the crash occurs only inside Windows Sandbox or whether the same query path can be triggered on the host. That would help narrow the problem to the virtual graphics path rather than a general dxgkrnl.sys regression.

Please keep the full memory dump private and post only sanitized debugger output publicly.