旧型デスクトップに Windows 11 を入れたら、1日に何度もブルースクリーン（BSoD）。WinDbg では「DRIVER_POWER_STATE_FAILURE（0x9F）／atapi.sys」と出る――この記事は、その典型症状を現場の切り分け手順で掘り下げ、原因特定から再発防止までを一気通貫で解説します。忙しい方は先に「実効性の高い対処表」をご覧ください。
症状の全体像と前提
相談内容を要約すると次の通りです。
- OS：Windows 11（旧型デスクトップへインストール）
- 頻度：1日に2〜3回のブルースクリーン（BSoD）
- ミニダンプ解析：DRIVER_POWER_STATE_FAILURE（0x9F）、犯人モジュールはatapi.sys
- 構成：Kingston 120GB SSD、WD 160GB HDD、ASUS P7P55D‑ELX マザーボード、メモリ12GB
このエラーは電源管理に関連するI/Oデバイス（多くはストレージ）が、スリープや電源状態の遷移にうまく応答できず、OSの電源IRPを長時間ブロックしたときに発生するのが典型です。コールスタックに atapi.sys が現れると、SATA/IDE周辺（HDD/SSD/光学ドライブ、ケーブル、ポート、コントローラ）の不調や相性が最有力容疑になります。
最初に見るべき「実効性の高い対処表」
| ステップ | 内容 | 目的 |
|---|---|---|
| 不要ストレージの切り離し | 使っていない SATA 機器（とくに光学ドライブ）を物理的に外し、再発有無をテスト。 → 実例では CD‑ROM ドライブを外した途端にクラッシュが停止。 | 故障デバイスの特定 |
| ケーブル確認・交換 | SATAケーブル・電源ケーブルを抜き差し、可能なら新品へ交換。ラッチ付きケーブル推奨。 | 接触不良・経年劣化の排除 |
| ストレージ健康診断 | CrystalDiskInfo等でS.M.A.R.T.を確認（代替処理済みセクタ数、未修復セクタ、UDMA CRCエラー、温度など）。異常値なら交換。 | デバイス故障の確認 |
| BIOS／チップセット更新 | マザーボードBIOSとストレージ周り（チップセット／RST相当）のドライバを見直し、古い独自ドライバは外してMicrosoft標準AHCI（storahci）を優先。 | I/Oタイムアウトの改善 |
| バックアップ | 外付けHDDやクラウドに重要データを退避。ディスクイメージ作成を推奨。 | 作業中のデータ損失防止 |
| 長期的対処 | 本機は Windows 11 の公式要件外（TPM 2.0／Secure Boot 非対応）。不安定が続くなら 対応ハードへ刷新。一時的な回避としては検証用OSや仮想化も選択肢。 | 今後の互換性・安定性確保 |
なぜ「0x9F／atapi.sys」で落ちるのか
0x9F（DRIVER_POWER_STATE_FAILURE）は、デバイスドライバが電源状態の遷移（S0↔S3/S4 等）に関連するIRPを握り続け、OSが待ちきれなくなると発火します。ストレージ系は電源管理とリンク電源管理（LPM/HIPM/DIPM）、回転系のスピンダウン、SATA再交渉などが絡み、わずかな不良や相性で「戻ってこない」ことが起こりやすい領域です。
スタックに atapi.sys（または ataport.sys）が見えるとき、犯人はOSのストレージスタックそのものとは限りません。多くは「下にぶら下がる物理デバイス／ケーブル／別ベンダー製コントローラ」が根本原因で、OS側が最後に巻き込まれているだけです。したがって、物理レイヤから順番に切り分けるのが最短です。
実例：光学ドライブの切り離しで収束
今回の構成では、使っていない光学ドライブを外した瞬間にBSoDが止まりました。古い光学ドライブは次の理由で電源管理に弱い典型例です。
- アイドル時のスピンダウン／復帰が遅延し、SATAのリンク再交渉に失敗する
- 劣化したトレイ機構やピックアップ駆動で電流急変→電源ノイズ→他デバイスが巻き添え
- JMicron/Marvell等の追加コントローラ配下だと、ドライバ層が複雑化しタイムアウトが発生しやすい
「使っていないなら物理的に外す」。これが最短の対処であり、再発しないなら故障デバイス確定です。
10分でできる初動チェックリスト
- 電源オプションを一時的に「高パフォーマンス」に（スリープ・ハイブリッドスリープ・ハードディスクの電源オフを一時無効）。
- 不要SATA機器を外す（光学ドライブ／カードリーダー／古いHDD）。
- SSDと起動に必要な1台だけで起動。それで安定するか確認。
- 別SATAポートへ差し替え、ラッチ付きケーブルを使用。3Gbps/6Gbps混在環境では片側だけ古いケーブルがボトルネックやCRCエラーの温床になります。
- イベントビューアの「システム」にDisk/StorAHCI/atapi/ataportの警告（例：イベントID 129/153）が連発していないかを確認。
ストレージ健診のやり方（S.M.A.R.T.の見方）
| 属性 | 見るポイント | 判断の目安 | アクション |
|---|---|---|---|
| Reallocated Sector Count（代替処理済） | 初期不良や劣化で増加 | 1以上で注意、連日増えるのは危険 | 早期バックアップ・交換 |
| Current Pending Sector（代替予定） | 読み取り困難セクタ | 1以上で要監視、増加は赤信号 | 交換・完全消去での再評価 |
| UDMA CRC Error Count | ケーブル品質／接触不良 | 0が理想、増えていればケーブル疑い | ケーブル交換・別ポート試験 |
| Power-On Hours / 温度 | 経年・熱劣化 | 高温常態は寿命短縮 | 冷却見直し・設置変更 |
とくにUDMA CRCエラーは「データ路」の問題を直撃で示します。BSoDが出たり出なかったりする「再現性の低い不具合」はケーブル・ポート・電源の境界に潜みがちです。
BIOS/UEFIとポートの見直し
- SATAモードはAHCIに統一（IDE/RAIDのままだとレガシー層を経由し、atapi.sys経由の相性が増える）。
- 追加コントローラ（JMicron/Marvell等）配下を避ける。OS標準のIntel PCH直結ポートへ接続。
- 未使用ポートの「Hot Plug」を無効。必要なポートだけ有効化。
- 古いBIOSは更新。ストレージ初期化や電源管理の微修正が多数含まれます。
古いマザーボードは、OSから見ると同じSATAでも複数の別ベンダー制御が混在していることが珍しくありません。起動SSDは最も素直なチップセット直結ポートへ。
Windows側ドライバの方針：まずは「標準AHCI（storahci）」
旧世代チップセットに古いRST系ドライバを当てると、Windows 11 と相性を生むことがあります。次で確認しましょう。
- デバイス マネージャー → IDE ATA/ATAPI コントローラーまたは記憶域コントローラーを開く。
- 「標準 SATA AHCI コントローラー」になっているか、ドライバ提供元がMicrosoftか確認。
- もしベンダー独自ドライバなら、ドライバの更新 → コンピューターを参照 → 互換性のあるハードウェアの表示で標準SATA AHCIに切替えて挙動を見る（事前バックアップ必須）。
この切替でBSoDが止まる事例は多く、逆に標準から独自ドライバへ替えると悪化するケースもあります。まずは標準で安定化→必要ならベンダー版を試す順序が安全です。
電源オプションと省電力設定の暫定無効化
原因切り分けの間だけ省電力を外し、スリープ／ドライブの電源断／PCIeのリンク状態電源管理（LPM）をオフにして様子を見ます。
- 電源プランを高パフォーマンスへ。
- ハードディスク→「次の時間が経過後ハードディスクの電源を切る」をなし。
- スリープ／ハイブリッドスリープを無効。
- PCI Express → リンク状態の電源管理をオフ。
これで再発が止まるなら、省電力遷移がトリガと分かります。安定した後、項目を一つずつ元に戻し、どこで再発するかを特定します。
WinDbg での読み方（要点だけ）
ミニダンプを WinDbg で開いたら、まずは：
!analyze -v
続いて現在のIRPやデバイスオブジェクトをたどります：
!irp <IRPアドレス>
!devstack <デバイスオブジェクト>
!poaction
lmvm atapi
スタックに atapi.sys/ataport.sys、storahci.sys、クラッシュ直前のストレージデバイスドライバ（例：iaStor/iaStorA/ベンダーSATA）が見えたら、物理デバイスまたはコントローラ周りの遅延が濃厚です。犯人モジュール名だけで「OSが悪い」と決めつけず、下層の実体（接続機器・ケーブル・ポート）へ降りていくのが鉄則です。
ケーブル・ポート・電源：ハードのツボ
- ラッチ付きSATAケーブルを使用（経年で緩むと衝撃や温度で外れかける）。
- ケーブル長を短く、折り曲げすぎない。シャープな折れや束ねすぎは伝送エラーの元。
- 別のSATAポートへ差し替え。同じコントローラ内でも物理ポートの品質差が出ることがあります。
- 電源分岐は少なく、HDD/光学ドライブの同一ライン多段分岐は避ける。
- 一時的に光学ドライブを完全撤去。使っていないならそのまま外しておくのがベスト。
イベントログで「前兆」を掴む
イベントビューアの「Windows ログ → システム」で、次の警告／エラーが連発していないか確認します。
- Disk（遅延や再試行、タイムアウト）
- storahci/atapi/ataport（バスのリセットや遅延）
- Ntfs（I/O再試行やジャーナルのロールバック）
とくに短時間に集中して出ている時間帯をメモし、ユーザー操作（スリープ復帰・ゲーム起動・バックアップ開始）と突き合わせると誘因が見えます。
OSレベルの基本健全化
- システムファイルチェック：
sfc /scannow DISM /Online /Cleanup-Image /RestoreHealth - クリーンブート（常駐を最小化して再現するか確認）。
- ドライバの整理：古い仮想ドライブ／チップセット外デバイスのユーティリティは一旦外す。
電源管理の裏側を点検（powercfg）
コマンドプロンプト（管理者）で、スリープや即時妨害を確認します。
powercfg /a
powercfg /requests
powercfg /devicequery wake_armed
powercfg /lastwake
スリープ不可や復帰直後の不安定が続くなら、/requestsで常時I/O要求を出し続けるプロセスを特定・停止し、問題の切り分けを進めます。
「犯人はOS」ではなく「下層のどれか」：切り離し試験の手順
- すべてのSATA機器を外し、起動SSDのみで起動。
- 安定後、HDDを1台だけ追加して数時間〜1日観察。
- 問題なければ次の機器を追加……を一本ずつ繰り返す。
- どこかで再発したら、その機器／ケーブル／ポートの組み合わせを入れ替えて再試験。
この「一本ずつ戻す」方法が、最短・最確実です。とくに光学ドライブや古いHDD、外付けケース（ブリッジチップ）に要注意。
旧世代マザー特有の落とし穴
- 追加SATAコントローラ（JMicron/Marvell/ASMedia等）配下は避ける。BIOSで無効化できるなら未使用分は切る。
- USB3.0コントローラの相性でスリープ復帰時にストレージが遅延することがある。USB機器を外して検証。
- メモリ構成の混在（容量／速度／ブランド）が不安定の土台を作る。Memtestで最低1周は検証。
「長期的な安定」の考え方
今回の構成は、TPM 2.0／Secure Boot といったWindows 11 の公式要件を満たしていません。このため、アップデートやドライバ検証の前提が崩れ、不具合の再発確率が高止まりします。運用の安定を最優先するなら次の選択肢を検討してください。
- 対応ハードウェアへ刷新（現行世代のCPU・チップセット・電源・SSDへ移行）。
- 仮想化で分離：ホストは安定構成、当該旧環境はゲストとして隔離。I/Oの影響を封じ、バックアップも容易。
- 用途分離：信頼性が必要な業務領域と、検証／サブ用途を分ける。
なお、Windows 10 は通常サポートが終了済み（ESU等の例外を除く）であるため、暫定回避として戻す選択はリスクを理解した上でに限ります。最終的には、要件を満たすハードでWindows 11を使うのが王道です。
原因別の「勘どころ早見表」
| 現象 | 怪しい箇所 | 試すこと |
|---|---|---|
| スリープ復帰直後に0x9F | 光学ドライブ、外付けHDD、追加SATAコントローラ | 機器撤去、標準AHCI、電源設定の省電力オフ |
| 負荷をかけると落ちる | 電源容量不足、ケーブル接触不良、温度 | 別系統電源、ケーブル交換、冷却強化 |
| アイドル放置で落ちる | ディスクのスピンダウン、LPM、スケジュールタスク | 電源プラン見直し、バックアップ時間帯を変更 |
| イベントログにUDMA CRC | データ路（SATAケーブル／ポート） | ケーブル交換、別ポート、取り回し改善 |
安全第一：バックアップ戦略
切り分け中にディスクが完全に死ぬことは珍しくありません。次を徹底します。
- ユーザーデータの即時コピー（ドキュメント、写真、メールアーカイブ）。
- システムのディスクイメージ（復旧時間を短縮）。
- SMARTに異常が出たら即交換（「様子を見る」は危険）。
これだけはやめたいNG対処
- 原因不明のままドライバを手当たり次第に更新／ロールバック（再現条件が見えなくなる）。
- 疑わしい機器を接続したまま運用継続（BSoDがデータ破損を誘発）。
- レジストリでLPMを闇雲に無効化（副作用の把握が難しい）。まずは電源プランで再現性を見極める。
最短ルートまとめ（実行順）
- バックアップ（データ＆イメージ）。
- 光学ドライブなど未使用SATA機器を撤去、起動SSDのみでテスト。
- ケーブル交換・別ポート、UDMA CRCの有無をチェック。
- 標準AHCI（Microsoft）へ統一、追加コントローラは避ける／無効化。
- 電源プランを高パフォーマンス、スリープ・LPMを一時停止して再現性確認。
- BIOS更新・設定見直し（AHCI、Hot Plug、不要コントローラ無効）。
- それでもダメならハード刷新（要件準拠のWindows 11環境へ）。
Q&A：よくある誤解と補足
- Q：atapi.sysと表示された＝Windowsの不具合？
いいえ。多くは物理デバイスやコントローラ周りの遅延です。OSが最後に巻き込まれているだけ。 - Q：メモリ不良でも0x9Fは出る？
主因ではありませんが、同時にI/Oが壊れるため、別のバグチェックやファイル破損を誘発します。Memtestは一度実施を。 - Q：USB接続の外付けHDDは無関係？
いいえ。復帰直後のスピンダウン／スピンアップやブリッジチップの相性がトリガになることがあります。外して検証を。 - Q：省電力を全部オフにしたまま運用してよい？
切り分け中は可。落ち着いたら、一つずつ戻して副作用を確認しましょう。
チェックシート（印刷して使えます）
| 項目 | 確認 | 結果／メモ |
|---|---|---|
| データ＆イメージのバックアップ完了 | □ | |
| 光学ドライブ・未使用SATA機器を撤去 | □ | |
| ケーブル交換（ラッチ付・短尺）／別ポート | □ | |
| S.M.A.R.T.に異常なし（CRC・Pending・Realloc） | □ | |
| 標準AHCI（Microsoft）で動作 | □ | |
| 電源プラン：高パフォーマンス／LPMオフで安定 | □ | |
| イベントログにDisk/StorAHCIの警告が消失 | □ | |
| BIOS更新・不要コントローラ無効化 | □ |
結論
DRIVER_POWER_STATE_FAILURE（0x9F）で atapi.sys が挙がるとき、疑うべきはストレージ周辺です。今回のように、使っていない光学ドライブや劣化したSATAケーブルが元凶であることは珍しくありません。物理レイヤ→BIOS→OSドライバ→省電力設定の順で丁寧に切り分ければ、原因は必ず絞れます。要件外ハードで無理にWindows 11を運用するのは、長期的には保守コストが嵩みます。安定を重視するなら、要件準拠のハード刷新を視野に、いま発生している0x9Fを「構成を見直すチャンス」と捉えて対処しましょう。
付録：参考コマンド集（コピペ用）
:: システム整合性
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
:: 省電力と復帰の状態
powercfg /a
powercfg /requests
powercfg /devicequery wake_armed
powercfg /lastwake
:: ストレージの簡易チェック（管理者PowerShell）
Get-PhysicalDisk | Select FriendlyName, HealthStatus, OperationalStatus, Size
Get-EventLog -LogName System -Newest 200 | ? {$_.Source -match "disk|storahci|atapi|ataport"}
:: メモ：WinDbg基本
!analyze -v
!irp
!devstack <デバイス>
!poaction
lmvm atapi 付録：トラブルの再発を減らす運用Tips
- 定期的にS.M.A.R.T.を確認し、UDMA CRCが増えたらケーブル再点検。
- バックアップは「3-2-1」（3世代、2種類メディア、1つはオフサイト）。
- USB外付けHDDは安全な取り外しを徹底し、スリープ中の給電設定を見直す。
- イベントビューアのカスタムビューでDisk/StorAHCI/atapiの警告を一括監視。
コメント