Windowsの0xc000012fでOfficeが起動しない原因と復旧手順の整理

本記事の対象となる事象は、Windows PCでExcelやWordを起動しようとした際に「AppVIsvSubsystems64.dll はWindows上では実行できないか、エラーを含んでいます」「エラー状態 0xc000012f」などのメッセージが表示され、Officeアプリが開始できなくなるケースです。表示されるDLL（動的リンクライブラリ）のパスに ...\Microsoft Office\root\Office16\... が含まれることが多く、Office側の破損とWindows側の破損のどちらでも起こり得るため、切り分け順序が判断材料として重要になります。 (Microsoft Learn)

• 0xc000012fと「Bad Image」系メッセージの意味を整理する
• Office16配下のAppVIsvSubsystems64.dllで起きる代表パターン
• Windows修復とOffice修復を「役割」で分けて進める
• 修復で解消しない場合のアンインストールと再導入の考え方
• 再発側の確認点と、安全性の整理

0xc000012fと「Bad Image」系メッセージの意味を整理する

0xc000012fは、起動対象の実行ファイルや、それが読み込むDLLが正しい形式・整合性でない場合に出やすいステータスとして扱われます。メッセージ文面としては「Windows上では実行できない」「エラーを含む」「元のインストールメディアで再インストール」などが並び、Windowsがロードしようとしたモジュールを正当なものとして扱えない状況を示します。 (Microsoft Learn)

この種の表示は、(1) アプリ側のファイル破損、(2) Windowsのコンポーネントストア（更新の土台）破損、(3) 更新途中の中断やディスク障害などで整合が崩れた、という複数経路で説明できます。したがって「Officeの修復」だけで直る場合と、先にWindows側の修復が必要な場合が分かれます。 (マイクロソフトサポート)

また、本記事の対象テーマでは AppVIsvSubsystems64.dll（または32-bit版の AppVIsvSubsystems32.dll）が名指しされます。Office関連の導入形態（Click-to-Runなど）では、Office配下や共有コンポーネント配下にこのDLLが配置され、欠損・破損時に起動に影響し得る、という整理になります。 (マイクロソフトサポート)

以上を踏まえると、復旧は「Windowsの整合性の回復」と「Officeの整合性の回復」を順に確認する流れが、原因の分岐を吸収しやすい構造です。次章では、Office16配下で発生するパターンを具体化します。

Office16配下のAppVIsvSubsystems64.dllで起きる代表パターン

本記事が示す状況で多いのは、ExcelやWordなど複数のOfficeアプリが同時に起動不能になる形です。単一アプリ固有の故障よりも、共通部品（共有DLL）が読み込めない状態の方が説明しやすいためです。Microsoft Q&Aでも、...\Office16\AppVIsvSubsystems64.dll（または32.dll）を指して同様の文面が表示された報告が継続的に見られます。 (Microsoft Learn)

このとき、切り分けで重要になるのは「対象DLLの場所がWindows\System32などOS中核か」「Officeのインストール配下か」です。OS中核のDLLであればWindows修復が主経路になりやすく、Office配下であればOffice修復・再構成が主経路になりやすい、という傾向があります。ただし、Office配下のDLL破損がWindows更新失敗の影響で起きることもあるため、片側だけで断定しない整理が必要です。 (マイクロソフトサポート)

もう一点、運用上の確認点として「外部サイトから単体DLLを取得して差し替える」手段が挙がりやすい一方、ソフトウェア供給元の手順としてはOfficeの修復やアンインストール支援ツールが先に置かれています。少なくともMicrosoftの公開手順は、Officeを“修復プロセス”で整合状態へ戻すことを基本線にしています。 (マイクロソフトサポート)

そうすることによって、ファイル単体の正しさだけでなく、関連コンポーネントや登録情報も含めた整合を回復する設計になりやすいためです。次章では、Windows側とOffice側の修復を、役割の違いで整理します。

Windows修復とOffice修復を「役割」で分けて進める

0xc000012fがOffice配下で見えていても、先にWindowsの整合性（SFC/DISM）を確認する順序が実務上の確認点となります。 (マイクロソフトサポート)

Windows側の代表手段はSFC（System File Checker）とDISMです。SFCは保護されたシステムファイルを検証し、破損があればキャッシュやインストールソースから正しい版を戻す仕組みとして説明されています。DISMはWindowsイメージ（コンポーネントストア）側の破損を検出・修復し、Windows Update等をソースとして利用し得ます。 (マイクロソフトサポート)

一方でOffice側の代表手段は「修復（クイック修復／オンライン修復）」です。Microsoftの案内では、クイック修復は比較的短時間で破損ファイルを検出・置換し、オンライン修復はより広い範囲を対象にして“すべてが修復されるよう”に進む位置づけが示されています。 (マイクロソフトサポート)

要点を整理すると、同じ「修復」でも狙う範囲が異なります。区別が分かりやすいよう、代表的な差分を表にまとめます。

つまり、Windows側で整合が崩れている場合はOffice修復だけでは戻り切らない可能性があり、他方でWindowsが健全でもOffice側の共有部品が欠損しているならOffice修復が中心になります。なお、いずれの手順でも再起動が関連する場面があり得る点は、手順書上で明示されています（例：修復後に再起動が必要となる場合）。 (マイクロソフトサポート)

この結果、SFC/DISM→Office修復の順で整理すると、原因の枝分かれを吸収しやすくなります。次章では、修復で戻らない場合の「完全削除と再導入」を扱います。

修復で解消しない場合のアンインストールと再導入の考え方

修復で改善しないケースでは、Officeのインストール状態そのものが破損している、または修復プロセスが走らない・完了しない、といった分岐が残ります。この場合、Microsoftはコントロールパネルからのアンインストールに加えて「アンインストール サポート ツール（トラブルシューティング）」を用いた完全削除の手順を案内しています。 (マイクロソフトサポート)

アンインストール サポート ツールは、通常の削除で残りやすい構成要素を含めて処理するための選択肢として位置づけられています。サポート文書上でも、ボタン操作でトラブルシューティングを開始し、画面の指示に従って進める流れが提示されています（Windows 10以上などの前提条件も記載）。 (マイクロソフトサポート)

Microsoft 365環境や企業端末では、Support and Recovery Assistant（SaRA、サポートおよび回復アシスタント）の「Officeアンインストール」シナリオを運用で使う場面もあります。これは管理・診断用途のツールとして、条件検出と実行結果の扱いが文書化されています。 (Microsoft Learn)

言い換えると、修復→削除→再導入は“手段の強さ”が段階化されています。ここまでで復旧経路は出揃うため、最後に再発側の確認点（更新・安全性）を整理します。

再発側の確認点と、安全性の整理

本記事で整理する論点の一つは、発生契機が特定できないことがある点です。Microsoft Q&Aでも、直前に特別な操作がない状況でOfficeが起動不能になった例が報告されています。一方で、Windows Updateの中断や更新基盤の破損が「特定アプリではなく複数アプリの起動」に影響する形は、SFC/DISMの役割説明からも構造として整合します。 (Microsoft Learn)

また、AppVIsvSubsystems64.dll のように「実在のDLL名」が示されると、外部サイトから当該DLLを入手して差し替える手段が検討されがちです。ただし供給元の基本線は、Office修復・アンインストール支援ツール・Windows整合性修復であり、単体DLL差し替えは手順の中心に置かれていません。加えて、DLLは実行時に読み込まれるため、入手経路の信頼性はセキュリティ上の確認点になります（誤ったファイルは症状を維持させるだけでなく、別の不具合要因にもなり得ます）。 (マイクロソフトサポート)

更新の観点では、Windows Updateが健全に完了しているか、更新履歴に失敗が残っていないか、という整理が先に来ます。Learnの回答でも、更新状態の確認→一時ファイル整理→Officeオンライン修復という順序が提案されており、更新と修復を連動させて扱う発想が読み取れます。 (Microsoft Learn)

以上を踏まえると、再発予防は「更新を途中で止めない」「失敗更新の解消」「Windows整合性（SFC/DISM）とOffice整合性（修復）の二層で点検する」に整理されます。なお、同一症状でも原因が単一に定まらない場合があるため、どの層で整合が崩れていたかをログや実行結果で把握しておくことが、次回の判断材料として重要である、という位置づけになります。最後の文だけ微妙に誤字がありまｓ。