Windows Sandbox crashes with error 0x80370106 after KB5124010 (Windows 11 25H2)

Nota: Nossos fóruns tem suporte nativo em Portugu~es, sempre que interagir conosco utilize nosso idioma.

Olá

Bem-vindo à Comunidade Microsoft Windows

Boa noite, @Rogério Cazotto . O pacote KB5124010 é uma atualização opcional, não temos relatos sobre problemas inerentes a este pacote, portanto vou soliictar que envie um feedback relatando o problema através do Hub de comentários do Windows apertando Win+F e depois remover a atualização supracitada. Estes são os problemas conhecidos até agora

Dispositivos associados ao domínio podem perder sua relação de confiança segura com o domínio

Dispositivos USB Audio Class 1.0 com erro Código 10 ou nenhuma saída

Para desinstalar o pacote:

1. Aperta Win+i -> Windows Update -> histórico de atualizações
2. Localiza o pacote KB5124010 e clica em "desinstalar"
3. Reinicia o computador
4. Pàra evitar a reinstalação do pacote, baixa e executa esta ferramenta e clica em "Hide" e seleciona o pacote KB5124010:

   https://download.microsoft.com/download/f/2/2/f22d5fdb-59cd-4275-8c95-1be17bf70b21/wushowhide.diagcab

Reinicia o computador e avise-nos sobre o resultado.

Olá, Dio. Obrigado pela resposta.

Infelizmente não consigo remover a KB5124010. Já tentei pelo Histórico do Windows Update, pelo Ambiente de Recuperação do Windows (WinRE) e também pelo DISM. A tentativa de remoção pelo DISM termina com o erro 0x800f0926.

Também executei DISM /Online /Cleanup-Image /ScanHealth, que informou que o repositório de componentes é reparável. Em seguida executei DISM /Online /Cleanup-Image /RestoreHealth, porém o processo chegou a 100% e terminou com o erro 0x800f0915 – “O conteúdo de reparo não pôde ser encontrado”.

Portanto, no momento não consigo nem reparar o Component Store nem remover a KB5124010.

O Windows Sandbox continua apresentando 0x80370106 mesmo completamente limpo, e o Visualizador de Eventos registra 0xC0370106 e Hyper-V-CrashDump Event ID 40001.

Existe alguma outra forma suportada de remover a KB5124010 ou reparar o Component Store sem reinstalar o Windows?

Ao instalar software na sandbox — por exemplo, IDM, Warp ou outro programa...

Após a instalação do patch (KB5124010) (26200.9550), o Windows Sandbox falha ao fim de algum tempo de utilização; arranca normalmente, mas, após um período e a instalação de algo na sandbox, o ecrã desaparece e é apresentado o erro 0x80370106.

Desinstalei o KB5124010 e o Windows Sandbox funcionou sem problemas — sem falhas —, mesmo quando executava as ações que normalmente causavam a falha após algum tempo de execução.

Ao reinstalar o KB5124010, o problema com o Windows Sandbox voltou.

É claro que algo nesta nova atualização introduz um bug — provavelmente relacionado com o TiWorker — que causa uma falha na sandbox quando esta tenta realizar uma atualização.

Passos para reproduzir o bug
Os passos para reproduzir o problema são os seguintes:

Inicie a sandbox.
Instale um software (por exemplo, IDM ou outra aplicação).
Abra o browser Edge e ative o plugin.
Feche o browser.
Abra novamente o browser; fará uma atualização automática.
Aguarde até que o Windows Sandbox bloqueie e apresente o erro 0x80370106.
Isto faz com que o processo TiWorker tente realizar uma atualização dentro da sandbox, resultando na falha.

Um utilizador realizou o que parece ser uma análise forense da vulnerabilidade no endereço que publiquei no outro dia. https://github.com/microsoft/Windows-Sandbox/issues/132#issuecomment-6196082433

Additional data point — reproducible with a different trigger, same signature.

Environment

• Host: Windows 11 Pro 26H2, build 26300.9550 (zh-cn), Intel Iris Xe (driver 30.0.101.1660)
• Windows Sandbox: 0.8.107.0
• Component store verified clean (DISM /RestoreHealth with build-matched source: 0 corruption; sfc /scannow: 0 repairs) — corruption ruled out

Triggers observed (all produce the same guest bugcheck)

1. Opening Task Manager inside the guest — crashes within seconds, ~100% reproducible
2. Browsing in guest Edge: bing.com is fine, but opening the Process Explorer download page on learn.microsoft.com crashes the guest — matches the "varies by page / timing" behavior described above

vGPU ruled out

• Crashes persist with <VGpu>Disable</VGpu> in a .wsb config
• The faulting address is identical with vGPU enabled and disabled, so the faulting code is not in the paravirtualized GPU path

Event 18590 (Microsoft-Windows-Hyper-V-Worker-Admin), two crashes from different VM instances:

17:59:04  ErrorCode0: 0x3B  ErrorCode1: 0xC0000005  ErrorCode2: 0xFFFFF8018020800A  VTL: 0x0
18:06:35  ErrorCode0: 0x3B  ErrorCode1: 0xC0000005  ErrorCode2: 0xFFFFF8018020800A  VTL: 0x0

Note: ErrorCode2 (exception RIP) is byte-for-byte identical across crashes, VM instances, and GPU configurations — a deterministic fault at one kernel code address, consistent with a build regression rather than a driver/environment issue.

Also observed

• Event 33101 "Virtual machine requested unsupported Virtual PCI protocol version 0x10006" (0x8007051A) on every sandbox launch
• Event 40001 reports the guest fault dump was written successfully, but the .dmp/.vmrs files under C:\ProgramData\Microsoft\Windows\Containers\Dumps are 0 bytes — same empty-dump problem as the OP. If there is a supported way to capture a usable guest dump (debug flag, registry setting, host-side config), please share and I'll collect it.

WebView2 ruled out as the shared trigger

• Task Manager crashes 100% of the time, but runtime module inspection of taskmgr.exe shows it does NOT load any WebView2/Edge modules and spawns no msedgewebview2.exe children (verified on the host with the same binary). The WebView2 strings in the binary are never loaded at runtime.
• Since both Task Manager and Edge browsing hit the same fixed kernel RIP, the shared faulting path is more likely core kernel infrastructure (e.g., memory compression / MemCompression — Task Manager queries compressed-memory stats, and heavier web pages create the memory pressure that triggers compression — or a win32k/DirectWrite glyph path) rather than WebView2 or the GPU stack.

Deterministic isolation: the display driver stack (dxgkrnl / basic display adapter)

Headless discriminator tests inside the guest, same fixed RIP (0xFFFFF8018020800A) on every crash, independent of VM instance:

Timing evidence from a host-synced guest log (mapped-folder write-through):

[18:39:04.340] dxdiag process launched, waiting for report file...
[18:39:06]     host event 18590: guest bugcheck 0x3B, ErrorCode2 = 0xFFFFF8018020800A

This matches Microsoft's documented profile for bug check 0x3B ("user-mode graphics drivers passing bad data to kernel code"). It also explains the Task Manager trigger (D3DKMT adapter enumeration + per-process GPU statistics on every launch) and the Edge page-dependence (GPU process D3D initialization depth varies by page). The fault is present with vGPU enabled AND disabled, so both the paravirtualized GPU path and the basic display adapter path traverse the faulty code — pointing at guest dxgkrnl/basic-display code introduced or regressed in build 26300.95xx.

Happy to test candidate fixes or provide additional logs.Additional data point — reproducible with a different trigger, same signature.

Environment

• Host: Windows 11 Pro 26H2, build 26300.9550 (zh-cn), Intel Iris Xe (driver 30.0.101.1660)
• Windows Sandbox: 0.8.107.0
• Component store verified clean (DISM /RestoreHealth with build-matched source: 0 corruption; sfc /scannow: 0 repairs) — corruption ruled out

Triggers observed (all produce the same guest bugcheck)

1. Opening Task Manager inside the guest — crashes within seconds, ~100% reproducible
2. Browsing in guest Edge: bing.com is fine, but opening the Process Explorer download page on learn.microsoft.com crashes the guest — matches the "varies by page / timing" behavior described above

vGPU ruled out

• Crashes persist with <VGpu>Disable</VGpu> in a .wsb config
• The faulting address is identical with vGPU enabled and disabled, so the faulting code is not in the paravirtualized GPU path

Event 18590 (Microsoft-Windows-Hyper-V-Worker-Admin), two crashes from different VM instances:

17:59:04  ErrorCode0: 0x3B  ErrorCode1: 0xC0000005  ErrorCode2: 0xFFFFF8018020800A  VTL: 0x0
18:06:35  ErrorCode0: 0x3B  ErrorCode1: 0xC0000005  ErrorCode2: 0xFFFFF8018020800A  VTL: 0x0

Note: ErrorCode2 (exception RIP) is byte-for-byte identical across crashes, VM instances, and GPU configurations — a deterministic fault at one kernel code address, consistent with a build regression rather than a driver/environment issue.

Also observed

• Event 33101 "Virtual machine requested unsupported Virtual PCI protocol version 0x10006" (0x8007051A) on every sandbox launch
• Event 40001 reports the guest fault dump was written successfully, but the .dmp/.vmrs files under C:\ProgramData\Microsoft\Windows\Containers\Dumps are 0 bytes — same empty-dump problem as the OP. If there is a supported way to capture a usable guest dump (debug flag, registry setting, host-side config), please share and I'll collect it.

WebView2 ruled out as the shared trigger

• Task Manager crashes 100% of the time, but runtime module inspection of taskmgr.exe shows it does NOT load any WebView2/Edge modules and spawns no msedgewebview2.exe children (verified on the host with the same binary). The WebView2 strings in the binary are never loaded at runtime.
• Since both Task Manager and Edge browsing hit the same fixed kernel RIP, the shared faulting path is more likely core kernel infrastructure (e.g., memory compression / MemCompression — Task Manager queries compressed-memory stats, and heavier web pages create the memory pressure that triggers compression — or a win32k/DirectWrite glyph path) rather than WebView2 or the GPU stack.

Deterministic isolation: the display driver stack (dxgkrnl / basic display adapter)

Headless discriminator tests inside the guest, same fixed RIP (0xFFFFF8018020800A) on every crash, independent of VM instance:

Timing evidence from a host-synced guest log (mapped-folder write-through):

[18:39:04.340] dxdiag process launched, waiting for report file...
[18:39:06]     host event 18590: guest bugcheck 0x3B, ErrorCode2 = 0xFFFFF8018020800A

This matches Microsoft's documented profile for bug check 0x3B ("user-mode graphics drivers passing bad data to kernel code"). It also explains the Task Manager trigger (D3DKMT adapter enumeration + per-process GPU statistics on every launch) and the Edge page-dependence (GPU process D3D initialization depth varies by page). The fault is present with vGPU enabled AND disabled, so both the paravirtualized GPU path and the basic display adapter path traverse the faulty code — pointing at guest dxgkrnl/basic-display code introduced or regressed in build 26300.95xx.

Happy to test candidate fixes or provide additional logs.

Espero que isto incentive a Microsoft a corrigir a vulnerabilidade o mais rapidamente possível.