Causes and solutions for PowerShell 7.6.6 crashing immediately upon startup: ‘totalWidth’ (‘-10’) error
Target: PowerShell 7.6.6, in localized environments (such as Japanese)
Primary error: totalWidth ('-10') must be a non-negative value
Symptoms: When launching pwsh, the application terminates after 1–2 seconds, before the prompt appears.
This issue is caused by a bug in the update notification that PowerShell displays upon startup. If you need an immediate fix, please try the following workaround first.
Solution: Turn off update notifications and restart Windows.
If pwsh fails to launch, open “Windows PowerShell” from the Start menu and run the following command.
[Environment]::SetEnvironmentVariable(
'POWERSHELL_UPDATECHECK',
'Off',
'User'
)After running it, please restart Windows. In my own environment, simply closing the Claude desktop app did not resolve the issue; I confirmed that pwsh launched correctly only after restarting Windows.
When launching temporarily from the command prompt
To launch pwsh within the current command prompt session without persisting any settings, run the following:
set POWERSHELL_UPDATECHECK=Off
pwshThis setting will be lost when the command prompt is closed. If you wish to make it persistent, execute the following instead, then restart Windows.
setx POWERSHELL_UPDATECHECK OffPlease set the value to “Off.” According to an issue reported in the official PowerShell repository, this problem cannot be avoided when using the LTS version.
Disabling update notifications does not prevent you from updating PowerShell; it simply stops the notifications from appearing, so you will need to check for updates yourself as needed.
winget list --id Microsoft.PowerShell --upgrade-availableSymptoms experienced
In my environment, the issue occurred around midday on October 20, 2026.
- Windows 11 Pro 10.0.26200, Japanese UI
- PowerShell 7.6.6
- The MSI version has been installed to C:\Program Files\PowerShell\7.
- .NET 10.0.12 included with PowerShell
- None of the four profile.ps1-related profiles exist.
When I open a terminal from the “Code” tab in the Claude desktop app, pwsh exits within 1–2 seconds. The same thing happens even if I try opening it again.
The following exit code was found in the logs. Information that could identify the session has been omitted.
Shell PTY for session ... exited with code -2146232797Converting -2146232797 to a 32-bit unsigned integer in hexadecimal format yields 0x80131623. This corresponds to the .NET COR_E_FAILFAST error code, indicating that the process may have been forcibly terminated via Environment.FailFast().
The cause is a localized update notification.
UpdatesNotification.ShowUpdateNotification(), which displays update notifications, assumes that the first line of the notification text is the longest. Based on this, it calculates the necessary padding by determining the difference in character count between the first line and the subsequent lines, and then passes this value to String.PadRight().
However, when translating into languages like Japanese, subsequent lines may end up being longer. As a result, a negative value is passed to PadRight().
totalWidth ('-10') must be a non-negative value. (Parameter 'totalWidth')Because this exception is not caught during the PowerShell startup process, it results in more than just a display glitch; Environment.FailFast() is invoked, causing the entire pwsh process to terminate.
In issue #28131 on the official PowerShell repository, it is reported that an examination of the 13 languages included in PowerShell 7.6.6 revealed that the margin calculation results were negative for 9 of them: Czech, German, French, Italian, Japanese, Korean, Russian, Simplified Chinese, and Traditional Chinese.
Furthermore, since the length of a string is calculated based on the number of characters rather than its display width on screen, the positioning of frames may be misaligned—even if the application does not crash—when dealing with languages that include full-width characters.
The width of the terminal was not the cause.
At the start of the investigation, based on the cols=72 and cols=80 values found in the logs, I hypothesized that the side panel was so narrow that the calculation for the border resulted in a negative value.
However, the same issue occurred in Windows Terminal as well. The actual input value was not the width of the terminal, but rather the length of each line of the localized notification message.
While a stack trace can reveal where a crash occurred, it doesn’t show where the problematic input originated. By cross-referencing existing issues, I was able to refine my initial hypothesis.
Why did it happen suddenly?
The following is based on publicly available information and the time of the incident.
PowerShell update notifications appear only when a new version is available. Additionally, starting with PowerShell 7.6.1, the system is designed not to display notifications for the first 7 days following the release of a new version.
PowerShell 7.6.7 was released on October 13, 2026. It appears that the issue surfaced on October 20, 2026—seven days later—because that is when notifications for version 7.6.7 began appearing for users of version 7.6.6.
つまり、PowerShellやターミナルの設定を直前に変更していなくても、更新通知が表示される日になったことで突然起動しなくなる可能性があります。翻訳された更新通知は7.6.6から含まれるようになったと、Issueのコメントで報告されています。
Check the event log to identify where the crash occurred.
If the cause cannot be determined from the application logs alone, check the Windows Event Logs. The following command was executed from Windows PowerShell 5.1:
Get-WinEvent -FilterHashtable @{
LogName = 'Application'
StartTime = (Get-Date).AddHours(-3)
} |
Where-Object ProviderName -eq '.NET Runtime' |
Select-Object -First 1 -ExpandProperty MessageThe following information was recorded in the application log under the source “.NET Runtime” with event ID 1025
Application: pwsh.exe
CoreCLR Version: 10.0.1226.41902
.NET Version: 10.0.12
Description: The application requested process termination through System.Environment.FailFast.
Message: totalWidth ('-10') must be a non-negative value. (Parameter 'totalWidth')
at System.String.PadRight(Int32 totalWidth, Char paddingChar)
at Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification(PSHostUserInterface hostUI)
at Microsoft.PowerShell.ConsoleHost.Start(...)The points of interest are System.String.PadRight() and Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification(). This indicates that the operation to add padding to a string was triggered by the update notification process at startup, and that this operation failed.
Will updating to 7.6.7 fix it?
As of October 20, 2026, relying solely on an update to version 7.6.7 is not recommended as a workaround.
Updating to version 7.6.7 may make it appear as though the issue has been resolved, as no notification for a “newer version than 7.6.7” will be displayed at that point. However, according to the relevant issue and the fix PR #28236, the problematic calculation logic still exists in version 7.6.7.
The issue may recur in the future when a version newer than 7.6.7 is released and the update notification is triggered. Although a pull request (PR) containing a fix has been submitted, it remains open as of October 20, 2026, and no official release incorporating the fix has been confirmed.
If winget indicates that the installation format differs
In the author’s environment, the update using the following command failed.
winget upgrade --id Microsoft.PowerShell新しいバージョンが見つかりましたが、インストールテクノロジが
現在インストールされているバージョンと異なります。
パッケージをアンインストールして、新しいバージョンをインストールしてください。The existing environment used the MSI version. However, as of PowerShell 7.6.0, winget defaults to the MSIX version. While the winget manifest for version 7.6.7 includes both the MSIX and MSI versions, the default selection may not always match the currently installed format.
If you are reinstalling, perform the operation from Windows PowerShell 5.1 or the Command Prompt, rather than from pwsh. To switch to the MSIX version, follow the steps below.
winget uninstall --id Microsoft.PowerShell
winget install --id Microsoft.PowerShell --source wingetIf you wish to retain the MSI version, you can specify WiX as the installer format.
winget install --id Microsoft.PowerShell --source winget --installer-type wix
Post Comment Cancel reply