【PCゲーマー必見】そのまま使うとPCパフォーマンス低下、勝手に変更された設定を元に戻す「AppX Deployment Service (AppXSVC)」

2026年01/18日追記↓（本来の記事はだいぶ下にあります）

ちゃんと説明しておいた方が良いかなと思い追記です。

追記していますが、原則自己責任には変わりありません。

Windows 11（KB5072033適用後）においてスタートアップ設定が「自動」へ変更された AppXSVC について、その内部ロジックを解析し、最適化（Start=3 手動化）の妥当性と安全性を技術的に証明しにいくものである。

• ファイル名: AppXDeploymentServer.dll

• サービス名: AppXSVC (AppX Deployment Service)

• 実行階層: ユーザーモード (svchost.exe 経由)

デコンパイル結果より、主要な関数を本来の C++ 構造に再構築してわかりやすく。

A. サービスエントリーポイント (ServiceMain)

サービスの起動と初期化を司る中心的なロジックです。

void WINAPI ServiceMain(DWORD dwArgc, LPTSTR* lpszArgv) {
    // サービスのコントロールハンドラーを登録
    g_StatusHandle = RegisterServiceCtrlHandlerExW(L"appxsvc", ServiceHandler, NULL);
    if (g_StatusHandle == NULL) {
        // エラー時はログを記録して安全に終了 (Fallback)
        ReportServiceError(GetLastError());
        return; 
    }

    // ステータスを「開始中」に設定
    UpdateServiceStatus(SERVICE_START_PENDING);

    // ユーザーモードの基盤である COM の初期化
    HRESULT hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);
    if (FAILED(hr)) {
        // COM初期化失敗時も、システムを止めず終了処理へ
        goto CLEANUP;
    }

    // 内部コンポーネントの初期化
    if (SUCCEEDED(InitializeComponents())) {
        // ステータスを「実行中」に設定
        UpdateServiceStatus(SERVICE_RUNNING);
        
        // バックグラウンドメンテナンス（重いスキャンのトリガー）
        if (IsMaintenanceRequired()) {
            ExecuteHeavyMaintenanceTasks(); // DB整合性チェック等
        }
    }

CLEANUP:
    if (comInitialized) CoUninitialize();
    UpdateServiceStatus(SERVICE_STOPPED);
    return; // 関数の正常終了
}

B. リソース優先度監視ロジック (FUN_18017816c)

サービスが自らの処理優先度をチェックし、不足している場合に警告を出す箇所です。

void CheckResourcePriority(longlong context, int cpuPri, int ioPri) {
    // 内部的な「足切り」ラインの判定
    // CPU優先度 7以上、I/O優先度 1以上が期待されている
    if (cpuPri > 7 && ioPri > 1) {
        return; // 十分なリソースがあれば正常終了
    }

    // リソース不足（Inadequate）と判定された場合
    // エラーコード 0x8007139f を吐くが、システムは停止させない
    LogDiagnosticMessage(
        "StateRepository.ResourcePriority.Inadequate",
        "CpuPriority", cpuPri,
        "IoPriority", ioPri,
        0x8007139f // ERROR_INVALID_STATE
    );
    
    return; // ログ記録後、安全に処理を継続
}

C. OS状態分離の判定ロジック (FUN_18002e880)

起動時に ntdll.dll を参照して OS の動作モードを確認する箇所です。

BOOL IsStateSeparationEnabled() {
    HMODULE hNtdll = LoadLibraryExW(L"ntdll.dll", NULL, LOAD_LIBRARY_SEARCH_SYSTEM32);
    if (hNtdll) {
        auto pRtlIsStateSeparationEnabled = 
            (pRtlIsStateSeparationEnabled_t)GetProcAddress(hNtdll, "RtlIsStateSeparationEnabled");

        if (pRtlIsStateSeparationEnabled) {
            // OSのAPIを呼び出してモード判定
            return pRtlIsStateSeparationEnabled(); 
        }
        FreeLibrary(hNtdll);
    }
    // DLLロード失敗時や関数不在時は FALSE を返して続行 (Fallback)
    return FALSE; 
}

安全性に関する技術的証明

① 物理的破壊（BSOD）の不可能性

解析の結果、インポート・シンボル・テーブルに NtRaiseHardError（ユーザーモードからの強制BSOD）や KeBugCheck（カーネル停止）といったAPIが一切存在しないことを確認。このDLLのコードがどのような論理エラーを起こしたとしても、OSカーネルを停止させる手段を持っていないことが技術的に確定。

② 起動不可（ブート失敗）のリスク排除

ServiceMain 解析から明らかな通り、本サービスはブート必須のドライバ（Storage/Network等）ではなく、CoInitializeEx に依存するアプリケーション層のサービスです。OSのブートプロセスにおけるクリティカルな依存関係に含まれておらず、ErrorControl 設定も「Normal (1)」であるため、本サービスが起動しないことでブートが停止することはまずありません。

③ フォールバック設計による安定性

各関数において、外部DLL（ntdll.dll等）のロード失敗や関数の取得失敗を想定した if 分岐と、失敗時に return 0 や FALSE を返して「何事もなかったかのように」処理を継続するエラートラップが実装されていることを確認しました。これは、想定外の状態においてもシステムをクラッシュさせない堅牢な設計（フォールバック）がなされている証拠です。

AppXSVC を「Start=3（手動）」に設定することは、システムを物理的・構造的に破壊するリスクがゼロであることが解析によって証明。

「1回目にアプリ起動エラーが出る」という副作用は、ServiceMain 内の重い初期化処理がアプリ側のタイムアウトを上回るために発生するものであり、2回目以降の起動で大体が成功が示す通り、サービスの整合性自体は維持されます。

で、本題のなぜ重くなるのか？

原因は単一のバグではなく、プログラム内に実装された「強権的なリソース確保ロジック」と「データベースの排他制御」になります。

「自分を最優先する」スケジューリングロジック

解析した FUN_18017816c のコードから、このサービスが「他を差し置いてでも動こうとする」性質なのが分かる。

• 優先度の「足切り」判定
  この関数は、自身の CPU 優先度が 8未満（通常以下）、または I/O 優先度が 2未満である場合を「異常（Inadequate）」と見なします。

• システムへの影響
  Windows の標準的なバックグラウンドプロセスは優先度を下げて動作しますが、AppXSVC は「十分な優先度が与えられていない」と判断すると、診断ログを吐きつつ高いリソースを要求し続けます。ゲームスレッドに割り当てられるべき CPU サイクルが奪われ、フレームタイムのスタッターが発生します。

データベース（StateRepository）のロック競合

抽出した文字列 StateRepository.Database.BusyOrLockedTimeoutExceeded は、リソース占有の証拠。

• SQLite の仕様と FixIntegrity→AppX の管理には SQLite (.srdファイル) が使われていますが、起動直後に StateRepositoryFixIntegrity（整合性修復）タスクが走ると、データベース全体に「書き込みロック」がかかります。

• 連鎖する遅延（I/O Wait）このロック中、他のプロセス（エクスプローラーやスタートメニューなど）がアプリ情報にアクセスしようとすると、ロックが解除されるまで「待機」させられます。これが、PC 操作中に一瞬フリーズしたように感じる「I/O 待ち遅延」の正体。

「状態分離（State Separation）」によるスキャンループ

解析した FUN_18002e880（RtlIsStateSeparationEnabled の呼び出し）が、処理をさらに重くしています。

• スキャン範囲の拡大→近年の Windows Update で強化された「状態分離」モードが有効な場合、サービスはシステム領域とユーザー領域の両方でアプリの整合性を再確認。

• 計算コストの増大→単なる起動確認ではなく、マニフェストファイルの再検証やディレクトリの再スキャンを行うため、ServiceMain 内で実行されるループ回数が劇的に増加し、ディスク I/O 負荷の状態が長く続くことになります。

「一時停止（Pause）」の拒絶とロールバック

FUN_1801e6f40（Deployment Request）の解析で見つかった、柔軟性の欠如も原因の一つ。

• 処理を止めない設計です。解析コードには "Pause feature is off because the configuration reg key is not set." という分岐が存在。デフォルトでは一時停止が無効であるため、一度スキャンが始まると、たとえゲームを起動しても処理を中断（Yield）しません。

• ロールバック負荷。万が一途中で中断しようとしても、解析コードにある通り "User-initiated cancels are not paused--instead, they are rolled back"（一時停止せずロールバックする）というロジックが走り、書き戻し処理によってさらに負荷が倍増。

高優先度の要求→CPU リソースの強奪による FPS の不安定化。
DB 排他ロック→ストレージ帯域の占有によるプチフリーズ（スタッター）
状態分離スキャン→起動直後のディスク I/O スパイクの長期化。
Pause 機能の無効化→ユーザー操作に関わらず処理を完遂しようとする「不柔軟さ」。

このサービスは「OS の整合性を守るために、他のリソースを犠牲にしても良い」という設計思想で動いています。 そのため、低遅延を求めるゲーマーにとっては、Start=3（手動）にしてこの「強権的なサイクル」自体を発生させないことが、最も効果的な対策となります。

以上の解析結果を以て、低遅延（Low Latency）を目的とした当該サービスのスタートアップ設定変更は、技術的に安全かつ正当な最適化手法であると判断します（自己責任でね）

以下、本来の記事です↓

「AppXSVC」が「手動（トリガー）」から「自動」に→この設定変更は2025年12月アップデート「KB5072033」で実装されたものです。

動作が「カクつく」「重い」等のPCパフォーマンスに影響します。
この機能が自動常駐するだけで、メモリが+２～４GB使用される、CPU負荷が無駄にかかる等の報告が多々上がっています＆動作が不安定になる。

一番のデメリットは、単なるメモリ消費等以上に、システムの「リアルタイム性」と「予測可能性」を損なう点にあります↓

ゲーム中に非同期的なバックグラウンド処理が走りやすくなる。

• データベースのスキャン→ AppXSVCは、インストールされているすべてのUWPパッケージ（ストアアプリ）の状態を管理しています。常駐化することで、システムがアイドルだと判断した際や特定のトリガーで、パッケージの整合性チェックやレジストリ走査をバックグラウンドで開始する。

• CPUスパイク→CPUの特定のコアに突発的な負荷が発生。特にゲームが使用しているコアと同じコアでこのスキャンが走ると、フレームタイムにバラつき（Jitter）が生じ、0.1% Low FPSの低下やスタッターの原因になります。

Microsoftにとっては「アプリの更新失敗を防ぐための安定策」として変更されましたが、ゲーマーにとっては「いつ発生するか予測できないパフォーマンス泥棒」を常に家の中に居座らせている状態と言えます。

なのでこの機能を自動→手動【必要な時のみ立ち上がるように設定しましょう】

レジストリでの変更が必要です【下にワンタッチで入れるスクリプト置いときます】自己責任で設定変更してください。

• Regeditを開く。

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AppXSVC を開く。

• Start の値を 2 (自動) から 3 (手動) に書き換える。

• PCを再起動する。

レジストリ触るのわからないや、間違えるのが怖い、面倒な方へ↓
自己責任でご使用ください

下をダウンロード後、ファイルをダブルクリック→情報を追加するとなんたらかんたらが出るので【はい】で完了します。PC再起動してください。
Start の値を 2 (自動) から 3 (手動) に変更されます。

↓はWindows既定の値【自動】に戻すファイルです。
使用方法は同じです。Start の値を 2 (自動)に戻します。
Windows Updateを実行する直前やエラー等で失敗する場合、Microsoft Storeアプリの更新・インストールができない時(基本は実行モード)になりますが、環境は千差万別です。