terminal
terminal copied to clipboard
Running WT portable as a different user on W11 24H2 completely freezes initiating users logon session
Windows Terminal version
1.21.2911.0 Happens also with previous versions both stable and preview but all portable.
Windows build number
10.0.26100.2033
Other Software
Default profile can be either Windows PowerShell or PowerShell
Steps to reproduce
Windows 11 24H2 fully patched and domain joined. WT portable is in stalled to root of local drive e.g. C:\WT or D:\WT Logon as a domain user Start windowsterminal.exe > right-click > Run as a different user - account is in initiated with YubiKey smartcard logon. Type a command e.g. get-adcomputer xxx123 Whole logon session for initiating users freezes and becomes unusable. Sometime a remote logoff of frozen logon can be forced, and the computer returns to normal operation. User can log back on and work normally. Sometimes a hard reboot is needed. We have verified this happens on several different computers and users. This can happen after in place upgrade from 23H2 to 24H2 via Windows Update or with completely clean 24H2 install. It does not happen on prior versions of the OS 23H2. Running other applications as a different user does not provoke this behavior. Next troubleshooting step will be to determine if it is related to just running as a different user or specifically to a different user using a smartcard.
Expected Behavior
WT works normally when run as another user and does not freeze the initiating account logon.
Actual Behavior
Whole logon session for initiating users freezes and becomes unusable. Sometime a remote logoff of frozen logon can be forced, and the computer returns to normal operation. User can log back on and work normally. Sometimes a hard reboot is needed.
other notes. The logon session is not completely dead. Mouse moves albeit slowly. Seems everything is delayed hugely. Sometimes Explorer crashes and does not restart. This can happen with both a user sat at local desktop console or via a rdp session.
I can confirm that this seems to explicitly be related to run as a different user when smartcard is required for logon to the different user account. Starting WT with run as a different user where account is normal logon (not smartcard) works.
Also I can replicate the exact issue on Windows Server 2025 26100 with last stable cumulative patch.
Thanks for filing. There's a possibility this is some weird XAML deadlock. We'll look into it further.
Carlos, Thanks for the update. Not really sure how to troubleshoot further as the whole initiating session just freezes. It is consistent on multiple different computers (all physical that we saw issues on) and different users, but all running W11 24H2 or WS 2025. Let me know if I can provide anything else to help. Pete
Pete Gomersall
I get it when running the local installed version after elevating it as admin after a while. Mouse moves slowly, can't click on anything, CTRL+Shift+Esc doesn't bring up task manager so i have to hard reboot every time to get it going again.
It happens on every domain joined computer using 24H2 in my organisation.
If you run Terminal as an admin or other user, any next prompt for elevating privalages will not show resulting in frozen screen and moving cursor. You can't click anything, no keypress works.
Only hard reboot.
Facing the same issue here, I run elevated terminal app from a standard user account, after a minute only the mouse moves and nothing responds,
Does enabling this setting fix this? You can find it in the settings UI under the Rendering page.
Does enabling this setting fix this? You can find it in the settings UI under the Rendering page.
@carlos-zamora I will test on affected systems when I am physically present, not over RDP and get back to this thread.
@carlos-zamora Nope. The setting didn't help
Does enabling this setting fix this? You can find it in the settings UI under the Rendering page.
@carlos-zamora Carlos, I can also confirm that this setting DOES NOT fix the issue.
I think the problem with "invisible prompt" happens with "User Account Control: Switch to the secure desktop when prompting for elevation setting" GPO setting enabled.
I think the problem with "invisible prompt" happens with "User Account Control: Switch to the secure desktop when prompting for elevation setting" GPO setting enabled.
This setting is enabled by default. Does setting it to Disabled stop the issue occurring?
This setting is enabled by default. Does setting it to Disabled stop the issue occurring?
So, I do not think this is an acceptable approach even if it worked; we should not be disabling security to fix an issue with Terminal. In my testing doing this (disabling secure desktop) did not fix the issue. Terminal works fine in 23H2, just not in 24H2. The problem needs to be investigated by those working on the project; it then needs fixing. Given that Terminal is a key tool of most system administrators that regularly need to elevate or run as a different user this is a major issue that needs to be resolved.
fwiw I think everyone agrees that disabling UAC is a terrible solution to a problem
(it's also the holidays and most all the team is out for the year)
I am experiencing this issue as well. If I have a windows terminal running as an admin (elevated session) and then I try to lock my screen, the screens will turn black and I will only see a mouse cursor. Control-alt-delete, etc fail to respond. The behavior is exactly identical to that described in https://github.com/microsoft/terminal/issues/18224 however it looks like that issue was marked as a duplicate of this issue. I am running windows 11 24H2 and I did not observe this behavior on 23H2.
@cruzian80 you said: "Experienced the same issue when running terminal as admin after providing credentials. After changing Terminal host app to "Windows Console Host" from 'Windows Terminal" in 'Settings > System > For developers', I no longer experienced this. Version 24H2 (OS Build 26100.2605) Terminal Version: 1.21.3231.0"
These settings have always been set for me and have no effect on the outcome. I can always induce the session locking and becoming un-usable up by doing the following:
- Start Terminal as another user.
- Open an application that requires elevation – at this point system locks up.
Pete Gomersall
Same thing as #18428 and as described here https://answers.microsoft.com/en-us/windowsclient/forum/all/issues-with-24h2-and-uac-prompts-and-screen-lock/5df375ae-4a6a-474f-baa8-107881a2e15f
Have shutdown the computer by holding the power button is the only solution after freezing. How can an application do this? Seems an OS bug.
Similar problem for me, also locking up the whole computer...
I've reported my issue to #18428 as i'm not running on a portable instance but the issue is pretty much identical with the steps provided here.
Not running portable but I've a simular problem, if I start Terminal as another user and locks the computer the computer hangs with a cursor and a black screen. I can move the cursor but that's all. Need to hold the power button to restart.
Windows 11 24H2
Windows-terminal Version: 1.21.10351.0
Any update on this bug fix?
I've looped in the right folks. Sorry to let this devastating bug go on for so long, but it appears to be squarely outside of our code and somewhere in user32.
For all who have this specific issue with session lock ups when running as different user and using portable versions. I have been told by MS that they believe they have isolated the issue causing this and have suggested a work around. This involves making sure that the Personalization Accent Color settings are set to exactly the same for all users i.e. the user initiating the use, and the one running under "run as a different user". This requires logging on interactively as all users that may be called by the run as process and setting those Personalization Colors to make them identical. I tested setting Accent color to Manual and color to "Storm". I have tested this on a number of different W11 24H2 and Server 2025 systems and verified that I have not had the problem I initially described in this issue ticket. It may also apply\improve running other tools that require elevation that are called via run as that raise a UAC prompt and see sessions lock ups. Note that it seems to fix the issue for both Stable and Preview portables but seems to cause other negative issues with Preview portable so I would not recommend that version.
@PGomersall Unfortunately your workaround doesn't work for me. I've set up the same accent color on all users and PC still hangs on UAC prompt when elevated Terminal is running.
@Flapu7 - more work for MS where elevation is required. In my test cases I have not been running Terminal elevated, just as a different user. I have opened other applications (e.g. ADUC) while multiple Terminal windows are running though where UAC is prompted, and these have not caused the issues for me that I previously had.
Same issue highlighted here: https://answers.microsoft.com/en-us/windows/forum/all/black-screen-with-only-cursor-upon-lock-with/cbb260ea-8aee-4f61-a9c2-50a74d23dcb2
It is frustrating for us developers when the Windows Update causes this issue. Any workaround?
Any workaround?
I would encourage you to read the recent posts in this thread. Reading the highly-discussed thread reporting the same issue you found is the only way to determine whether there is a workaround for such issue.
Having same elevation issue as @Flapu7 - UAC prompts work fine until I start an elevated Terminal.
For additional context, I read somewhere that issue could be related to Windows Spotlight and want to confirm I'm using a static image, not spotlight. Additionally a similar thing happened when I tried to switch desktop to static color instead of image - mouse slowed down, fan started zooming and PC went unresponseive. Once I restarted the desktop was changed to static image
I run Windows 11 Enterprise and Windows Terminal (MSI install) current version; I routinely run an elevated instance of Windows Terminal under the context of a different AD username.
I recently received the 24H2 upgrade and began experiencing this issue; I was able to reproduce it reliably.
Today I found this thread, logged into Windows under each account, disabled transparency and set the same manually-selected accent color under each account; now I seem unable to reproduce the issue (so far).