WindowsTerminal.exe sometimes ```hang```s

[denis-komarov]

Windows Terminal version

1.25.260109001-llm

Windows build number

10.0.26100.0

Other Software

PowerShell 7.5.4

Steps to reproduce

Run the PowerShell script from the Windows shell like this:

d:\windows_terminal\version\wt.exe --window last new-tab --inheritEnvironment --profile 'PowerShell' d:\powershell\version\pwsh.exe -NoExit -NoLogo -ExecutionPolicy Bypass -File d:\get_version.ps1

Expected Behavior

The PowerShell script is executed in new tab, and then the work continues in the same tab of the Windows Terminal console (for example, typing and executing other commands).

Actual Behavior

The PowerShell script executes successfully, but after clicking on the current tab window of the Windows Terminal console, this happens: Windows Terminal Host is not responding.

Event 1001 Windows Error Reporting.txt
Event 1002 Application Hang.txt
Report.wer.txt
WinDbg Exception Analysis.txt

[lhecker]

The WER reporting lists a failure bucket of 8a7e2e80a743de7085908f6c88cda2dc and the WinDbg analysis a failure hash of 02ac87eb-c60c-485f-40d4-3807d598cd53. Neither turn up any recorded bug reports in our internal databases.

The WinDbg stack trace is very helpful. It's stuck inside LoadLibraryExW (to load some DLL), inside RtlAddGrowableFunctionTable (which allocates memory to set up function tables), which calls RtlProtectHeap (for mrdata) to make that new memory writeable, and that call seemingly blocks. Maybe a (loader-) deadlock with another thread?

Could you show us a stack trace of all threads in that dump? The command is ~*k I believe (not a big fan of WinDbg commands tbh).

[denis-komarov]

The output of the ~*kv command:

WinDbg_stack_traces_for_all_threads.txt

The output of the !locks command:

WinDbg_locks.txt

[Zeroes1]

@denis-komarov where get_version.ps1? ( i cant reproduce, WT,PS,OS same)

[denis-komarov]

@Zeroes1 Even I can't reproduce it myself - it happens unexpectedly and rarely and with different PowerShell scripts.

[lhecker]

Thread 2, which is stuck in TppTimerpExecuteCallback = heap related, is somewhat suspicious, but I suspect it's a false herring. The heap code should be fairly robust. More importantly, thread 7 is stuck in FreeLibraryAndExitThread which is the counterpart to our LoadLibraryExW call on the main thread. This would further cement that this is a "loader lock" deadlock.

If you're able to investigate this yourself, it'd be interesting to know what lambda_9844335fc14345151eefcc3593dd6895 is (if you click it, it should open the corresponding source file or at least show the source location). Also, it may be interesting what name/path is being passed to LoadLibraryExW on the main thread.

If you'd like us to investigate this further on your behalf, please feel free to email the dump to <my github username>@microsoft.com (you'll have to upload it somewhere, since it'll be too large as an attachment). 🙂

[denis-komarov]

@lhecker Thank you for your attention to the problem, I sent a dump (OneDrive link) to your email.