WSL2 shutdown can deadlock while process creation waits for OOBE

[SylvainM98]

WSL2 shutdown can deadlock while process creation waits for OOBE

Summary

WslCoreInstance::CreateLxProcess() waits for an in-progress OOBE while holding WslCoreInstance::m_lock. The shutdown path needs the same lock to stop the instance and signal its destruction event.

If another process launch arrives while OOBE is waiting for user input, distribution termination or shutdown can remain blocked until OOBE completes.

Code analysis

CreateLxProcess() acquires m_lock before checking m_oobeCompleteEvent:

std::lock_guard lock(m_lock);

if (m_oobeCompleteEvent && !m_oobeCompleteEvent.is_signaled())
{
    m_oobeCompleteEvent.wait();
}

RequestStop() and Stop() also acquire m_lock. Stop() signals m_destroyingEvent, but it cannot do so while the process-creation thread owns the lock.

The resulting dependency is:

1. A process-creation thread owns m_lock and waits for OOBE completion.
2. Shutdown waits for m_lock before it can stop the instance.
3. The process-creation wait does not observe m_destroyingEvent.

OOBE is intentionally allowed to wait indefinitely for user interaction. That wait should not retain the instance lock or prevent shutdown.

Expected behavior

An OOBE flow may remain active for an arbitrary duration, but distribution termination and shutdown must still be able to stop the instance.

Proposed change

Capture stable handles for the OOBE-complete and instance-destroying events while holding m_lock, release the lock, and wait for either event. After reacquiring the lock, revalidate that the instance is still running before continuing process creation.

Proposed validation

Add a WSL2 regression test that:

• starts an OOBE command that remains active;
• starts a second process creation that waits for OOBE;
• terminates the distribution concurrently;
• verifies that termination completes before OOBE's natural completion;
• verifies that the waiting client processes exit.

This report is based on static source analysis and a deterministic regression scenario. No machine logs are attached.

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[SylvainM98]

No machine logs will be attached because this report is based on a deterministic code-level deadlock and includes a focused regression test in #41387. The issue body documents the lock cycle and the exact shutdown path; the test reproduces OOBE wait followed by distribution termination.