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

Powershell settings not preserved on Windows upgrade #592

New Issue
Closed
opened 2026-01-30 21:56:20 +00:00 by claunia · 6 comments
claunia commented 2026-01-30 21:56:20 +00:00
Owner
Copy Link

Originally created by @winstliu on GitHub (Mar 20, 2019).

  • Your Windows build number: (Type ver at a Windows Command Prompt)
    Microsoft Windows [Versión 10.0.18361.1]

  • What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)
    When I update to a new Insider build, most of my custom settings for Powershell are not retained and seem to reset to the default. Here's what my terminal looks like after an upgrade:
    powershell-incorrect-win-x
    This is when starting it through the Win+X menu. The colors are completely wrong:
    powershell-incorrect-colors

The font size is also 14, instead of the 16 it should be.

Interestingly, starting it through Win+R (powershell) results in the following:
powershell-incorrect-win-r
When running it this way, the font size and colors are correct, though the foreground and background colors are still wrong.

Default options are still correct.

  • What's wrong / what should be happening instead:
    Here's what it should look like:
    powershell-correct
    powershell-correct-colors

This does not affect cmd or WSL, which both retain their settings as expected.

Possibly relevant information:

  • My system language is Spanish (Spain), but English (United States) is the default language for applications
  • The codepage in use is 437

Let me know if this belongs in the Powershell repo instead.

Originally created by @winstliu on GitHub (Mar 20, 2019). * Your Windows build number: (Type `ver` at a Windows Command Prompt) `Microsoft Windows [Versión 10.0.18361.1]` * What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots) When I update to a new Insider build, most of my custom settings for Powershell are not retained and seem to reset to the default. Here's what my terminal looks like after an upgrade: ![powershell-incorrect-win-x](https://user-images.githubusercontent.com/2766036/54700651-cbf30100-4b09-11e9-816d-9f884127dd23.png) This is when starting it through the Win+X menu. The colors are completely wrong: ![powershell-incorrect-colors](https://user-images.githubusercontent.com/2766036/54700806-17a5aa80-4b0a-11e9-8203-7f413026ed03.png) The font size is also 14, instead of the 16 it should be. Interestingly, starting it through Win+R (`powershell`) results in the following: ![powershell-incorrect-win-r](https://user-images.githubusercontent.com/2766036/54700735-fb097280-4b09-11e9-8388-d05075692d86.png) When running it this way, the font size and colors are correct, though the foreground and background colors are still wrong. Default options are still correct. * What's wrong / what should be happening instead: Here's what it should look like: ![powershell-correct](https://user-images.githubusercontent.com/2766036/54700991-64898100-4b0a-11e9-8d91-9e47dbc86a8a.png) ![powershell-correct-colors](https://user-images.githubusercontent.com/2766036/54701002-70754300-4b0a-11e9-91a0-53ba29ebfb27.png) This does _not_ affect `cmd` or WSL, which both retain their settings as expected. Possibly relevant information: * My system language is Spanish (Spain), but English (United States) is the default language for applications * The codepage in use is 437 Let me know if this belongs in the Powershell repo instead.
claunia commented 2026-01-30 21:56:21 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Mar 20, 2019):

Did you start Powershell from a pre-existing shortcut in either the Start Menu or the WinKey+X menu?

Or do you have your own Powershell shortcut somewhere?
Or are you starting Powershell from the Run Box or somewhere else?

@miniksa commented on GitHub (Mar 20, 2019): Did you start Powershell from a pre-existing shortcut in either the Start Menu or the WinKey+X menu? Or do you have your own Powershell shortcut somewhere? Or are you starting Powershell from the Run Box or somewhere else?
claunia commented 2026-01-30 21:56:22 +00:00
Author
Owner
Copy Link

@winstliu commented on GitHub (Mar 20, 2019):

Oh, I thought I included that information. Whoops!
The completely incorrect (dark blue) screenshots are from Win+X. The one that's mostly right (cyan foreground) is from the Run box.

After fixing the settings, it doesn't matter where I start Powershell from, they're all correct.

@winstliu commented on GitHub (Mar 20, 2019): Oh, I thought I included that information. Whoops! The completely incorrect (dark blue) screenshots are from Win+X. The one that's mostly right (cyan foreground) is from the Run box. After fixing the settings, it doesn't matter where I start Powershell from, they're all correct.
claunia commented 2026-01-30 21:56:22 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Mar 20, 2019):

Unfortunately when you start from an in-built shortcut (Win+X or the one that is already there for you in the start menu) and use the Properties page to save settings, those settings are embedded inside the LNK shortcut file.

And even more unfortunately on every build-to-build upgrade, they're helpfully recreated for you in the new OS build. Then the upgrade engine attempts to copy the properties from the old OS build to the new one. However, the engine doesn't know how to copy the settings embedded by the console inside the LNK so they get lost.

We have a long standing backlog item to write an upgrade migration plugin to move these settings since the upgrade engine won't do it by default, but we haven't gotten around to it because other things are higher priority and it's absolutely no joy to write a migration plugin.

The backlog item is MSFT: 8213510.

I swear there's a GitHub issue about this already, but I can't seem to find it at the moment. Therefore, I'll tag this one up.

Until then, I recommend that you use a launch pattern that stores the settings in an upgrade-friendly location (either with the run box so they're stored in the registry at HKCU\Console* or your own LNK shortcut file that isn't one of ours.) Using the Defaults menu on right click always stores at HKCU\Console in the registry at the root of our path so it should migrate properly.

For a bit more information, you can review a blog post we created about settings a while ago at https://devblogs.microsoft.com/commandline/understanding-windows-console-host-settings/

@miniksa commented on GitHub (Mar 20, 2019): Unfortunately when you start from an in-built shortcut (Win+X or the one that is already there for you in the start menu) and use the Properties page to save settings, those settings are embedded inside the LNK shortcut file. And even more unfortunately on every build-to-build upgrade, they're helpfully recreated for you in the new OS build. Then the upgrade engine attempts to copy the properties from the old OS build to the new one. However, the engine doesn't know how to copy the settings embedded by the console inside the LNK so they get lost. We have a long standing backlog item to write an upgrade migration plugin to move these settings since the upgrade engine won't do it by default, but we haven't gotten around to it because other things are higher priority and it's absolutely no joy to write a migration plugin. The backlog item is MSFT: 8213510. I swear there's a GitHub issue about this already, but I can't seem to find it at the moment. Therefore, I'll tag this one up. Until then, I recommend that you use a launch pattern that stores the settings in an upgrade-friendly location (either with the run box so they're stored in the registry at HKCU\Console\* or your own LNK shortcut file that isn't one of ours.) Using the Defaults menu on right click always stores at HKCU\Console in the registry at the root of our path so it should migrate properly. For a bit more information, you can review a blog post we created about settings a while ago at https://devblogs.microsoft.com/commandline/understanding-windows-console-host-settings/
claunia commented 2026-01-30 21:56:22 +00:00
Author
Owner
Copy Link

@winstliu commented on GitHub (Mar 20, 2019):

Okay, thanks.

@winstliu commented on GitHub (Mar 20, 2019): Okay, thanks.
claunia commented 2026-01-30 21:56:23 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 10, 2022):

You know, I'm gonna cut this one as Wont-Fix.

We certainly could write a migration plugin for this. It would have to be authored OS-side, not in github. But considering our general story is "if you want a modern commandline experience, use the Windows Terminal", then I frankly don't think this is worth our time to do for the vintage console. If there's a massive outcry and people really need the migration for the vintage console .lnk settings, then they're free to upvote this thread (and tell us why they're still using the vintage console instead of the Terminal 😝)

@zadjii-msft commented on GitHub (Jan 10, 2022): You know, I'm gonna cut this one as Wont-Fix. We certainly _could_ write a migration plugin for this. It would have to be authored OS-side, not in github. But considering our general story is "if you want a modern commandline experience, use the Windows Terminal", then I frankly don't think this is worth our time to do for the vintage console. If there's a massive outcry and people _really_ need the migration for the vintage console .lnk settings, then they're free to upvote this thread (and tell us why they're still using the vintage console instead of the Terminal 😝)
claunia commented 2026-01-30 21:56:24 +00:00
Author
Owner
Copy Link

@winstliu commented on GitHub (Jan 10, 2022):

No objections from me - I don't even remember opening this issue 😄. I guess that tells you how many times I've had to open just PowerShell since Windows Terminal came out 😉.

@winstliu commented on GitHub (Jan 10, 2022): No objections from me - I don't even remember opening this issue 😄. I guess that tells you how many times I've had to open _just_ PowerShell since Windows Terminal came out 😉.
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 Area-Settings Issue-Feature Product-Conhost Resolution-Won't-Fix Work-Item
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#592
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?