技術資料

2026年10月20日、普段使っているPowerShell 7.6.6が、起動直後にエラーを出して終了するようになりました。コマンドを入力するところまで進めません。

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

今回は、更新通知を無効にすることで起動できるようになりました。同じエラーに遭遇した方向けに、復旧手順と原因をまとめます。対象はWindows上のPowerShell 7.6.6で、修正状況は2026年10月21日時点の情報です。

コマンドプロンプトから更新通知を無効にする

PowerShellは、環境変数POWERSHELL_UPDATECHECKで更新通知を制御できます。これを起動前にOffにすると、今回エラーになっている通知処理を回避できます。

PowerShell自体が起動できないので、Windowsのスタートメニューで「コマンドプロンプト」を検索するか、Win + Rでcmd.exeを実行して、コマンドプロンプトを開きます。

そこで、次のコマンドを実行します。

setx POWERSHELL_UPDATECHECK Off

このコマンドは、現在のユーザーの環境変数として設定を保存します。管理者権限での実行や、システム全体へ設定する/mの指定は不要です。

続いて、Windows Terminalを使っている場合は、作業中の内容を保存し、開いているWindows Terminalのウィンドウをすべて閉じてから、起動し直します。今回の環境では、この操作でPowerShell 7.6.6が正常に起動するようになりました。

setxの設定は、既に動いているプロセスには反映されません。タブを開き直すだけでは、Terminalが持っている古い環境変数を引き継ぐ場合があります。エラー画面でEnterを押してシェルを再起動するだけでなく、Terminalごと起動し直す点に注意してください。仕様はMicrosoftのsetxコマンドの説明で確認できます。

この設定で無効になるのはPowerShellの更新通知です。コマンドやスクリプトの実行機能を無効にするものではありません。ただし、新バージョンの通知も表示されなくなるので、回避策を使っている間は公式のリリース情報を確認しておきましょう。

原因は更新通知メッセージの余白計算

エラーログには、次の呼び出しが含まれていました。スタックトレースの一部を抜粋しています。

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)

UpdatesNotification.ShowUpdateNotificationという名前からも分かるように、更新通知を表示する処理でエラーになっています。

PowerShell公式リポジトリのIssue #28131には、複数の言語環境で同様の起動失敗が報告されています。日本語環境のPowerShell 7.6.6で、同じtotalWidth ('-10')が出たという報告もあります。

修正PR #28236の説明によると、通知メッセージの整形処理は「1行目が最も長い」という前提で、後の行へ付ける余白を計算していました。ところが、翻訳されたメッセージでは後の行のほうが長くなることがあり、計算結果が負になります。

文字列の右側を埋めるString.PadRight()には、負の長さを渡せません。そのため例外が発生し、プロンプトが表示される前にPowerShellが終了してしまいます。

なぜ突然起きるようになったのか

更新通知は、新しいバージョンが公開されると即座に表示されるわけではありません。Microsoftの更新通知の説明では、新バージョンの公開から7日を超えて経過したものを通知するとされています。

PowerShell 7.6.7のリリース情報では、公開日は10月13日（UTC）です。Issueでも、10月20日に報告が増えた理由として、この通知の待機期間との関係が説明されています。

今回も、以前から潜んでいた不具合が、新バージョンの通知開始によって表に出たと考えられます。更新確認のタイミングやキャッシュも関係するため、すべての環境で同じ日時に発生するというわけではなさそうです。

7.6.7に更新できても、根本修正とは限らない

Issueには、7.6.7への更新後に起動できたという報告もあります。ただし、2026年10月21日時点では、修正PR #28236は未マージで、PRの説明では7.6.7にも問題の計算が残っているとされています。

新しいバージョンへ更新すると、そのバージョンを勧める通知は表示されなくなります。その状態で起動できても、通知の整形処理が直った証拠にはなりません。私は7.6.7での再現試験はしていないため、ここは公開された解析に基づく注意点です。

一方、7.6.7にはセキュリティ修正があります。MicrosoftのCVE-2026-96303のアドバイザリでは、7.6系の修正版が7.6.7とされています。今回の起動障害が未修正だからといって更新を見送るのではなく、セキュリティ更新の適用と、更新通知の回避を分けて考える必要があります。

補足：-NoLogoで起動する方法も報告されている

Issueには、コマンドプロンプトから次のように起動できたという報告もあります。

pwsh -NoLogo

こちらは私の環境では未検証です。今回、実際に復旧できたのは、環境変数をOffにしてターミナルを起動し直す方法でした。

修正版を確認したら更新通知を戻す

更新通知の無効化は、不具合を修正する操作ではありません。修正PRのマージだけでなく、利用する安定版への修正の収録を公式リリース情報で確認し、その版を導入してから通知を戻しましょう。

通常の通知動作へ戻す場合は、コマンドプロンプトで次を実行します。

setx POWERSHELL_UPDATECHECK Default

その後、無効にしたときと同様に、Windows Terminalなどの起動元のアプリを終了し、起動し直します。Defaultは、この環境変数を未設定にした場合と同じ通知動作です。変数自体を削除するコマンドではありません。また、以前からLTSなどを意図して設定していた場合は、元の値へ戻してください。

LTSは通知対象をLTS版に絞る設定なので、通知そのものを無効にするOffの代わりにはなりません。修正PRでも、LTS用メッセージで同様の問題が起こる言語があると説明されています。

今回のように起動直後に終了する場合でも、エラーに含まれる処理名が原因を絞る手掛かりになります。同じ更新通知のエラーなら、まず別のシェルから通知を無効にし、復旧後に更新と修正状況を確認するとよいかと思います。