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

Windows Terminal hangs after switching user account. #18992

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

Originally created by @samiksome92 on GitHub (Nov 30, 2022).

Windows Terminal version

1.15.2875.0

Windows build number

10.0.22621.819

Other Software

No response

Steps to reproduce

I have been having this issue for quite some time.

I have two user accounts and often switch between them. The problem occurs when some program (eg. ping) is running in windows terminal and I switch to another account. Upon switching back the whole terminal freezes and I have to kill it using Task Manager. This does not happen if I run the same program using conhost.

Basically issue is as follows:

  1. As User A:
    1. Open terminal.
    2. Run some long running program. eg. ping, ssh
  2. Switch to User B.
  3. Switch back to User A.
  4. Terminal hangs.

I don't remember if the issue started once I upgraded to Windows 11, but I do remember that it never happened in Windows 10.

Expected Behavior

Expected behavior is terminal keeps running normally.

Actual Behavior

Terminal hangs (not responding).

I believe the issue is also related to the screen updates since when I run ping -t 1.1.1.1 > a.txt which does not result in any output lines on the terminal, it does not hang. Neither does it hang when nothing is running. The issue only seems to happen if the screen has updated while I was using the other account.

Originally created by @samiksome92 on GitHub (Nov 30, 2022). ### Windows Terminal version 1.15.2875.0 ### Windows build number 10.0.22621.819 ### Other Software _No response_ ### Steps to reproduce I have been having this issue for quite some time. I have two user accounts and often switch between them. The problem occurs when some program (eg. ping) is running in windows terminal and I switch to another account. Upon switching back the whole terminal freezes and I have to kill it using Task Manager. This does not happen if I run the same program using conhost. Basically issue is as follows: 1. As User A: 1. Open terminal. 2. Run some long running program. eg. ping, ssh 2. Switch to User B. 3. Switch back to User A. 4. Terminal hangs. I don't remember if the issue started once I upgraded to Windows 11, but I do remember that it never happened in Windows 10. ### Expected Behavior Expected behavior is terminal keeps running normally. ### Actual Behavior Terminal hangs (not responding). I believe the issue is also related to the screen updates since when I run `ping -t 1.1.1.1 > a.txt` which does not result in any output lines on the terminal, it does not hang. Neither does it hang when nothing is running. The issue only seems to happen if the screen has updated while I was using the other account.
claunia added the Resolution-Fix-AvailableNeeds-TriageIssue-BugNeeds-Attention labels 2026-01-31 06:30:35 +00:00
claunia commented 2026-01-31 06:30:37 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 30, 2022):

Can you try installing Terminal Preview, v1.16, and see if that fixes this/? There's a whole class of hangs in Terminal Stable that seemingly go away with the new rendering engine in 1.16.

@zadjii-msft commented on GitHub (Nov 30, 2022): Can you try installing Terminal Preview, v1.16, and see if that fixes this/? There's a whole class of hangs in Terminal Stable that seemingly go away with the new rendering engine in 1.16.
claunia commented 2026-01-31 06:30:37 +00:00
Author
Owner
Copy Link

@samiksome92 commented on GitHub (Nov 30, 2022):

@zadjii-msft Terminal Preview v1.16 seems to be working properly. Tried with both ping and ssh and in both cases the stable version froze after user switch but preview worked smoothly.

@samiksome92 commented on GitHub (Nov 30, 2022): @zadjii-msft Terminal Preview v1.16 seems to be working properly. Tried with both ping and ssh and in both cases the stable version froze after user switch but preview worked smoothly.
claunia commented 2026-01-31 06:30:37 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 30, 2022):

That's great to hear! Let's just call this one "fixed by the atlas engine" then. Thanks for following up!

@zadjii-msft commented on GitHub (Nov 30, 2022): That's great to hear! Let's just call this one "fixed by the atlas engine" then. Thanks for following up!
claunia commented 2026-01-31 06:30:37 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 5, 2022):

In retrospect, more dumps is better. We kinda want to better understand what's going on here - 1.16 might just make the window for this deadlock to happen smaller, but not get rid of it.

Could you try 1.15 again, and when the Terminal hangs, could you grab a dump with Task Manager and send it to us?

image

I believe you can manually attach a dmp to a Feedback Hub post: /feedback

@zadjii-msft commented on GitHub (Dec 5, 2022): In retrospect, more dumps is better. We kinda want to better understand what's going on here - 1.16 might just make the window for this deadlock to happen _smaller_, but not get rid of it. Could you try 1.15 again, and when the Terminal hangs, could you grab a dump with Task Manager and send it to us? ![image](https://user-images.githubusercontent.com/18356694/135876584-e48514d6-26c0-49da-ae28-b8c5d66dc2a3.png) I believe you can manually attach a dmp to a Feedback Hub post: /feedback
claunia commented 2026-01-31 06:30:37 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Dec 5, 2022):

Hi there!

Can you please send us feedback with the Feedback Hub with this issue? Make sure to click the "Start recording" button, then reproduce the issue before submitting the feedback. Once it's submitted, paste the link here so we can more easily find your crash information on the back end?

Thanks!

image

image

image

@ghost commented on GitHub (Dec 5, 2022): Hi there!<br><br>Can you please send us feedback with the [Feedback Hub](https://support.microsoft.com/en-us/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332) with this issue? Make sure to click the "Start recording" button, then reproduce the issue before submitting the feedback. Once it's submitted, paste the link here so we can more easily find your crash information on the back end?<br><br>Thanks!<br><br>![image](https://user-images.githubusercontent.com/18356694/140811502-a068f78b-89d2-4587-925a-73e19652b830.png)<br><br>![image](https://user-images.githubusercontent.com/18356694/140811557-cdc22a0f-fa6a-4f6a-953e-73b51f5548a3.png)<br><br>![image](https://user-images.githubusercontent.com/18221333/62478649-6de55400-b760-11e9-806e-5aab7e085a9f.png)
claunia commented 2026-01-31 06:30:37 +00:00
Author
Owner
Copy Link

@samiksome92 commented on GitHub (Dec 5, 2022):

I have created a feedback as requested. https://aka.ms/AAixlbk
I have also attached the dump file to the feedback

@samiksome92 commented on GitHub (Dec 5, 2022): I have created a feedback as requested. https://aka.ms/AAixlbk I have also attached the dump file to the feedback
claunia commented 2026-01-31 06:30:38 +00:00
Author
Owner
Copy Link

@samiksome92 commented on GitHub (Dec 5, 2022):

I am attaching a link to the dump file here as well: https://1drv.ms/u/s!AiKzjTVpEcAHeL7FtFYZ_usCBWk?e=HbUyGM

@samiksome92 commented on GitHub (Dec 5, 2022): I am attaching a link to the dump file here as well: https://1drv.ms/u/s!AiKzjTVpEcAHeL7FtFYZ_usCBWk?e=HbUyGM
claunia commented 2026-01-31 06:30:38 +00:00
Author
Owner
Copy Link

@Ariane-B commented on GitHub (Dec 14, 2022):

Not sure why this is closed.

@Ariane-B commented on GitHub (Dec 14, 2022): Not sure why this is closed.
claunia commented 2026-01-31 06:30:38 +00:00
Author
Owner
Copy Link

@samiksome92 commented on GitHub (Dec 14, 2022):

@Ariane-B It's fixed in 1.16 (pre-release)

@samiksome92 commented on GitHub (Dec 14, 2022): @Ariane-B It's fixed in 1.16 (pre-release)
claunia commented 2026-01-31 06:30:38 +00:00
Author
Owner
Copy Link

@Ariane-B commented on GitHub (Dec 14, 2022):

Oh! Thanks for the info. Is there an ETA for when the update will be pushed to everyone?

@Ariane-B commented on GitHub (Dec 14, 2022): Oh! Thanks for the info. Is there an ETA for when the update will be pushed to everyone?
claunia commented 2026-01-31 06:30:39 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 14, 2022):

To be clear - I don't think 1.16 fixes the issue, I think it just makes the window for this particular hang to happen much much smaller.

1.16 Preview has been out for a while. Go ahead and use that if this is impacting you on a regular basis.

We'll probably be pushing 1.16 to Stable some time next month, but likely without turning the new renderer on for everyone in Stable. It'll still be there, just defaulted to off on the Stable builds.

Some stack analysis from the above dump

main

Microsoft_Terminal_Control!til::atomic_wait+0x18 [C:\a\_work\1\s\src\inc\til\atomic.h @ 13] 
06 0000004f`e1ddde40 00007ff9`54d94c44     Microsoft_Terminal_Control!til::ticket_lock::lock+0x61 [C:\a\_work\1\s\src\inc\til\ticket_lock.h @ 35] 
07 0000004f`e1ddde80 00007ff9`54e04be4     Microsoft_Terminal_Control!std::unique_lock<til::ticket_lock>::unique_lock<til::ticket_lock>+0x18 [C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\mutex @ 135] 
08 (Inline Function) --------`--------     Microsoft_Terminal_Control!Microsoft::Terminal::Core::Terminal::LockForReading+0x10 [C:\a\_work\1\s\src\cascadia\TerminalCore\Terminal.cpp @ 965] 
09 0000004f`e1dddeb0 00007ff9`54e02fa0     Microsoft_Terminal_Control!winrt::Microsoft::Terminal::Control::implementation::ControlCore::_updateHoveredCell+0x9c [C:\a\_work\1\s\src\cascadia\TerminalControl\ControlCore.cpp @ 622] 
0a 0000004f`e1dddfa0 00007ff9`54e0ce79     Microsoft_Terminal_Control!winrt::Microsoft::Terminal::Control::implementation::ControlCore::SetHoveredCell+0x30 [C:\a\_work\1\s\src\cascadia\TerminalControl\ControlCore.cpp @ 600] 
0b 0000004f`e1dddff0 00007ff9`54e20100

renderer thread

0:019> k
 # Child-SP          RetAddr               Call Site
00 0000004f`e354ee78 00007ff9`94509afe     ntdll!ZwWaitForSingleObject+0x14 [minkernel\ntdll\daytona\objfre\amd64\usrstubs.asm @ 251] 
01 0000004f`e354ee80 00007ff9`827acc39     KERNELBASE!WaitForSingleObjectEx+0x8e [minkernel\kernelbase\synch.c @ 1328] 
02 0000004f`e354ef20 00007ff9`827ad736     nvwgf2umx!NVAPI_Thunk+0x1017ed9
03 0000004f`e354f200 00007ff9`827adb82     nvwgf2umx!NVAPI_Thunk+0x10189d6
04 0000004f`e354f240 00007ff9`827b47f3     nvwgf2umx!NVAPI_Thunk+0x1018e22
05 0000004f`e354f290 00007ff9`82842e4a     nvwgf2umx!NVAPI_Thunk+0x101fa93
06 0000004f`e354f2f0 00007ff9`907e24ff     nvwgf2umx!OpenAdapter10+0x25c9a
07 0000004f`e354f560 00007ff9`907e220f     d3d11!NDXGI::CDevice::ReclaimResourcesImpl+0x253 [onecoreuap\windows\directx\dxg\d3d11\d3dcore\lowfreq\dxgidevice.cpp @ 5244] 
08 0000004f`e354f6c0 00007ff9`90283046     d3d11!NDXGI::CDevice::ReclaimResources+0x4f [onecoreuap\windows\directx\dxg\d3d11\d3dcore\lowfreq\dxgidevice.cpp @ 5118] 
09 (Inline Function) --------`--------     d2d1!OfferableResourceManager::ReclaimResourcesImmediately+0x28 [onecoreuap\windows\direct2d\d2dcommon\resources\offerableresource.cpp @ 361] 
0a (Inline Function) --------`--------     d2d1!OfferableResourceManager::ReclaimResourcesInList+0xbe [onecoreuap\windows\direct2d\d2dcommon\resources\offerableresource.cpp @ 325] 
0b 0000004f`e354f720 00007ff9`90282cfd     d2d1!CHwSurfaceRenderTarget::BeginProcessBatch+0x126 [onecoreuap\windows\direct2d\core\hw\hwsurfrt.cpp @ 7310] 
0c 0000004f`e354f920 00007ff9`9028b9c5     d2d1!CHwSurfaceRenderTarget::ProcessBatch+0x2d [onecoreuap\windows\direct2d\core\hw\hwsurfrt.cpp @ 7389] 
0d 0000004f`e354f970 00007ff9`9028433a     d2d1!CBatchSerializer::FlushInternal+0xf5 [onecoreuap\windows\direct2d\core\batching\batchserializer.cpp @ 308] 
0e (Inline Function) --------`--------     d2d1!CBatchSerializer::Flush+0x1e [onecoreuap\windows\direct2d\core\batching\batchserializer.cpp @ 440] 
0f (Inline Function) --------`--------     d2d1!DrawingContext::FlushBatch+0x2b [onecoreuap\windows\direct2d\core\targets\drawingcontext.cpp @ 5958] 
10 0000004f`e354fa00 00007ff9`90283caf     d2d1!DrawingContext::Flush+0x9a [onecoreuap\windows\direct2d\core\targets\drawingcontext.cpp @ 3409] 
11 (Inline Function) --------`--------     d2d1!DrawingContext::EndDraw+0x31 [onecoreuap\windows\direct2d\core\targets\drawingcontext.cpp @ 4670] 
12 0000004f`e354fa60 00007ff9`54d94305     d2d1!D2DDeviceContextBase<ID2D1DeviceContext6,ID2D1DeviceContext6,null_type>::EndDraw+0x19f [onecoreuap\windows\Direct2D\core\targets\D2DRenderTarget.inl @ 804] 
13 0000004f`e354fb20 00007ff9`54d93d89     Microsoft_Terminal_Control!Microsoft::Console::Render::DxEngine::EndPaint+0xa5 [C:\a\_work\1\s\src\renderer\dx\DxRenderer.cpp @ 1387] 
14 (Inline Function) --------`--------

Yep, looks like a deadlock. The Renderer thread is in a ZwWaitForSingleObject above nvwgf2umx!OpenAdapter10 above d3d11!NDXGI::CDevice::ReclaimResourcesImpl, in our DxEngine::EndPaint.

We've got a pile of these around the repo. I should promote one to me the master tracking thread.

@zadjii-msft commented on GitHub (Dec 14, 2022): To be clear - I don't think 1.16 _fixes_ the issue, I think it just makes the window for this particular hang to happen much _much_ smaller. 1.16 Preview has been out for a while. Go ahead and use that if this is impacting you on a regular basis. We'll probably be pushing 1.16 to Stable some time next month, but likely without turning the new renderer on for everyone in Stable. It'll still be there, just defaulted to off on the Stable builds. <hr> <details> <summary>Some stack analysis from the above dump</summary> #### main ``` Microsoft_Terminal_Control!til::atomic_wait+0x18 [C:\a\_work\1\s\src\inc\til\atomic.h @ 13] 06 0000004f`e1ddde40 00007ff9`54d94c44 Microsoft_Terminal_Control!til::ticket_lock::lock+0x61 [C:\a\_work\1\s\src\inc\til\ticket_lock.h @ 35] 07 0000004f`e1ddde80 00007ff9`54e04be4 Microsoft_Terminal_Control!std::unique_lock<til::ticket_lock>::unique_lock<til::ticket_lock>+0x18 [C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\mutex @ 135] 08 (Inline Function) --------`-------- Microsoft_Terminal_Control!Microsoft::Terminal::Core::Terminal::LockForReading+0x10 [C:\a\_work\1\s\src\cascadia\TerminalCore\Terminal.cpp @ 965] 09 0000004f`e1dddeb0 00007ff9`54e02fa0 Microsoft_Terminal_Control!winrt::Microsoft::Terminal::Control::implementation::ControlCore::_updateHoveredCell+0x9c [C:\a\_work\1\s\src\cascadia\TerminalControl\ControlCore.cpp @ 622] 0a 0000004f`e1dddfa0 00007ff9`54e0ce79 Microsoft_Terminal_Control!winrt::Microsoft::Terminal::Control::implementation::ControlCore::SetHoveredCell+0x30 [C:\a\_work\1\s\src\cascadia\TerminalControl\ControlCore.cpp @ 600] 0b 0000004f`e1dddff0 00007ff9`54e20100 ``` #### renderer thread ``` 0:019> k # Child-SP RetAddr Call Site 00 0000004f`e354ee78 00007ff9`94509afe ntdll!ZwWaitForSingleObject+0x14 [minkernel\ntdll\daytona\objfre\amd64\usrstubs.asm @ 251] 01 0000004f`e354ee80 00007ff9`827acc39 KERNELBASE!WaitForSingleObjectEx+0x8e [minkernel\kernelbase\synch.c @ 1328] 02 0000004f`e354ef20 00007ff9`827ad736 nvwgf2umx!NVAPI_Thunk+0x1017ed9 03 0000004f`e354f200 00007ff9`827adb82 nvwgf2umx!NVAPI_Thunk+0x10189d6 04 0000004f`e354f240 00007ff9`827b47f3 nvwgf2umx!NVAPI_Thunk+0x1018e22 05 0000004f`e354f290 00007ff9`82842e4a nvwgf2umx!NVAPI_Thunk+0x101fa93 06 0000004f`e354f2f0 00007ff9`907e24ff nvwgf2umx!OpenAdapter10+0x25c9a 07 0000004f`e354f560 00007ff9`907e220f d3d11!NDXGI::CDevice::ReclaimResourcesImpl+0x253 [onecoreuap\windows\directx\dxg\d3d11\d3dcore\lowfreq\dxgidevice.cpp @ 5244] 08 0000004f`e354f6c0 00007ff9`90283046 d3d11!NDXGI::CDevice::ReclaimResources+0x4f [onecoreuap\windows\directx\dxg\d3d11\d3dcore\lowfreq\dxgidevice.cpp @ 5118] 09 (Inline Function) --------`-------- d2d1!OfferableResourceManager::ReclaimResourcesImmediately+0x28 [onecoreuap\windows\direct2d\d2dcommon\resources\offerableresource.cpp @ 361] 0a (Inline Function) --------`-------- d2d1!OfferableResourceManager::ReclaimResourcesInList+0xbe [onecoreuap\windows\direct2d\d2dcommon\resources\offerableresource.cpp @ 325] 0b 0000004f`e354f720 00007ff9`90282cfd d2d1!CHwSurfaceRenderTarget::BeginProcessBatch+0x126 [onecoreuap\windows\direct2d\core\hw\hwsurfrt.cpp @ 7310] 0c 0000004f`e354f920 00007ff9`9028b9c5 d2d1!CHwSurfaceRenderTarget::ProcessBatch+0x2d [onecoreuap\windows\direct2d\core\hw\hwsurfrt.cpp @ 7389] 0d 0000004f`e354f970 00007ff9`9028433a d2d1!CBatchSerializer::FlushInternal+0xf5 [onecoreuap\windows\direct2d\core\batching\batchserializer.cpp @ 308] 0e (Inline Function) --------`-------- d2d1!CBatchSerializer::Flush+0x1e [onecoreuap\windows\direct2d\core\batching\batchserializer.cpp @ 440] 0f (Inline Function) --------`-------- d2d1!DrawingContext::FlushBatch+0x2b [onecoreuap\windows\direct2d\core\targets\drawingcontext.cpp @ 5958] 10 0000004f`e354fa00 00007ff9`90283caf d2d1!DrawingContext::Flush+0x9a [onecoreuap\windows\direct2d\core\targets\drawingcontext.cpp @ 3409] 11 (Inline Function) --------`-------- d2d1!DrawingContext::EndDraw+0x31 [onecoreuap\windows\direct2d\core\targets\drawingcontext.cpp @ 4670] 12 0000004f`e354fa60 00007ff9`54d94305 d2d1!D2DDeviceContextBase<ID2D1DeviceContext6,ID2D1DeviceContext6,null_type>::EndDraw+0x19f [onecoreuap\windows\Direct2D\core\targets\D2DRenderTarget.inl @ 804] 13 0000004f`e354fb20 00007ff9`54d93d89 Microsoft_Terminal_Control!Microsoft::Console::Render::DxEngine::EndPaint+0xa5 [C:\a\_work\1\s\src\renderer\dx\DxRenderer.cpp @ 1387] 14 (Inline Function) --------`-------- ``` </details> Yep, looks like a deadlock. The Renderer thread is in a `ZwWaitForSingleObject` above `nvwgf2umx!OpenAdapter10` above `d3d11!NDXGI::CDevice::ReclaimResourcesImpl`, in our `DxEngine::EndPaint`. We've got a pile of these around the repo. I should promote one to me the master tracking thread.
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 Resolution-Fix-Available
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#18992
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?