Windows 10でMicrosoft Visual C++ 2022がインストールできずNVIDIAアプリが起動しない時の直し方｜0x80070001の原因と対処完全ガイド

Windows 10 Pro 22H2 で NVIDIA アプリ（NVIDIA App/旧 GeForce Experience）が更新後に起動しない。信頼性モニターには「Microsoft Visual C++ 2022 X86 Minimum Runtime – 14.42.34438 のインストール失敗」「0x80070001 (Incorrect function)」などが並ぶ──この記事は、このよくある詰まりを最短で復旧するための実務的な手順と、再発を防ぐ運用のコツをまとめた完全版ガイドです。

症状の概要と前提環境

以下のような組み合わせで不具合が表面化します。

• OS：Windows 10 Pro 22H2（x64）
• アプリ：NVIDIA アプリ（NVIDIA App／旧 GeForce Experience を置き換える新 UI を含むことも）
• 表示されるエラー：「Microsoft Visual C++ 2022 X86 Minimum Runtime – 14.42.34438 のインストール失敗」
• 信頼性モニター/イベントログ：Visual C++ 再頒布可能パッケージの失敗、インストーラーの終了コード 0x80070001（Incorrect function）
• GPO：
  ・「自動更新は通知のみ」
  ・「対象の機能更新プログラムのバージョン＝22H2 に固定」
  ──の設定が入っていても、通常は本件の直接原因ではありません。

現象	確認ポイント	よくある原因の目安
NVIDIA アプリが起動しない／更新で止まる	VC++ 2022 x86 の導入履歴／信頼性モニター	VC++ ランタイムの破損／欠落、x86 未導入
VC++ セットアップが途中でロールバック	%TEMP% の dd_vcredist_*.log	古い残骸、ロック中の DLL、再起動保留
0x80070001（Incorrect function）	デバイスがビジー／ファイル操作失敗箇所	ウイルス対策の干渉、権限/ポリシー、I/O 異常

なぜ Visual C++ 2022 Runtime が鍵になるのか

NVIDIA アプリや付随するサービスは、C++ で実装されたモジュールに依存します。これらは OS 標準ではないランタイム（例：vcruntime140.dll、msvcp140.dll、vcruntime140_1.dll ほか）を必要とし、アプリ本体とは別に「Microsoft Visual C++ 再頒布可能パッケージ（Redistributable）」として提供されます。

重要なのは、2015 以降の VC++ は「14.x 系」で共通化されており、最新の 2022 再頒布パッケージを入れると 2015/2017/2019 も包括的に満たす点です。また、x64 Windows でも x86 ランタイムは別物で、NVIDIA アプリの一部は x86 ランタイムに依存します。よって x64 と x86 を両方入れることが実務上の正解です。

主な原因と技術的背景

• ランタイムの破損／欠落：過去の不完全なアップデートや急な電源断で、レジストリやファイルが不整合になると、最低限（Minimum）の構成ですら検証に落ちます。
• 旧版の残骸やロック：古いドライバーや関連アプリが DLL をロックしたまま、上書きに失敗してロールバック。0x80070666（別のバージョンが既に存在）などに派生することも。
• セキュリティソフトの介入：自己解凍 EXE の展開や一時フォルダへの書き込みを監視・遮断し、結果として 0x80070001 へ。
• 再起動保留／保留中のトランザクション：Windows Installer の保留処理が残っていると、後続セットアップが弾かれます。
• ポリシーの誤解：Windows Update の GPO は更新の配信/再起動タイミングに影響しますが、VC++ のスタンドアロン EXE/MSI を直接ブロックすることは通常ありません。ブロックするのは AppLocker/WDAC/Software Restriction Policy（SRP）等の実行制御系です。

原因	ログ/痕跡	対処
ランタイム破損	修復で「ファイル復元」イベント、dd_vcredist_*.log に検出	全 VC++ の Repair → 最新パッケージで上書き
ロック/使用中	セットアップが「使用中のファイル」警告／再起動要求	再起動 → 常駐停止 → セーフモードで再実行
セキュリティ介入	リアルタイム保護ログ、隔離履歴	一時的に無効化し、インストール後に再有効化
旧版の残骸	「別バージョンが既に存在」0x80070666	Repair または古い構成の削除 → 再導入
GPO/実行制御	AppLocker/WDAC のイベントログ	例外ルール追加または一時無効化

最短で復旧する「基本フロー」

1. 既存の Visual C++ を一括修復（x86/x64 すべて）
2. 最新の VC++ 2022 再頒布パッケージを x86→x64 の順で導入（インストール or 修復）
3. NVIDIA ドライバー/アプリをクリーン再インストール（NVIDIA Cleanup Tool または DDU の利用）
4. なおらない場合：SFC/DISM で OS を整備 → セキュリティソフト一時停止 → ログ解析

具体的な操作手順

既存の Visual C++ を修復する

1. Win + R → appwiz.cpl と入力し「プログラムと機能」を開く。
2. 一覧から「Microsoft Visual C++ ××× Redistributable」（x86/x64 の全バージョン）を順に選択 → 変更 → 修復 (Repair) を実行。
3. 一巡したら 再起動。

最新の VC++ 再頒布パッケージを手動導入

公式の「最新サポート Visual C++ 再頒布可能パッケージ」から以下を入手し、管理者として実行します（リンクは掲載しません）。

• vc_redist.x86.exe（x86）
• vc_redist.x64.exe（x64）

ポイント：

• 必ず両方導入（x86 → x64 の順がおすすめ）。
• 「既にインストールされています」と出たら修復（Repair）を選ぶ。
• サイレント導入の例（管理者の PowerShell/コマンド）

vc_redist.x86.exe /install /quiet /norestart /log C:\Temp\vc2022_x86.log
vc_redist.x64.exe /install /quiet /norestart /log C:\Temp\vc2022_x64.log
  

GPU ドライバー/関連アプリのクリーン再インストール

NVIDIA Cleanup Tool（NVIDIA 提供）で既存ドライバーを除去するか、上級者は DDU（サードパーティ製・自己責任）をセーフモードで実行します。完了後、最新ドライバーと NVIDIA アプリを導入し、インストール時は「クリーンインストール」を選びます。

注意：DDU は強力です。復元ポイントの作成と再起動計画を用意のうえ、手順に従ってください。企業環境ではまずクリーンアップツールの利用を推奨します。

それでも失敗する場合の追加チェック

• システムファイルを修復

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
  

• ウイルス対策/EDR を一時的に無効化（オフラインで作業後、必ず再有効化）。
• セットアップログを確認：%TEMP% や指定した /log のパスに dd_vcredist_*.log が生成されます。
• ロックされたファイルの手動削除：ログに具体名が出る場合は、セーフモードで当該 DLL/フォルダを削除してから再導入。

エラーコードとログの読み方

代表的な終了コード・メッセージと対処の早見表です。

コード/メッセージ	意味	対処
0x80070001（Incorrect function）	ファイル操作/関数呼び出しが失敗。I/O、権限、介入など広範	再起動保留の解消、セキュリティ停止、セーフモードで再実行、イベントログ確認
0x80070666（Another version is already installed）	別バージョンが既に存在	Repair 実行、古い構成の削除後に最新で上書き
0x80070652（Another installation is in progress）	他のインストールが進行中	再起動→他のセットアップを完了/停止→再試行
0x80070005（Access denied）	権限不足/実行制御	管理者として実行、AppLocker/WDAC/SRP の例外設定

ログ（dd_vcredist_*.log）で注目する行：

• Return code：最終的な終了コード。
• Blocking application：ロック中のプロセス名。
• Package action：Install/Repair/Uninstall のどこで失敗したか。

[...]
Error 0x80070001: Incorrect function while copying file ...
Blocking application: nvcontainer.exe
[...]
  

この例では nvcontainer.exe がランタイム DLL を占有しているため、NVIDIA 関連サービス停止またはセーフモードでの導入が効果的です。

グループポリシーは影響するのか？（結論：ほぼ無関係）

質問にある GPO（自動更新の通知のみ／機能更新 22H2 固定）は、Windows Update の配信・再起動制御に関与しますが、VC++ のスタンドアロンインストーラー（EXE/MSI）の実行をブロックしません。ブロックが起こり得るのは以下です。

• AppLocker/WDAC/SRP：実行ファイルのホワイトリスト制御。イベントビューアの「アプリケーションとサービス ログ」で該当ログを確認。
• ストレージ制御/USB 制限：一時フォルダや展開先への書き込み制御。

よって本件の主戦場は「ランタイムの整合性確保」と「ドライバーのクリーン導入」であり、GPO 側の調整は通常不要です。

インストールがうまくいく実践テクニック

• 順番：x86 → x64 の順で導入すると、依存検証がスムーズ。
• 再起動：導入・修復後は都度再起動。保留状態を残さない。
• 常駐停止：NVIDIA 関連サービス（NVIDIA Display Container LS など）とウイルス対策を一時停止。
• セーフモード：どうしても DLL が解放されない場合は、ネットワークなしのセーフモードで VC++ → ドライバーの順に。
• 署名確認：vc_redist.*.exe のプロパティで署名者が「Microsoft Corporation」であることを確認。

企業・組織向け：配布と検出の実装例

レジストリでの検出（14.x 系）

以下のキーに Version（例：14.42.34438.0 など）が入ります。

HKLM\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x86
HKLM\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x64
  

PowerShell での存在確認スクリプト

$keys = @(
 'HKLM:\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x86',
 'HKLM:\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x64'
)
foreach($k in $keys){
  if(Test-Path $k){
    $p = Get-ItemProperty $k
    "{0}: {1} (Installed={2})" -f $k, $p.Version, $p.Installed
  } else {
    "{0}: NotFound" -f $k
  }
}
  

サイレント配布（例）

配布製品（Intune/SCCM/その他）から以下のコマンドを実行します。

vc_redist.x86.exe /install /quiet /norestart
vc_redist.x64.exe /install /quiet /norestart
  

winget を使う場合（管理者 PowerShell）

winget install --id Microsoft.VCRedist.2015+.x86 --silent --accept-source-agreements --accept-package-agreements
winget install --id Microsoft.VCRedist.2015+.x64 --silent --accept-source-agreements --accept-package-agreements
  

オフライン環境では、予め vc_redist の EXE を配布点に保管して実行します（再配布パッケージ自体はオフラインで動作します）。

ファイル/サービスの観点での自己診断

チェック項目	確認方法	OK の目安
主要 DLL の存在	C:\Windows\System32\vcruntime140.dll C:\Windows\SysWOW64\vcruntime140.dll	両フォルダに存在し、バージョンが 14.42.x など最新
NVIDIA サービス	サービス管理（services.msc）で状態確認	導入後に自動で開始、エラーなし
再起動保留	レジストリの RebootRequired を確認、または単純に再起動	保留なし（再起動直後）

よくある質問（FAQ）

x64 だけ入れていれば十分では？

いいえ。x86 と x64 は別です。x64 環境でも 32bit コンポーネントが存在するため、x86 ランタイムは必須です。

古い VC++（2005〜2010 など）は削除すべき？

削除不要です。レガシーアプリが依存する場合があるため、残して問題ありません。

0x80070001 の直接原因は？

「関数が誤っています」という汎用エラーです。実体は I/O エラー、ドライバー/サービスが DLL を握っている、セキュリティ製品が展開を阻害する、など。まずは再起動→常駐停止→セーフモード→ログ確認の順で切り分けます。

グループポリシーでも止まるのでは？

Windows Update の遅延/固定は関係しません。実行制御（AppLocker/WDAC/SRP）が設定されている場合のみ、例外ルールが必要です。

NVIDIA Cleanup Tool と DDU の違いは？

Cleanup Tool はベンダー提供の安全寄りのクリーンアップ。DDU はより徹底的ですがサードパーティ製で、運用ルールに従い自己責任で。

トラブル発生時の判断フロー（保存版）

1. 「プログラムと機能」で全 VC++ を Repair → 再起動。
2. vc_redist.x86 → vc_redist.x64 をインストール/修復（必要なら /log 付与）。
3. NVIDIA Cleanup Toolでドライバーを消去 → 最新版をクリーンインストール。
4. 改善なし：SFC / DISM → セキュリティ製品を一時停止 → セーフモードで再実行。
5. ログでロック/拒否を特定 → 該当プロセス停止/例外設定/手動削除。
6. 組織環境：AppLocker/WDAC の例外、配布スクリプトで x86/x64 両方の担保。

再発防止の運用ポイント

• 1〜2 カ月に一度、最新 VC++ 2022 再頒布パッケージで上書き導入（Repair 相当）。
• GPU ドライバー更新時はクリーンインストールを選択し、旧構成を残さない。
• 導入ジョブは再起動込みで計画、ログを中央収集して失敗傾向を早期検出。
• セキュリティ製品には一時除外ルールを準備（%TEMP%、インストーラーのパスなど）。
• 復元ポイント/バックアップの定期作成（特に DDU 等の強力ツール使用前）。

ケーススタディ：現場で本当に起きた詰まり

ケース A：x86 未導入で NVIDIA アプリが即終了

x64 のみ導入済み。x86 を追加しただけで起動安定。ログには「x86 Minimum Runtime が満たされない」旨の検証失敗が明記。

ケース B：0x80070001 と 0x80070666 が交互に発生

旧版の残骸があり、Repair が成功しない。セーフモードで %ProgramFiles%\Microsoft Visual C++ Redistributable 配下を整理後、vc_redist.*.exe /repair で回復。

ケース C：EDR が自己解凍をブロック

ログに「書き込み失敗」。EDR の一時停止と信頼済みパスの除外で通過。作業後に必ず再有効化。

レジストリとファイルの参考（読み取り専用で）

環境調査のための参照先（編集は慎重に）。

対象	場所	用途
VC ランタイム版数	HKLM\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\{x86|x64}	導入/バージョン/インストール済みフラグ
主要 DLL	C:\Windows\System32 / SysWOW64	タイムスタンプ/バージョンの突合
VC セットアップログ	%TEMP%\dd_vcredist_*.log	失敗箇所の特定

注意：レジストリやシステムフォルダの削除/変更は最終手段です。バックアップや復元ポイントを用意し、不明点は編集せずログで原因を特定しましょう。

まとめ

• NVIDIA アプリの起動不全は、VC++ 2022（14.x）ランタイムの不整合が主因になりがち。
• x86 と x64 を両方インストール/修復し、ドライバーはクリーン導入が基本。
• 0x80070001 は汎用エラー。再起動→常駐停止→セーフモード→ログ解析で切り分ける。
• Windows Update の GPO は直接の原因ではない。実行制御（AppLocker/WDAC）だけ注意。
• 運用では定期的な上書き導入とログの中央管理で再発を予防。

上記の手順と運用を押さえれば、同様のトラブルが起きても短時間で復旧できます。まずは Repair と最新パッケージの x86→x64 導入、その後のクリーンなドライバー再構築という王道フローを実践してみてください。