starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

WindowsTerminal.exe sometimes ``hang``s #23952

New Issue
Closed
opened 2026-01-31 08:57:08 +00:00 by claunia · 11 comments
claunia commented 2026-01-31 08:57:08 +00:00
Owner
Copy Link

Originally created by @denis-komarov on GitHub (Jan 11, 2026).

Originally assigned to: @lhecker on GitHub.

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

Originally created by @denis-komarov on GitHub (Jan 11, 2026). Originally assigned to: @lhecker on GitHub. ### 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](https://github.com/user-attachments/files/24564522/Event.1001.Windows.Error.Reporting.txt) [Event 1002 Application Hang.txt](https://github.com/user-attachments/files/24564523/Event.1002.Application.Hang.txt) [Report.wer.txt](https://github.com/user-attachments/files/24564521/Report.wer.txt) [WinDbg Exception Analysis.txt](https://github.com/user-attachments/files/24564524/WinDbg.Exception.Analysis.txt)
claunia added the Needs-TriageIssue-BugNeeds-AttentionSeverity-DataLoss labels 2026-01-31 08:57:08 +00:00
claunia commented 2026-01-31 08:57:09 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jan 13, 2026):

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).

@lhecker commented on GitHub (Jan 13, 2026): 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).
claunia commented 2026-01-31 08:57:09 +00:00
Author
Owner
Copy Link

@denis-komarov commented on GitHub (Jan 13, 2026):

The output of the ~*kv command:

WinDbg_stack_traces_for_all_threads.txt

The output of the !locks command:

WinDbg_locks.txt

@denis-komarov commented on GitHub (Jan 13, 2026): The output of the ~*kv command: [WinDbg_stack_traces_for_all_threads.txt](https://github.com/user-attachments/files/24599709/WinDbg_stack_traces_for_all_threads.txt) The output of the !locks command: [WinDbg_locks.txt](https://github.com/user-attachments/files/24600497/WinDbg_locks.txt)
claunia commented 2026-01-31 08:57:10 +00:00
Author
Owner
Copy Link

@Zeroes1 commented on GitHub (Jan 14, 2026):

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

@Zeroes1 commented on GitHub (Jan 14, 2026): @denis-komarov where get_version.ps1? ( i cant reproduce, WT,PS,OS same)
claunia commented 2026-01-31 08:57:10 +00:00
Author
Owner
Copy Link

@denis-komarov commented on GitHub (Jan 14, 2026):

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

@denis-komarov commented on GitHub (Jan 14, 2026): @Zeroes1 Even I can't reproduce it myself - it happens unexpectedly and rarely and with different PowerShell scripts.
claunia commented 2026-01-31 08:57:10 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jan 14, 2026):

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). 🙂

@lhecker commented on GitHub (Jan 14, 2026): 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). 🙂
claunia commented 2026-01-31 08:57:10 +00:00
Author
Owner
Copy Link

@denis-komarov commented on GitHub (Jan 15, 2026):

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

@denis-komarov commented on GitHub (Jan 15, 2026): @lhecker Thank you for your attention to the problem, I sent a dump (OneDrive link) to your email.
claunia commented 2026-01-31 08:57:10 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jan 15, 2026):

@denis-komarov Unfortunately, it seems like it got blocked by our IT, as I didn't receive anything. 😢 Can you try sending it to the mail address you can find on my Github profile? It's my personal one.

@lhecker commented on GitHub (Jan 15, 2026): @denis-komarov Unfortunately, it seems like it got blocked by our IT, as I didn't receive anything. 😢 Can you try sending it to the mail address you can find on my Github profile? It's my personal one.
claunia commented 2026-01-31 08:57:11 +00:00
Author
Owner
Copy Link

@denis-komarov commented on GitHub (Jan 16, 2026):

@lhecker Ok, I sent a dump (Proton Drive link) to your personal email.

@denis-komarov commented on GitHub (Jan 16, 2026): @lhecker Ok, I sent a dump (Proton Drive link) to your personal email.
claunia commented 2026-01-31 08:57:11 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jan 23, 2026):

Hmm I really can't understand it. The lambda_9844335fc14345151eefcc3593dd6895 callstack is shcore!WorkThreadManager unloading its own dll (shcore.dll). But that's probably (?) fine because shcore!WorkThreadManager gets created for all sorts of reasons (e.g. clipboard paste with WinRT).

The existence of userenv.dll further indicates that you had the Explorer File Picker open inside the settings dialog. This would mean that you didn't reproduce the issue on a clean Windows Terminal launch, right?

I can see that you have AMD GPU drivers v8.17.10 loaded which are 11 years old at this point. Are you aware that you're using them and doing so intentionally? Because Chromium blacklisted them back in 2020 already, due to the severe bugs they have. You should urgently upgrade your drivers.

@lhecker commented on GitHub (Jan 23, 2026): Hmm I really can't understand it. The `lambda_9844335fc14345151eefcc3593dd6895` callstack is `shcore!WorkThreadManager` unloading its own dll (shcore.dll). But that's probably (?) fine because `shcore!WorkThreadManager` gets created for all sorts of reasons (e.g. clipboard paste with WinRT). The existence of userenv.dll further indicates that you had the Explorer File Picker open inside the settings dialog. This would mean that you didn't reproduce the issue on a clean Windows Terminal launch, right? I can see that you have AMD GPU drivers v8.17.10 loaded which are 11 years old at this point. Are you aware that you're using them and doing so intentionally? Because Chromium blacklisted them back in 2020 already, due to the severe bugs they have. You should _urgently_ upgrade your drivers.
claunia commented 2026-01-31 08:57:11 +00:00
Author
Owner
Copy Link

@denis-komarov commented on GitHub (Jan 26, 2026):

That's right, outdated drivers were used because they weren't updated automatically. Now the problem does not reproduce, so I believe that updating the drivers solved the problem. Thank you!

@denis-komarov commented on GitHub (Jan 26, 2026): That's right, outdated drivers were used because they weren't updated automatically. Now the problem does not reproduce, so I believe that updating the drivers solved the problem. Thank you!
claunia commented 2026-01-31 08:57:11 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jan 26, 2026):

I wonder how they caused this issue since their stack trace seemed entirely unrelated. But I'm glad you could update them! Hopefully our D3D11 text renderer works even better now. 🙂

@lhecker commented on GitHub (Jan 26, 2026): I wonder how they caused this issue since their stack trace seemed entirely unrelated. But I'm glad you could update them! Hopefully our D3D11 text renderer works even better now. 🙂
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Bug Needs-Attention Needs-Triage Severity-DataLoss
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#23952
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?