[DefApp] Console apps launched simultaneously at logon fail with 0xc0000142 when the first one exits and closes Windows Terminal

[ksksni]

Windows Terminal version

1.24.11911.0

Windows build number

10.0.26200.9457

Other Software

Windows Terminal is set as the default terminal application (HKCU\Console\%%Startup: DelegationConsole = {2EACA947-7F5F-4CFA-BA87-8F7FBEEFBE69}, DelegationTerminal = {E12CFF52-A866-4C77-9A90-F570A7AA2C6B}).

The real-world trigger is the OneDrive updater. After an update it registers cleanup commands in HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce (cmd.exe /q /c del /q "...\OneDrive\Update\OneDriveSetup.exe" and cmd.exe /q /c rmdir /s /q "...\OneDrive\<old version>"). At the next logon Explorer starts them at the same time, and I get two or three "cmd.exe - Application Error (0xc0000142)" dialogs roughly every week.

Steps to reproduce

1. Keep Windows Terminal as the default terminal application.
2. Register three RunOnce entries that finish immediately:

   $k = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\RunOnce'
   1..3 | ForEach-Object { Set-ItemProperty -Path $k -Name "Test$_" -Value "`"C:\Windows\System32\cmd.exe`" /q /c echo ok > `"$env:TEMP\runonce-test$_.txt`"" }

3. Restart Windows (Start > Power > Restart) and sign in. Do not start Windows Terminal before the RunOnce entries run.

Expected Behavior

All three commands run and create runonce-test1.txt to runonce-test3.txt.

Actual Behavior

Only one of the three succeeds. The other two fail with "The application was unable to start correctly (0xc0000142)" (System log, Application Popup, event ID 26). Which one succeeds varies between runs.

Results of variations:

Condition	Result
3 entries, full boot (Restart)	1 succeeded, 2 failed (reproduced twice)
3 entries, boot with Fast Startup	1 succeeded, 2 failed
1 entry only, boot with Fast Startup	succeeded
3 entries, each waits 5 seconds first (ping -n 6 127.0.0.1 >nul & echo ok > ...)	all 3 succeeded
3 and 10 cmd.exe started at once from PowerShell later in the session (Start-Process -WindowStyle Hidden)	all succeeded (possibly no handoff because the window was hidden; I did not verify this)

I captured a Process Monitor boot log of one failing run. Timeline (local time; the three cmd.exe processes started within 75 ms):

Time	Event
16:00:28.870	Explorer starts cmd.exe #1; it starts conhost.exe 0xffffffff -ForceV1 at 28.879
16:00:28.900	Explorer starts cmd.exe #2; its conhost starts at 28.911
16:00:28.935	OpenConsole.exe -Embedding starts (1 of 3)
16:00:28.943	Explorer starts cmd.exe #3; its conhost starts at 28.950
16:00:29.088 / 29.148	2 more OpenConsole.exe -Embedding start
16:00:29.107	WindowsTerminal.exe -Embedding starts (only one instance)
16:00:29.691	In the conhost of #3, a read on \Device\NamedPipe returns STATUS_PIPE_BROKEN
16:00:29.871	cmd.exe #3 exits successfully; its conhost exits at 29.876, and one OpenConsole exits at 29.875
16:00:29.937	WindowsTerminal.exe exits
16:00:29.938	In the conhosts of #1 and #2, the same kind of read on \Device\NamedPipe returns STATUS_PIPE_BROKEN
16:00:32.70	The conhosts of #1 and #2 and the remaining two OpenConsole processes exit; the 0xc0000142 dialogs appear

Other observations from the same log:

• The failing cmd.exe processes load only ntdll.dll, kernel32.dll and KernelBase.dll, start their conhost, and then do nothing else. The successful one goes on to load ucrtbase.dll, combase.dll, etc.
• The conhost processes of the failing and the successful cmd.exe show the same sequence of operations (including loading ole32.dll and the named pipe I/O), and all three end with STATUS_PIPE_BROKEN on the pipe. The difference is timing: for Add an option to print the colour table for the current scheme #3 the pipe breaks at 29.691 and the client continues, while for Use invariant culture for parsing double values #1 and iTerm2 color schemes can not be parsed when using a non-english locale #2 it breaks 1-2 ms after WindowsTerminal.exe exits and the clients fail.

My reading, not confirmed from the source: when several handoffs arrive while Windows Terminal is not running, one WindowsTerminal.exe instance hosts them. When the first client exits and its tab closes, the window has no other tabs yet, so Windows Terminal exits while the other handoffs are still in progress, and those clients fail during console initialization.

Related: #10523 (startup-folder .bat files fail with 0xc0000142 at logon with DefApp) was closed as a duplicate of #10453, which was closed as No-Repro in January 2022 after #10751. #15936 describes a client that exits before Windows Terminal accepts the handoff.