Windows 11 スリープ復帰直後のブルースクリーン 0x9F(DRIVER_POWER_STATE_FAILURE)の原因と対処法

Windows 11 をクリーンインストールしたばかりなのに、スリープ復帰直後にブルースクリーン(BSoD)が出て再起動してしまう──自作PCではありがちなトラブルです。本記事では、停止コード 0x9F「DRIVER_POWER_STATE_FAILURE」が出るケースを題材に、Qualcomm 製 Wi‑Fi ドライバーを主因とする事例をベースに、原因の考え方と具体的な対処手順をまとめます。

目次

Windows 11 のスリープ復帰で発生する 0x9F(DRIVER_POWER_STATE_FAILURE)とは

停止コード 0x9F(DRIVER_POWER_STATE_FAILURE) は、Windows がスリープ/休止・シャットダウン・復帰などのタイミングでデバイスドライバーの電源状態遷移に失敗したときに発生する代表的なバグチェックです。

今回のケースでは、以下のような状況が揃っていました。

項目状況
OSWindows 11(クリーンインストール直後)
ハード構成CPU・マザーボード・メモリを一新した自作PC
症状スリープからの復帰直後に即ブルースクリーン発生 → 自動再起動
イベントログBugcheck 0x9F、DCOM 10010、予期しないシャットダウン 6008、Fast Startup 失敗 29 など
拡張カード10GbE SFP+ カード(本来 x8/x16 用)を x1/x4 スロットで使っていた履歴あり

一見すると、イベントログに色々な警告が並ぶため「どこから手を付けてよいか分からない」状態になりがちですが、0x9F の本質は「電源管理に失敗しているドライバーはどれか?」を特定することにあります。

結論:内蔵無線LAN(Qualcomm Wi‑Fi)ドライバーの電源管理不具合が主因

今回の実際の再現事例では、マザーボード内蔵の Qualcomm 製 Wi‑Fi(WLAN)ドライバーがスリープ復帰時に不正な電源状態のまま固まり、OS からの要求に応答しなくなったことが原因でした。

Windows では、デバイスには以下のような電源状態(Device Power State)が定義されています。

  • D0:フル稼働状態
  • D1/D2:中間的な省電力状態
  • D3:完全オフ(スリープ中・無効化など)

停止コード 0x9F は、たとえばスリープ復帰時に D3 → D0 に戻るはずが、ドライバーが期限内に遷移せずタイムアウトした場合によく発生します。問題の Wi‑Fi ドライバーは、スリープ復帰の瞬間にこの電源状態を正しく切り替えられず、結果として BSoD につながっていました。

さらに、サードパーティ製のドライバー更新ツールで自動更新したり、チップセット・LAN・Bluetooth ドライバーが混在インストールされていたことで、電源管理まわりの挙動が不安定になっていた可能性も高いと考えられます。

まずはここから:BSoD を止めるための全体方針

0x9F が関係するトラブルでは、やみくもに設定をいじる前に、次の 3 つを意識して対処していくと効率的です。

ステップ目的ポイント
① 問題ドライバーの切り分けどのデバイスが電源管理でコケているかを特定ミニダンプ・イベントログ・構成変更の履歴を確認
② ドライバーの「公式だけ」クリーン再導入混在・競合しているドライバーを排除マザーボード公式サイトのパッケージのみ使用
③ 電源管理設定の調整スリープ復帰を安定させ、再発を防ぐデバイス単位・OS 全体両方の省電力設定を見直す

ここからは、実際に 0x9F が解消した具体的な手順を、順番に解説していきます。

ドライバーを「公式だけ」でクリーン再導入する

事前準備:必要なドライバーを公式サイトからダウンロード

まずは、ネットが切れても困らないように、必要なドライバーをすべて事前にダウンロードしておきます。

  • マザーボードメーカー(例:MSI)のサポートページから次のドライバーを取得
    • Wi‑Fi(WLAN)ドライバー
    • Bluetooth ドライバー
    • AMD チップセットドライバー
  • 可能なら、別の PC やスマホからも同じファイルをバックアップしておく
  • ドライバー更新ツール(Snappy Driver Installer 等)は使用しない

自動更新ツールは便利な反面、公式サポート範囲外のバージョンを入れてしまうことがあり、スリープ・スタンバイ・電源管理まわりで想定外の不具合を招くことがあります。今回のようにトラブルが起きているときは、いったん「公式だけ」に絞る方が安全です。

既存の Qualcomm Wi‑Fi / Bluetooth ドライバーを完全に取り外す

  1. 管理者権限のアカウントで Windows にサインインする。
  2. デバイス マネージャーを開き、[ネットワーク アダプター]を展開。
  3. Qualcomm 製の Wi‑Fi デバイス(名称に「QCA」「QCN」などを含むことが多い)を右クリックし、[デバイスのアンインストール]を選択。
  4. [このデバイスのドライバーソフトウェアを削除する]にチェックを入れてアンインストールする。
  5. 同様に、Bluetooth の Qualcomm 関連デバイスもアンインストールする。

アンインストール後、デバイスが一覧から消えてしまう場合があります。その場合は、デバイス マネージャーのメニューから [表示] → [非表示のデバイスの表示] をオンにして、残っているゴーストデバイスを削除しておきましょう。

pnputil で古い oem*.inf を削除する(上級者向け)

デバイス マネージャーで消しただけでは、内部の「ドライバーストア」に古い inf が残っていることがあります。より徹底するには、pnputil コマンドで Qualcomm 関連のドライバーを削除します(誤削除のリスクがあるため、操作に慣れている方推奨)。

pnputil /enum-drivers | findstr /i "qualcomm qca qcn wlan wifi"

上記で表示された中から、明らかに Wi‑Fi 関連と思われる oemXX.inf を確認し、問題なさそうなら削除します。

pnputil /delete-driver oemXX.inf /uninstall /force /reboot

このコマンドを実行すると再起動が必要になるため、事前に公式ドライバーのインストーラーをローカルに保存しておくことを忘れないでください。

公式ドライバーのインストール順序

再起動後、次の順番でドライバーをインストールしていきます。

  1. AMD チップセットドライバーをインストール → 再起動
  2. Wi‑Fi(WLAN)ドライバーをインストール → 再起動
  3. Bluetooth ドライバーをインストール → 再起動

MSI Center の Live Update などで自動検出できなくても、サポートページからダウンロードしたインストーラー(.exe, .bat など)を直接実行すれば問題ありません。自動ツールに頼らず、自分でバージョンを管理するイメージです。

スリープ復帰を安定させるための電源設定の見直し

Wi‑Fi デバイスの電源管理タブを調整する

ドライバーをクリーンに入れ直したら、次は個々のデバイスの電源設定を見直します。

  1. デバイス マネージャーから Qualcomm Wi‑Fi デバイスのプロパティを開く。
  2. [電源の管理]タブを選択。
  3. [電力節約のために、コンピューターでこのデバイスの電源をオフにできるようにする]のチェックを外す。
  4. 必要に応じて、Bluetooth アダプターにも同様の設定を適用。

この設定をオフにすることで、スリープ中でもデバイスが完全に落ち切らず、復帰時の電源状態遷移が安定するケースが多く見られます。特に無線 LAN や Bluetooth は、OS の省電力制御とドライバー側の制御がバッティングしやすいため、ひとまず電源オフを許可しない方向で様子を見るのがおすすめです。

Windows 側の省電力設定を調整する

次に、OS 全体の電源オプションも見直しておきます。

  • 電源オプション → 詳細な電源設定の変更 → PCI Express → リンク状態電源管理をオフにする。
  • 高速スタートアップを無効化する。
    • コントロールパネル → [電源オプション] → [電源ボタンの動作を選択する]
    • [現在利用可能ではない設定を変更します] をクリック
    • [高速スタートアップを有効にする] のチェックを外す

高速スタートアップは、起動時間の短縮には有効ですが、スリープ・休止・再起動の挙動が複雑になり、特にドライバーが不安定な環境ではトラブルのトリガーになることがあります。トラブルシュート中はオフにしておき、安定を確認してからオンに戻すといった運用も有効です。

UEFI/BIOS と拡張カードの確認ポイント

BIOS を最新にしてメモリ設定は「安定寄り」に

  • マザーボードメーカーのサイトから最新 BIOSにアップデートする。
  • メモリの EXPO / XMP 設定は、まずは標準(Auto)または定格で動作確認。

メモリオーバークロック自体が直接 0x9F を起こすわけではありませんが、復帰直後の不安定なタイミングで誤動作を誘発する要因になり得ます。問題切り分けのためにも、まずは標準設定で様子を見る方が確実です。

10GbE SFP+ カードの差し込みスロットに注意

今回の環境では、x8 以上が推奨される 10GbE SFP+ カードを x1 / x4 スロットに挿して使用していた履歴がありました。この構成では、イベントログに次のような警告が出ることがあります。

  • Event ID 37:帯域不足や制限状態に関する警告 など

帯域不足自体は 0x9F の主因ではありませんが、スリープ復帰時に複数のデバイスが同時に復帰処理を行う際、PCIe バスの状態が不安定になるリスクがあります。問題切り分けのためにも、次のように対応するのが無難です。

  • 10GbE カードはx8 / x16 スロットにのみ利用する。
  • スリープ復帰の検証中は、増設 NIC を物理的に取り外した状態で試す。

Wi‑Fi だけでなく、有線 LAN やストレージカードなど、高速 PCIe デバイスはスリープ復帰時のトラブル要因になりやすいパーツです。疑わしいカードは一度外して、最小構成で安定を確認しましょう。

スリープ復帰後の挙動を検証するチェックポイント

スリープ/復帰を複数回テストする

設定変更後は、必ず以下のように複数回テストします。

  1. スタートメニューから「スリープ」を選択。
  2. 数十秒〜数分ほど待ってからキーボードやマウスで復帰。
  3. 同じ手順を5〜10回以上繰り返す。

0x9F のような電源管理系のトラブルは、毎回ではなく、数回に一度だけ発生することも多いため、1〜2回成功しただけでは安心できません。ある程度回数を重ねて再発がないか確認しておきましょう。

powercfg でスリープ解除デバイスを確認する

管理者権限のコマンドプロンプトまたは PowerShell で、次のコマンドを実行します。

powercfg -devicequery wake_armed

ここに不要なデバイス(たとえば Wi‑Fi や Bluetooth)が含まれている場合、そのデバイスのプロパティから「このデバイスで、コンピューターのスタンバイ状態を解除できるようにする」のチェックを外し、スリープ解除を許可するデバイスを絞り込むと安定しやすくなります。

イベントログで BugCheck / Kernel-Power の再発を確認

イベントビューアーの [Windows ログ] → [システム] を開き、次のイベントを中心にチェックします。

  • BugCheck 1001:ブルースクリーン発生ログ
  • Kernel-Power 41 / 6008:予期しないシャットダウン・再起動

スリープ復帰テスト後にこれらが記録されていなければ、少なくとも 0x9F で OS が落ちてはいないと判断できます。

ミニダンプから原因ドライバーを読む簡易手順

もう一歩踏み込んで、.dmp(ミニダンプ)ファイルから原因ドライバーを確認したい場合は、Microsoft 純正のデバッガーを使う方法があります。

  1. Microsoft Store から WinDbg Preview をインストール。
  2. C:\Windows\Minidump フォルダを開き、最新の日付の .dmp ファイルをコピーしてバックアップ。
  3. WinDbg Preview を起動し、[File] → [Open dump file] から当該 .dmp を開く。
  4. 下部のコマンド欄に次を入力して Enter。
!analyze -v

解析が終わると、出力の中に次のような情報が含まれます。

  • BugCheck:0x9F など停止コード
  • MODULE_NAME / IMAGE_NAME:問題を起こした可能性の高いドライバー(例:qcawlan.sys など)

ここで Wi‑Fi 関連のドライバー名が挙がっていれば、今回のようにQualcomm Wi‑Fi ドライバーを最優先で疑うべきと判断できます。逆に、ストレージ・GPU・USB など別のモジュール名が出ている場合は、そちらのデバイスとドライバーを中心に対処していきます。

「デバイス マネージャーが『最新です』と言う/削除したら Wi‑Fi が消えた」場合のリカバリ

トラブルシュート中によくあるのが次のような状態です。

  • 公式インストーラーを実行しても何も変わらない
  • デバイス マネージャーでは「最適なドライバーがすでにインストールされています」と表示されてしまう
  • 削除したら Wi‑Fi デバイス自体が一覧から消えた

このようなときは、以下の手順で復旧を試みます。

非表示デバイスを表示して残骸を削除 → 再検出

  1. デバイス マネージャーを開く。
  2. メニューから [表示] → [非表示のデバイスの表示] をオンにする。
  3. ネットワークアダプター・Bluetooth などのカテゴリーを展開し、グレーアウトしている古いデバイスを削除。
  4. メニューの[操作] → [ハードウェア変更のスキャン]を実行して、デバイスを再検出。

これで再検出されれば、そのまま公式ドライバーをインストールします。

それでも復活しない場合:pnputil で旧ドライバーを削除してから公式を即インストール

それでも Wi‑Fi デバイスが出てこない場合、前述の pnputil を用いて古い oem*.inf を削除し、再起動後にすぐ公式インストーラーを実行します。

注意点として、pnputil で誤ったドライバーを削除すると、ほかのハードが動かなくなる可能性があります。必ず /enum-drivers の出力をよく確認し、名称やプロバイダー名からQualcomm / Wi‑Fi 関連であることを十分に確認してから削除してください。

MSI Center ではなく、サポートページのパッケージを直接使う

MSI Center の Live Update は便利ですが、

  • 最新バージョンを検出しない
  • インストールが途中で失敗する

といったケースも珍しくありません。確実なのは、マザーボードの型番ページから個別のドライバーパッケージ(ZIP/EXE)を直接ダウンロードして実行する方法です。

ネットワークを確保してから作業する

Wi‑Fi ドライバーを完全に削除すると、一時的にネットワークが一切使えなくなる可能性があります。作業前に次のいずれかを準備しておきましょう。

  • マザーボード内蔵の有線 LAN ポートを使える状態にしておく
  • スマホのテザリングで一時的なネット接続手段を確保しておく
  • 念のため、使用するすべてのドライバーをUSB メモリなどに保存してから作業に入る

イベントログに出ていたその他の項目の扱い

今回のケースのイベントログには、次のようなエントリが多数記録されていました。

  • DCOM 10010
  • TLS 36882 など証明書関連の警告
  • Fast Startup 29(高速スタートアップ関連)

これらは 0x9F と一緒に出てきやすいですが、多くの場合は副次的なノイズであり、根本原因ではありません。

イベントおおまかな意味本件との関係
DCOM 10010特定の COM サーバー/サービスがタイムアウトスリープ復帰直後やクラッシュ直後に発生しやすいが、0x9F の主因ではない
TLS 36882証明書や暗号化セッションに関する警告ネットワークスタックが不安定なときの副次的エラーのことが多い
Fast Startup 29高速スタートアップの失敗今回のような復帰時の不具合と同時に出ることはあるが、原因ではなく結果のことも多い

電源ユニット(例:Seasonic 750W / SSR-750FX)についても、構成的には十分余裕があり、スリープ復帰時だけ 0x9F が出るという症状から考えても、PSU が主犯である可能性は低いといえます。

再発防止のための運用上のコツ

ドライバー更新ツールを常用しない

改めて強調しておきたいのが、サードパーティのドライバー一括更新ツールに頼りすぎないことです。

  • ベンダー非推奨のドライバーやベータ版が紛れ込む
  • チップセット・LAN・ストレージなど、電源管理に直結する部分の互換性が崩れる
  • 不具合発生時に「どのバージョンに戻せば良いか」追跡しにくい

安定運用を優先する自作PCでは、

  • チップセット・LAN・Wi‑Fi・Bluetooth はマザーボードメーカー公式
  • GPU はGPUベンダー公式(AMD / NVIDIA / Intel)

といった形で、入手元を絞っておくのが結果的にトラブルを減らします。

大きな Windows アップデートの後はスリープ動作を確認

Windows 11 は年に数回、機能アップデートや累積更新プログラムによって内部の電源管理やドライバーモデルが変わることがあります。大きな更新後は、次のような簡易チェックをルーチン化すると安心です。

  • スリープ → 復帰を数回実施して BSoD が出ないか確認
  • イベントログに BugCheck 1001 / Kernel-Power 41 が出ていないかざっと眺める
  • 更新後しばらくの間は、スリープより「シャットダウン+起動」を優先する

すぐ着手できるチェックリスト(要約)

最後に、本記事で紹介した内容を「今すぐできるアクション」としてまとめます。

  1. AMD チップセット → 再起動 → マザボ公式 Wi‑Fi → 再起動 → 公式 Bluetooth → 再起動の順でドライバーをクリーン再導入する。
  2. Qualcomm Wi‑Fi デバイスのプロパティから、電源管理タブの「電源をオフにできるようにする」のチェックを外す。
  3. 電源オプションで、PCIe リンク状態電源管理をオフ、高速スタートアップを無効にして検証する。
  4. 10GbE SFP+ カードはx8 / x16 スロットのみで使用し、検証中は一度取り外して最小構成で試す。
  5. powercfg -devicequery wake_armed でスリープ解除デバイスを確認し、不要なものは解除する。
  6. スリープ → 復帰を複数回繰り返し、イベントログでBugCheck 0x9F や Kernel-Power 41/6008 が再発していないかを確認する。

この流れを踏めば、スリープ復帰のたびに発生していた 0x9F(DRIVER_POWER_STATE_FAILURE)の BSoD は高い確率で解消・再発抑制が期待できます。特に、Qualcomm Wi‑Fi ドライバーのクリーン再導入と電源管理設定の見直しは、同様の環境でのトラブルシュートの「定番パターン」として覚えておくと役立つはずです。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次