WSLで0x8007019eが出るときにオプション機能を復旧する
この記事の結論
Linuxディストリビューション起動時にWSLオプションコンポーネント未有効のエラーになる場合の安全な切り分け手順。Windows Subsystem for Linux機能が無効、または機能有効化後の再起動が済んでいない。設定変更前に現在値を控え、公式機能だけを使って確認する。
一般的な切り分けガイドです。特定の不具合が現在発生しているという告知ではありません。
対象製品・影響範囲
- 製品
- Windows Subsystem for Linux
- 対象バージョン・条件
- Windows 11（対応機能はエディションとハードウェア要件を確認）
- 関連するエラーコード・識別子
- 0x8007019e
発生する症状
- Linuxディストリビューション起動時にWSLオプションコンポーネント未有効のエラーになる
- 再起動や再試行だけでは同じ状態が続くことがある
原因・発生条件
Windows Subsystem for Linux機能が無効、または機能有効化後の再起動が済んでいない。
作業前の準備
- 開いている文書と作業を保存し、必要ならPCを再起動できる時間を確保する
- 管理者権限が必要な操作は、個人所有PCまたは管理者の許可を得た端末だけで行う
- 診断用コマンド「Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux」の結果を保存し、変更前後を比較できるようにする
この操作の注意点
- レジストリ、システムフォルダー、資格情報、記憶域を手作業で一括削除しない
- インターネット上の非公式スクリプトや不明なドライバーを管理者権限で実行しない
使用するツール・公式ページ
この手順の公式要件、画面名、制限事項を確認する。
具体的な操作手順
起動に失敗したLinuxディストリビューション名と0x8007019eの全文を控えます。［設定］のアプリ画面でディストリビューションをリセットするとLinuxのデータを失うため、まずWindows側の機能を確認します。
まずエラー全文を見て、0x8007019eがどの操作で出るかを固定します。ディストリビューションの初回起動、既存環境の起動、インストールアプリの実行では調査対象が異なります。「前に使えた」という場合は、その時と現在のWindowsユーザー、起動方法、更新後の再起動の有無を比較します。管理者として実行しただけなら通常ユーザーと同じ場合もありますが、別の管理者アカウントで実行しているなら登録一覧が異なります。アカウント名を確認してから、どの環境の一覧を見ているかを記録します。
0x8007019eはWSLオプションコンポーネントを確認する入口です。「インストール済みディストリビューションがありません」という別の表示なら、まず同じWindowsユーザーで実行しているかを確認します。別ユーザーの登録状態を直すために現在のLinux環境を削除しません。
StateがEnabledか確認し、Disabledなら管理者権限で有効にする。
出力の State が Enabled なら有効、Disabled なら無効です。Enable Pendingや再起動要求がある場合は作業を保存してWindowsを再起動し、同じ確認コマンドを再実行します。
Get-WindowsOptionalFeature は管理者PowerShellで実行します。StateがDisabledなら次の有効化へ進み、Enabledなら0x8007019eをコンポーネント無効だけと決めず、wsl --statusと再起動待ちを確認します。
Get-WindowsOptionalFeatureの結果は機能名とStateをセットで読みます。DisabledならWSLコンポーネントの有効化へ進み、Enabledならその機能を再追加することだけに時間を使いません。再起動が保留されている場合は、開いている作業を保存し、Windowsの再起動を完了させてから再確認します。コマンド自体がアクセス拒否になる場合は、必要な管理者権限と組織の設定変更権限を確認します。権限不足と機能不足を混同すると、通常ユーザーで同じ操作を繰り返しても状況が変わりません。
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-LinuxWSL機能を有効化し、保留中の作業を保存してWindowsを再起動する。
コマンド終了時に「操作は正常に完了しました」、再起動要求、またはエラーコードのいずれかを確認します。失敗した場合は同じ操作を繰り返さず、表示コードと C:\Windows\Logs\DISM\dism.log を保存します。
有効化コマンドの正常終了後は、同じユーザーで一覧を取得し、最初に失敗した対象を起動します。一覧に対象がない場合はアプリの初回起動やユーザーを確認する別の分岐になります。対象があるのに起動エラーが変わった場合は、その新しいコードを控えます。WSL 2の仮想化要件に進む場合でも、今回のコンポーネント有効化が成功したかどうかと区別してください。ネット上にある複数の修復コマンドを続けて実行すると、どの変更が必要だったか判断できなくなり、戻すべき設定も増えます。
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestartこの手順で使う公式リンク
- Troubleshooting Windows Subsystem for Linux
この手順の公式要件、画面名、制限事項を確認する。
- Troubleshooting Windows Subsystem for Linux
［スタート］>［電源］>［再起動］でWindowsを再起動し、管理者PowerShellで手順2のコマンドを再実行します。StateがEnabledになったことを確認してから、同じディストリビューションを起動します。
機能有効化が成功して再起動を求められたら、作業を保存して再起動します。その後に同じユーザーで対象アプリを一度開きます。機能の追加自体が失敗した場合はDISMのエラーとして扱い、ディストリビューションの再インストールを先に行いません。
「wsl --list --verbose」で状態を確認し、最初に記録した操作を同じ条件で一度実行する。成功した場合も再起動後にもう一度確認し、変更した設定と結果を記録する。
対象ディストリビューション、WSL版、既定バージョンが表示されるか確認します。コマンドが認識されない場合はディストリビューションをリセットせず、WSL機能とStore版WSLの導入状態を確認します。
復旧が止まったときは、有効化前後のState、Windowsビルド、コマンドの終了表示、再起動の実施有無、対象ディストリビューションの一覧を保存します。利用者名や会社情報が出力に入っている場合は、共有する相手に必要な部分だけを残します。DISMが失敗した場合はWSL内のファイルを消さず、Windows側の機能処理のログを調べます。対象アプリのアンインストールや登録解除は最初の診断手順にはしません。設定を戻す必要がある場合も、変更した機能と依存する作業がないかを管理者と確認してから行います。
wsl --list --verbose
改善したか確認する
- 同じWindowsユーザーでディストリビューション一覧と起動結果を確認できる
- 確認コマンドの出力が期待する有効・正常・接続済み状態を示す
- Windows再起動後にも同じ操作を再現でき、イベントログに同時刻の新しい重大エラーが増えない
改善しない場合・設定を戻す場合
- 有効化失敗ならDISMログと再起動の実施有無を記録する
- ハードウェア要件、組織ポリシー、サーバー側設定が原因なら、クライアント側で回避せず所有者に変更を依頼する
このガイドの適用範囲
対処ガイド — 原因を切り分け、対象機能が正常に起動または接続でき、再起動後も同じ検証を通る状態を目標にする。
掲載内容は2026-10-13の情報確認に基づきます。以降の変更は公式出典でご確認ください。
よくある質問
機能を有効化してもすぐ反映されません。
オプション機能の変更は再起動待ちになることがあります。作業を保存してWindowsを再起動し、Stateと `wsl --list --verbose` を再確認します。
ディストリビューションを削除する必要がありますか？
通常は不要です。登録解除はLinux側データを失うため、機能有効化と再起動を先に試します。
Enabledなのに一覧が空なら機能を無効化してやり直しますか？
先にWindowsユーザーと対象アプリの初回起動を確認します。機能の状態とユーザーごとのディストリビューション登録は別です。既存データを残す必要があるなら削除やリセットを行わず、どのアカウントに環境があるかを調べます。
出典・情報の更新
- 主な出典の更新・解決日
- 公式ページで日付を特定できないため記載していません
- 本サイトの確認日
- 2026-10-13
公式情報を日本語で整理しています。メニュー名は製品の表示言語や版によって異なる場合があります。確認日は障害の発生日を意味しません。編集方針