PowerShell can crash on startup when displaying the update notification under zh-Hans due to negative PadRight width

Prerequisites

Write a descriptive title.
Make sure you are able to repro it on the latest released version
Search the existing issues.
Refer to the FAQ.
Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

The problem occurs in the update-notification formatting path when the UI culture is zh-Hans.

I originally encountered the crash with PowerShell 7.7.0-preview.4 when a newer preview release became eligible for notification.

The relevant code is in:

src/Microsoft.PowerShell.ConsoleHost/host/msh/UpdatesNotification.cs

inside UpdatesNotification.ShowUpdateNotification():

// The first line is longest, if the message changes, this needs to be updated
int line1Length = notificationMsgTemplate.IndexOf('\n');
int line2Length = notificationMsgTemplate.IndexOf('\n', line1Length + 1);
int line3Length = notificationMsgTemplate.IndexOf('\n', line2Length + 1);

line3Length -= line2Length + 1;
line2Length -= line1Length + 1;

line2Padding = line2Padding.PadRight(
    line1Length - line2Length + releaseTag.Length
);

// 3 represents the extra placeholder in the template
line3Padding = line3Padding.PadRight(
    line1Length - line3Length + 3
);

The code assumes that the first line of the localized notification is the longest.

However, the Simplified Chinese resource in:

src/Microsoft.PowerShell.ConsoleHost/resources/zh-Hans/ManagedEntranceStrings.zh-Hans.resx

contains the following PreviewUpdateNotificationMessage:

  {1} 有新的 PowerShell 预览版本可用: v{0} {2}
  {1} 立即升级，或访问发布页:{3}{2}
  {1}   https://aka.ms/PowerShell-Release?tag=v{0} {4}{2}

The issue can be reproduced independently from the notification state with:

$lines = @(
    '  {1} 有新的 PowerShell 预览版本可用: v{0} {2}'
    '  {1} 立即升级，或访问发布页:{3}{2}'
    '  {1}   https://aka.ms/PowerShell-Release?tag=v{0} {4}{2}'
)

$lines | ForEach-Object { $_.Length }

# 37
# 24
# 57

$paddingWidth = $lines[0].Length - $lines[2].Length + 3
$paddingWidth

# -17

''.PadRight($paddingWidth)

This produces the same invalid padding width seen in the startup crash:

-17

The exact calculation performed by ShowUpdateNotification() is:

line1Length - line3Length + 3
= 37 - 57 + 3
= -17

Therefore it eventually attempts the equivalent of:

string.Empty.PadRight(-17)

which throws ArgumentOutOfRangeException.

The same formatting logic and the same zh-Hans resource text are still present in the latest preview release, v7.7.0-preview.5.

When an eligible update notification is actually shown, the startup failure is:

Process terminated.
totalWidth ('-17') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -17.

   at System.Environment.FailFast(System.Runtime.CompilerServices.StackCrawlMarkHandle, System.String, System.Runtime.CompilerServices.ObjectHandleOnStack, System.String)
   at System.Environment.FailFast(System.Threading.StackCrawlMark ByRef, System.String, System.Exception, System.String)
   at System.Environment.FailFast(System.String, System.Exception)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(System.String[], Int32)
   at Microsoft.PowerShell.ManagedPSEntry.Main(System.String[])
System.ArgumentOutOfRangeException: totalWidth ('-17') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -17.
   at System.ArgumentOutOfRangeException.ThrowNegative[T](T value, String paramName)
   at System.String.PadRight(Int32 totalWidth, Char paddingChar)
   at Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification(PSHostUserInterface hostUI)
   at Microsoft.PowerShell.ConsoleHost.Start(String bannerText, String helpText, Boolean issProvidedExternally)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(String[] args, Int32 argc)

Setting:

setx POWERSHELL_UPDATECHECK Off

avoids the crash by preventing the update-notification path from running.

Expected behavior

PowerShell should start normally and display the localized update notification.

Notification formatting should work regardless of the relative lengths of localized message lines.

Actual behavior

When the zh-Hans update notification is displayed, ShowUpdateNotification() calculates a negative padding width because the third line is longer than the first line.

For the preview notification resource:

line 1 length = 37
line 3 length = 57

so:

37 - 57 + 3 = -17

This value is passed to String.PadRight(), which throws ArgumentOutOfRangeException.

Because this happens during console-host startup, the PowerShell process terminates instead of opening an interactive session.

The underlying assumption appears to be this comment in UpdatesNotification.cs:

// The first line is longest, if the message changes, this needs to be updated

That assumption is not valid for all localized resources.

Error details

`Get-Error` cannot be collected from the affected process because the exception occurs during PowerShell console-host startup and the process terminates through `Environment.FailFast()` before an interactive session is available.

The verbatim startup output is:


Process terminated.
totalWidth ('-17') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -17.

   at System.Environment.FailFast(System.Runtime.CompilerServices.StackCrawlMarkHandle, System.String, System.Runtime.CompilerServices.ObjectHandleOnStack, System.String)
   at System.Environment.FailFast(System.Threading.StackCrawlMark ByRef, System.String, System.Exception, System.String)
   at System.Environment.FailFast(System.String, System.Exception)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(System.String[], Int32)
   at Microsoft.PowerShell.ManagedPSEntry.Main(System.String[])
System.ArgumentOutOfRangeException: totalWidth ('-17') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -17.
   at System.ArgumentOutOfRangeException.ThrowNegative[T](T value, String paramName)
   at System.String.PadRight(Int32 totalWidth, Char paddingChar)
   at Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification(PSHostUserInterface hostUI)
   at Microsoft.PowerShell.ConsoleHost.Start(String bannerText, String helpText, Boolean issProvidedExternally)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(String[] args, Int32 argc)

Environment data

PASTE THE VERBATIM OUTPUT OF:

$PSVersionTable

The original startup crash was observed with:

PowerShell 7.7.0-preview.4

The relevant implementation and zh-Hans resource remain unchanged in v7.7.0-preview.5.

Visuals

Not required. The failure occurs during console-host startup and is fully represented by the stack trace above.

same

Got this error too.

I hit the same crash on the stable release with the Japanese UI culture.

Environment

PowerShell 7.6.6 (stable)
Windows 11, Windows Terminal
UI culture: ja-JP

What happened
pwsh crashed on startup right after the banner. I think the trigger was the update notification for 7.6.7.

PowerShell 7.6.6
Process terminated.
totalWidth ('-10') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -10.
   at System.Environment.FailFast(System.Runtime.CompilerServices.StackCrawlMarkHandle, System.String, System.Runtime.CompilerServices.ObjectHandleOnStack, System.String)
   at System.Environment.FailFast(System.Threading.StackCrawlMark ByRef, System.String, System.Exception, System.String)
   at System.Environment.FailFast(System.String, System.Exception)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(System.String[], Int32)
   at Microsoft.PowerShell.ManagedPSEntry.Main(System.String[])
System.ArgumentOutOfRangeException: totalWidth ('-10') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -10.
   at System.ArgumentOutOfRangeException.ThrowNegative[T](T value, String paramName)
   at System.String.PadRight(Int32 totalWidth, Char paddingChar)
   at Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification(PSHostUserInterface hostUI)
   at Microsoft.PowerShell.ConsoleHost.Start(String bannerText, String helpText, Boolean issProvidedExternally)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(String[] args, Int32 argc)

Workaround
setx POWERSHELL_UPDATECHECK Off and restarting all Windows Terminal windows fixed it.

So this is not only a zh-Hans issue. It seems to affect the stable channel and other localized resources (ja-JP) too.

Same here

powershell 7.6.6
windows 11 26200.9711, windows terminal

PowerShell 7.6.6
Process terminated.
totalWidth ('-11') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -11.
   at System.Environment.FailFast(System.Runtime.CompilerServices.StackCrawlMarkHandle, System.String, System.Runtime.CompilerServices.ObjectHandleOnStack, System.String)
   at System.Environment.FailFast(System.Threading.StackCrawlMark ByRef, System.String, System.Exception, System.String)
   at System.Environment.FailFast(System.String, System.Exception)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(System.String[], Int32)
   at Microsoft.PowerShell.ManagedPSEntry.Main(System.String[])
System.ArgumentOutOfRangeException: totalWidth ('-11') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -11.
   at System.ArgumentOutOfRangeException.ThrowNegative[T](T value, String paramName)
   at System.String.PadRight(Int32 totalWidth, Char paddingChar)
   at Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification(PSHostUserInterface hostUI)
   at Microsoft.PowerShell.ConsoleHost.Start(String bannerText, String helpText, Boolean issProvidedExternally)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(String[] args, Int32 argc)

+1
dsh已修复,关掉了更新提醒
这是一个到 08:00 才触发的、时间一到才会触发的根源
以前没有在8点之前开过机所以没有触发?可能

same crash on the stable release with the Korean UI culture.

Environment

PowerShell 7.6.6 (stable)
Windows 11, Windows Terminal
UI culture: ko-KR

C:\Users>pwsh
PowerShell 7.6.6
Process terminated.
totalWidth ('-23') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -23.
   at System.Environment.FailFast(System.Runtime.CompilerServices.StackCrawlMarkHandle, System.String, System.Runtime.CompilerServices.ObjectHandleOnStack, System.String)
   at System.Environment.FailFast(System.Threading.StackCrawlMark ByRef, System.String, System.Exception, System.String)
   at System.Environment.FailFast(System.String, System.Exception)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(System.String[], Int32)
   at Microsoft.PowerShell.ManagedPSEntry.Main(System.String[])
System.ArgumentOutOfRangeException: totalWidth ('-23') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -23.
   at System.ArgumentOutOfRangeException.ThrowNegative[T](T value, String paramName)
   at System.String.PadRight(Int32 totalWidth, Char paddingChar)
   at Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification(PSHostUserInterface hostUI)
   at Microsoft.PowerShell.ConsoleHost.Start(String bannerText, String helpText, Boolean issProvidedExternally)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(String[] args, Int32 argc)

C:\Users>pwsh -NoLogo
PS C:\Users> $PSUICulture
ko-KR

Confirming this on the stable channel (7.6.6, MSI) with zh-CN, with the exact numbers measured from the shipped localized resources. This is not limited to the preview template, and it explains the burst of "same" reports in this thread today.

Environment (verbatim)

PSVersion      7.6.6
PSEdition      Core
GitCommitId    7.6.6
OS             Microsoft Windows 10.0.26300 (Windows 11), Windows Terminal
UI culture     zh-CN
Install        C:\Program Files\PowerShell\7  ("PowerShell 7-x64", 7.6.6.0)

Why it started happening for everybody at 2026-10-20 00:00 UTC

ShowUpdateNotification() does nothing until the notified release is NotificationDelayDays (7) days old. 7.6.7 was published 2026-10-13, so the first startup where the banner became eligible was 2026-10-20T00:00Z = 08:00 Asia/Shanghai — exactly when zh-CN, ja-JP and ru-RU users started reporting this. On this machine the trigger file is %LOCALAPPDATA%\Microsoft\PowerShell\7.6.6\update1_v7.6.7_2026-10-13.

One detail worth adding to the analysis: the repository contains no zh-Hans/*.resx. The localized strings only ship inside the satellite assemblies, e.g. $PSHOME\zh-Hans\Microsoft.PowerShell.ConsoleHost.resources.dll, so this cannot be spotted by reading resources/ in the repo. Also note that both line1Length and line3Length are measured in characters, which is why CJK text ends up far "shorter" than the ASCII URL line below it.

Measured from the shipped `zh-Hans` satellite assembly

resource key	line 1	line 2	line 3	`line1 - line3 + 3`
`StableUpdateNotificationMessage`	38	25	58	-17
`LTSUpdateNotificationMessage`	40	25	58	-15
`PreviewUpdateNotificationMessage`	38	25	58	-17
neutral (en) `StableUpdateNotificationMessage`	61	59	58	+6 (OK)

Consequences:

reproducible on 7.6.6 stable using the stable template — no preview build needed;
POWERSHELL_UPDATECHECK=LTS is not a workaround (-15); only POWERSHELL_UPDATECHECK=Off is (it makes CanNotifyUpdates false, so ShowUpdateNotification() is never reached);
line2Padding stays positive in every case here, so only the third line trips.

A/B proof that does not depend on the notification state

Run inside an interactive zh-CN session (there $Host.UI.SupportsVirtualTerminal is True):

$asm = [System.Reflection.Assembly]::LoadFrom("$PSHOME\Microsoft.PowerShell.ConsoleHost.dll")
$t   = $asm.GetType('Microsoft.PowerShell.UpdatesNotification')
$m   = $t.GetMethod('ShowUpdateNotification', [System.Reflection.BindingFlags]'NonPublic,Static')
$f   = $t.GetField('CanNotifyUpdates', [System.Reflection.BindingFlags]'NonPublic,Static')

"CanNotifyUpdates = $($f.GetValue($null))"
$m.Invoke($null, @($Host.UI))

Results:

POWERSHELL_UPDATECHECK unset → CanNotifyUpdates = True → ArgumentOutOfRangeException: totalWidth ('-17') must be a non-negative value thrown from String.PadRight via UpdatesNotification.ShowUpdateNotification(PSHostUserInterface);
POWERSHELL_UPDATECHECK=Off → CanNotifyUpdates = False → the invocation returns cleanly.

The unguarded code is still present in the newest source

line3Padding.PadRight(line1Length - line3Length + 3) is unchanged at line 136 of UpdatesNotification.cs in v7.6.6, v7.6.7 and master, so no currently shipped build is fixed, and upgrading 7.6.6 → 7.6.7 does not help.

Suggested minimal fix

Clamp both widths (PadRight(Math.Max(0, line1Length - line3Length + 3))), and preferably derive the padding from the longest of the three lines instead of assuming line 1 is the longest. The call happens inside ConsoleHost.Start and nothing catches it, so a purely cosmetic alignment mismatch escalates into Environment.FailFast() — i.e. "pwsh cannot start at all". A clamp keeps it cosmetic for every locale, including ones added later.

Workaround for affected users

setx POWERSHELL_UPDATECHECK Off

Then restart the whole terminal application — already-running processes keep their old environment block and will keep crashing until they are closed. The update banner is lost until the bug is fixed or the variable is removed.

Windows PowerShell 5.1 is unaffected; it has no update notification.

This only started on stable with 7.6.6 because that's the first 7.6 release that ships translated ManagedEntranceStrings. None of the src/Microsoft.PowerShell.ConsoleHost/resources/<lang>/ManagedEntranceStrings.<lang>.resx files exist in v7.6.0 through v7.6.5 (or v7.5.5), and v7.6.6 has all 13. Up to 7.6.5 every UI culture got the English template, where the first line is the longest.

The zh-Hans file came into master with the OneLocBuild check-ins #27736 and #27821, which is why the 7.7 previews hit this first, and into release/v7.6.6 with #27918 and #27930. It's unchanged in v7.6.7 and master.

the repository contains no zh-Hans/*.resx

They are in the repo, next to the neutral resx: src/Microsoft.PowerShell.ConsoleHost/resources/zh-Hans/ManagedEntranceStrings.zh-Hans.resx.

line2Padding stays positive in every case here, so only the third line trips.

That holds for zh-Hans but not for every language. I ran the stable template from each 7.6.6 satellite assembly through the same calculation with 7.6.7 as the release tag: 9 of the 13 go negative (cs, de, fr, it, ja, ko, ru, zh-Hans, zh-Hant), and for cs, de, fr, it, ko and ru it's line 2 that goes negative first. The ko-KR report above (-23) is one of those. So both paddings need the clamp.

same issue, update to PowerShell 7.6.7 it seems be ok

PowerShell 7.6.6
Process terminated.
totalWidth ('-17') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -17.
   at System.Environment.FailFast(System.Runtime.CompilerServices.StackCrawlMarkHandle, System.String, System.Runtime.CompilerServices.ObjectHandleOnStack, System.String)
   at System.Environment.FailFast(System.Threading.StackCrawlMark ByRef, System.String, System.Exception, System.String)
   at System.Environment.FailFast(System.String, System.Exception)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(System.String[], Int32)
   at Microsoft.PowerShell.ManagedPSEntry.Main(System.String[])
System.ArgumentOutOfRangeException: totalWidth ('-17') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -17.
   at System.ArgumentOutOfRangeException.ThrowNegative[T](T value, String paramName)
   at System.String.PadRight(Int32 totalWidth, Char paddingChar)
   at Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification(PSHostUserInterface hostUI)
   at Microsoft.PowerShell.ConsoleHost.Start(String bannerText, String helpText, Boolean issProvidedExternally)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(String[] args, Int32 argc)
[已退出进程，代码为 2148734499 (0x80131623)]

Same crash here on the stable channel with a different locale, so this isn't limited to zh-Hans or preview builds.

PowerShell 7.6.6, Windows (Windows Terminal)
UI culture: ko-KR

Process terminated.
totalWidth ('-23') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -23.
   at System.String.PadRight(Int32 totalWidth, Char paddingChar)
   at Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification(PSHostUserInterface hostUI)
   at Microsoft.PowerShell.ConsoleHost.Start(String bannerText, String helpText, Boolean issProvidedExternally)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(String[] args, Int32 argc)

POWERSHELL_UPDATECHECK=Off works around it.

I encountered the same issue on PowerShell 7.6.6 on Windows with the Simplified Chinese (zh-Hans) locale.

The process crashes on startup with the exact same error:

totalWidth ('-17') must be a non-negative value. (Parameter 'totalWidth')

The stack trace points to Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification().

Disabling update notifications with setx POWERSHELL_UPDATECHECK Off allows PowerShell to start normally.

This is a frustrating startup-breaking bug for regular users. Please consider prioritizing a fix, since a localized update notification should never be able to crash the entire PowerShell process.

PowerShell 7.6.6
Process terminated.
totalWidth ('-17') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -17.
   at System.Environment.FailFast(System.Runtime.CompilerServices.StackCrawlMarkHandle, System.String, System.Runtime.CompilerServices.ObjectHandleOnStack, System.String)
   at System.Environment.FailFast(System.Threading.StackCrawlMark ByRef, System.String, System.Exception, System.String)
   at System.Environment.FailFast(System.String, System.Exception)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(System.String[], Int32)
   at Microsoft.PowerShell.ManagedPSEntry.Main(System.String[])
System.ArgumentOutOfRangeException: totalWidth ('-17') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -17.
   at System.ArgumentOutOfRangeException.ThrowNegative[T](T value, String paramName)
   at System.String.PadRight(Int32 totalWidth, Char paddingChar)
   at Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification(PSHostUserInterface hostUI)
   at Microsoft.PowerShell.ConsoleHost.Start(String bannerText, String helpText, Boolean issProvidedExternally)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(String[] args, Int32 argc)
[已退出进程，代码为 2148734499 (0x80131623)]
现在可以使用Ctrl+D关闭此终端，或按 Enter 重新启动。

Got this error too.

Same crash on 7.6.6 stable with zh-Hant (totalWidth ('-13')).

For those who don’t want to disable the update check (POWERSHELL_UPDATECHECK=Off), here is a quick fix that simply upgrades to the latest version:

Open cmd and run:
powershell

(Windows PowerShell 5.1 is not affected.)

Paste the official install script and run it:
iex "& { $(irm https://aka.ms/install-powershell.ps1) } -UseMSI"

Finish the installer, then open PowerShell 7 again. It starts normally.

If it happens again after a future release, just repeat these steps.

Correction for anyone finding this thread through search results: upgrading to 7.6.7 does not fix this.

7.6.7 only looks fixed because it is the newest release, so no update notification is eligible yet. The unguarded calculation is unchanged in v7.6.7 and in master (see the PR #28236 description), and that PR is not merged or backported yet. The moment the next servicing release (7.6.8) crosses the 7-day NotificationDelayDays window, every affected locale crashes again on startup, with no visible cause for the user.

Verified on a zh-CN Windows 11 machine, PowerShell 7.6.6 MSI install, values read from the shipped $PSHOME\zh-Hans\Microsoft.PowerShell.ConsoleHost.resources.dll:

template	line 1	line 2	line 3	`line1 - line3 + 3`
`StableUpdateNotificationMessage`	38	25	58	-17
`LTSUpdateNotificationMessage`	40	25	58	-15
`PreviewUpdateNotificationMessage`	38	25	58	-17

So POWERSHELL_UPDATECHECK=LTS is not a workaround either; only Off prevents the code path from running (CanNotifyUpdates == false).

One more thing worth adding to the workaround instructions, because it traps people into thinking the fix did not work:

Windows Terminal's "Press Enter to restart" is not enough. The restarted shell inherits the environment block of the already-running WindowsTerminal.exe process, so a shell restarted that way keeps crashing even after setx POWERSHELL_UPDATECHECK Off succeeded. The whole terminal window has to be closed and reopened (or a brand-new terminal instance launched from a process that was started after the variable was set).

For the fix itself, a clamp handles the crash, but since both line1Length and line3Length are measured with String.Length while CJK characters occupy two columns, the resulting alignment will still be visually off for those locales. Deriving the padding from the widest line, or measuring display width instead of character count, would fix the layout too - the clamp only stops the process from dying.

help：PowerShell 7.6.6
Process terminated.
totalWidth ('-17') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -17.
at System.Environment.FailFast(System.Runtime.CompilerServices.StackCrawlMarkHandle, System.String, System.Runtime.CompilerServices.ObjectHandleOnStack, System.String)
at System.Environment.FailFast(System.Threading.StackCrawlMark ByRef, System.String, System.Exception, System.String)
at System.Environment.FailFast(System.String, System.Exception)
at Microsoft.PowerShell.UnmanagedPSEntry.Start(System.String[], Int32)
at Microsoft.PowerShell.ManagedPSEntry.Main(System.String[])
System.ArgumentOutOfRangeException: totalWidth ('-17') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -17.
at System.ArgumentOutOfRangeException.ThrowNegative[T](T value, String paramName)
at System.String.PadRight(Int32 totalWidth, Char paddingChar)
at Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification(PSHostUserInterface hostUI)
at Microsoft.PowerShell.ConsoleHost.Start(String bannerText, String helpText, Boolean issProvidedExternally)
at Microsoft.PowerShell.UnmanagedPSEntry.Start(String[] args, Int32 argc)

29. I can reproduce the same problem on PowerShell 7.6.7.
Interesting detail: The crash only occurs when launching PowerShell from the Start Menu. Opening an additional tab afterwards works correctly.

Also crash from task manager or VS Code terminal.

6. +1
dsh已修复,关掉了更新提醒
这是一个到 08:00 才触发的、时间一到才会触发的根源
以前没有在8点之前开过机所以没有触发?可能

是之前没有新版本，没有触发这个bug。最近发了新版本，更新检测到了新版本所以崩溃。所以解决方案就是禁用启动自动检查更新。

Thank you all for reporting the issue and I'm sorry that us maintainers didn't notice this issue report earlier.
The PowerShell team has decided to remove the Update Notification feature as it provides increasingly limited additional value nowadays.
The PR #28242 has been merged, and we will backport it to v7.6 in the next servicing release.

[UPDATE on 10/22/2026] The v7.6.8 release is out with the Update Notification change backported.

i was also hit by this error

this bug was absurd.

basically you release a function that hits all CJK users who uses powershell. non-expert user are very hard to do anything about it because the powershell crash at start.

shame on you.

Use lower version powershell (system builtin) to execute following command:

setx POWERSHELL_UPDATECHECK Off

Then open the Powershell 7, problem fixed.

It's interesting, that our powershell 7's team choosed remove this function instead of fix this function to avoid that fatal.

This is not only CJK users - I can reproduce the error with 7.6.6 and locale 'en-US'. Running setx POWERSHELL_UPDATECHECK Off fixes the startup, setx POWERSHELL_UPDATECHECK On breaks it again.

It's somewhat concerning that removing the update notification mechanism entirely means macOS users will never know there is an update available using the recommended install method unless they also have Visual Studio Code installed. The Microsoft AutoUpdate tool for macOS does not check PowerShell.

Is there any update notification mechanism for macOS users?

31. It's somewhat concerning that removing the update notification mechanism entirely means macOS users will never know there is an update available using the recommended install method unless they also have Visual Studio Code installed. The Microsoft AutoUpdate tool for macOS does not check PowerShell.
Is there any update notification mechanism for macOS users?

I agree and commented on this issue which does the removal

#28242

I am on Linux and install using the tar.gz files. Seems they forgot about everybody that is not on Windows but uses pwsh.

30. It's somewhat concerning that removing the update notification mechanism entirely means macOS users will never know there is an update available using the recommended install method unless they also have Visual Studio Code installed. The Microsoft AutoUpdate tool for macOS does not check PowerShell.
Is there any update notification mechanism for macOS users?

subscribe to this repo?

 subscribe to this repo?

That's great for people that know about the repo, not so great for regular users who may never visit GitHub.

I reproduced this on PowerShell 7.6.7 (stable) in Windows Terminal with a zh-CN UI culture on Windows 11 (build 26200). PowerShell exits immediately after printing the version banner:

PowerShell 7.6.7
Process terminated.
totalWidth ('-17') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -17.
   at System.String.PadRight(Int32 totalWidth, Char paddingChar)
   at Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification(PSHostUserInterface hostUI)
   at Microsoft.PowerShell.ConsoleHost.Start(...)

This confirms that 7.6.7 was affected as well. I found the existing issue while diagnosing the startup failure and am updating to a release with the notification change.

Navigation Menu

Repository navigation

PowerShell can crash on startup when displaying the update notification under zh-Hans due to negative PadRight width #28131

Prerequisites

Steps to reproduce

Expected behavior

Actual behavior

Error details

Environment data

Visuals

Environment (verbatim)

Why it started happening for everybody at 2026-10-20 00:00 UTC

Measured from the shipped `zh-Hans` satellite assembly

A/B proof that does not depend on the notification state

The unguarded code is still present in the newest source

Suggested minimal fix

Workaround for affected users

33 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

📋 Server Request & Proxy Logs

⚙️ Pengaturan Proxy Target

PowerShell can crash on startup when displaying the update notification under zh-Hans due to negative PadRight width #28131

Description

Prerequisites

Steps to reproduce

Expected behavior

Actual behavior

Error details

Environment data

Visuals

Activity

scarletkc commented on Oct 20, 2026

Hans1208 commented on Oct 20, 2026

MareMare commented on Oct 20, 2026

YAAkimov commented on Oct 20, 2026

wulouniu commented on Oct 20, 2026

createOne999 commented on Oct 20, 2026

Joseph4Chou commented on Oct 20, 2026

Environment (verbatim)

Why it started happening for everybody at 2026-10-20 00:00 UTC

Measured from the shipped zh-Hans satellite assembly

A/B proof that does not depend on the notification state

The unguarded code is still present in the newest source

Suggested minimal fix

Workaround for affected users

wb2324580 commented on Oct 20, 2026

chenxuuu commented on Oct 20, 2026

hwhang0917 commented on Oct 20, 2026

Dec-4th commented on Oct 20, 2026

me2seeks commented on Oct 20, 2026

panaplat commented on Oct 20, 2026

wlchen1102 commented on Oct 20, 2026

33 remaining items

qiuhengyu commented on Oct 20, 2026

FrankHB commented on Oct 20, 2026

iporer commented on Oct 20, 2026

daxian-dbw commented on Oct 20, 2026

jiajinyu commented on Oct 21, 2026

symant233 commented on Oct 21, 2026

Perxenic-Acid commented on Oct 21, 2026

pascal-bertram-bl commented on Oct 23, 2026

kwtobin commented on Oct 23, 2026

JoeSalmeri commented on Oct 26, 2026

CrookedJ commented on Oct 27, 2026

kwtobin commented on Oct 27, 2026

Thymos2027 commented on Oct 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Measured from the shipped `zh-Hans` satellite assembly