Windows 11で休止状態にすると電源は切れる。でも、次に電源を入れると、開いていたChromeやメモ帳が戻ってこない。休止したはずなのに、普通に起動したときと同じ状態になっていた。
イベントログに残っていたのは 0xC0000411 と、メモリマップの変更を示すエラー。休止ファイルの作り直しやBIOS更新では改善せず、Credential Guardの無効化を起動時に承認した後、ようやくアプリが復元された。
その後、メモリ整合性をONへ戻しても正常に復帰できた。今回は、この中古PCで何を試し、どこで結果が変わったのかをまとめる。
休止には入れるのに、開いていたアプリが戻らない
使っているのは、中古で購入したFUJITSU ESPRIMO D7010/FX。Core i5-10500とメモリ16GBを搭載し、Windows 11 ProをクリーンインストールしたPCだ。OSビルドは26200、BIOSモードはUEFI、セキュアブートは有効になっている。
休止前にはChatGPT、Chrome、メモ帳などを開いていた。休止を実行するとPCの電源自体は切れるが、次回起動時にはPIN画面が表示され、ログインしても作業中のアプリが復元されなかった。
電源が切れるところまでは進むので、「休止状態に入れない」というより、休止データから元の状態へ戻す処理が失敗しているように見えた。そこで、設定を次々に変える前にイベントログを確認した。
イベントログに0xC0000411とメモリマップ変更エラー
イベントビューアーでは、休止復帰に失敗した時刻付近のKernel-Bootを確認した。System側のイベントID 16に、次の記録が残っていた。
FailureStatus: 3221226513
FailureMsg:
A fatal error occurred processing the restoration data.3221226513を16進数にすると0xC0000411。表示されたメッセージも「Windows はエラー ステータス 0xC0000411 の休止状態から再開できませんでした」という内容だった。
さらに、Kernel-BootのOperationalログのイベントID 158には、次の文字列があった。以下は確認したログの転記で、画面の再現画像ではない。
BL_LOG_ERROR_RES_INVALID_HBBOOT_MEM_MAP
The memory map has changed since associated cold boot.ここでいうメモリマップは、Windowsが使うメモリ領域の配置情報のこと。今回のログからは、関連する通常起動時から配置情報が変わり、保存された休止データを復元できなかったと読み取れる。
ただし、これだけでメモリ故障や特定のセキュリティ機能が原因と分かるわけではない。まずは休止ファイルや起動設定から切り分けていった。
休止ファイルの再作成やBIOS更新では直らなかった
hiberfil.sysを作り直し、容量も増やした
最初に疑ったのは、休止状態の保存先であるhiberfil.sys。保存ファイルの問題かを確認するため、管理者権限のコマンドプロンプトで、休止を一度無効にしてから再有効化した。実行すると既存の休止データは失われるため、作業中のファイルは先に保存しておく。
powercfg /h off
powercfg /h on
powercfg /h /type fullコマンドは正常終了し、Full設定後のhiberfil.sysは約6.3GBになった。ただ、休止からの復帰は依然として失敗する。
容量が関係しているかも確かめるため、続けてRAM容量の100％を指定した。
powercfg /h /size 100ファイルは約15.8GBまで増えたが、結果は変わらなかった。このPCでは、休止ファイルを大きくするだけでは改善しなかった。
powercfgの休止ファイル設定は、Microsoftの公式コマンド資料でも確認できる。
高速スタートアップとBIOSも確認
高速スタートアップはONとOFFの両方を試したが、どちらでもアプリは戻らなかった。
BIOSも更新した。更新前はR1.38.0（2021年4月15日）、更新後はR1.67.0（2026年1月29日）。更新自体は正常に完了したものの、休止復帰の症状は残った。
少なくとも今回の結果では、「古いBIOSを更新すれば解決する」「hiberfil.sysの容量を増やせば解決する」という単純な話ではなかった。
メモリ整合性をOFFにしても、VBSは実行中だった
次に、仮想化を使うセキュリティ機能を切り分けた。VBSは仮想化を利用する保護の仕組みで、メモリ整合性もその仕組みを使う機能の一つだ。メモリ整合性をOFFにすることと、VBS全体を止めることは同じではない。
Windows セキュリティの「デバイス セキュリティ → コア分離」から、メモリ整合性をOFFにした。
この画面はOFFにした直後で、上部に再起動を求める表示が出ている。再起動まで済ませて休止復帰を試したが、改善はなかった。
実際の稼働状態を確認するためにsysteminfoを実行すると、「仮想化ベースのセキュリティ: 状態: 実行中」「ハイパーバイザーが検出されました」と表示された。メモリ整合性をOFFにしても、別の保護機能によってVBSが動いている可能性が残った。
起動設定やレジストリを変更しても表示は変わらず
ハイパーバイザーの起動を止められるか確認するため、切り分けの中で次の設定も実施した。これは実施した内容の記録で、休止復帰エラーだけを根拠に実行する手順ではない。
bcdedit /set hypervisorlaunchtype offDeviceGuardのEnableVirtualizationBasedSecurityも0へ変更した。しかし、再起動後のsysteminfoではVBSは実行中のまま。Windowsの機能ではHyper-VがOFFになっていたが、それでもハイパーバイザー検出の表示が残っていた。
関連するレジストリにはOFF側の値がある一方、IsSecureKernelRunningには1が残っていた。設定値だけを見て「もう止まっている」と判断できない状態だった。
適用ポリシーも確認するため、管理者PowerShellでCiToolを実行した。
CiTool --list-policiesMicrosoft Windows Virtualization Based Security Policyなどが適用中と表示された。ただ、この一覧だけでCredential Guardの稼働状態や、休止復帰失敗の原因を確定することはできない。設定画面と実際の状態が一致していないように見えたことが、次の確認につながった。
Credential GuardのOpt-outを承認した後、初めて復帰できた
変更前に確認しておきたいこと
ここからは、Windowsのセキュリティ機能に関わる操作になる。Credential Guardは認証情報を保護する機能で、無効化は保護を弱める変更だ。会社や学校が管理するPCなら、管理者に確認する必要がある。
個人のPCでも、変更前の設定を記録し、重要なデータを保存・バックアップしておく。BitLockerやデバイス暗号化を使っている場合は、回復キーを別の端末などから確認できるようにしておきたい。今回も、セキュリティ機能をOFFのまま使う方法を探すのではなく、原因を切り分けるために変更した。
DG Readiness Toolを実行
使用したのは、MicrosoftのDevice Guard and Credential Guard Hardware Readiness Tool。配布ページのバージョンは3.6だが、対応OSの記載はWindows 10とWindows Server 2016になっている。今回Windows 11で使った実体験を、Windows 11全般で保証された修復方法とは扱わない。
Microsoftの配布元から入手したファイルを確認したうえで、そのスクリプトがあるフォルダを開き、管理者PowerShellで次を実行した。
Set-ExecutionPolicy Bypass -Scope Process -Force
.\DG_Readiness_Tool_v3.6.ps1 -Disable -AutoReboot1行目の実行ポリシー変更は、そのPowerShellプロセスの範囲だけに適用される。ただし、スクリプトの安全性を保証する設定ではない。入手元が不明なファイルを実行するために、同じ操作を使うべきではない。
実行中には「SIPolicy.p7bが存在しない」「Disabling Hyper-V failed please check the log file」といったエラーも出た。すべての処理が成功したわけではなく、結果としてPCは再起動へ進んだ。
再起動時に出た、いつもと違う承認画面
再起動すると「Credential Guard Opt-out Tool」という画面が表示された。「Do you want to disable Credential Guard?」と聞かれ、保護を無効にする影響についても警告が出ていた。
画面下部には、WindowsキーまたはF3で無効化し、Escでこの手順をスキップする案内がある。今回は、その案内に従って無効化を承認した。
MicrosoftのCredential Guard設定資料にも、UEFIロック付きで有効化されたCredential Guardの解除には、端末の前で起動時の変更を承認する手順が説明されている。ただし、このPCが当初どのような経緯で設定されたのかまでは、今回の記録から確定できない。
VBSが無効になり、アプリが復元された
Windows起動後にsysteminfoを確認すると、今度は「仮想化ベースのセキュリティ: 状態: 無効」に変わっていた。「ハイパーバイザーが検出されました」という表示も消えていた。
そこで、アプリを開いた状態で休止し、電源が切れた後、物理電源ボタンで復帰を試した。
ここで初めて、休止前に開いていたアプリがそのまま復元された。 普通に起動し直す状態から、作業を続けられる状態へ戻った。
ファイル容量やBIOSを変えても直らなかった症状が、この操作の後に改善した。結果が変わったのは確かだが、ツールは複数の設定を変更しているため、Opt-outの承認だけが効いたのかまでは切り分けられていない。
メモリ整合性をONに戻しても、休止復帰は成功
復帰できたからといって、メモリ整合性をOFFのままにするのは避けたい。Windows セキュリティからONへ戻し、再起動した。
メモリ整合性のスイッチはONになっている。さらにsysteminfoでは、VBSが再び実行中になり、構成済み・実行中のサービスに「ハイパーバイザーによるコードの整合性の強制」が表示された。これはHVCI、つまりメモリ整合性に対応する。
仮想化ベースのセキュリティ: 状態: 実行中
Services Running:
ハイパーバイザーによるコードの整合性の強制
ハイパーバイザーが検出されました上記は、IPアドレスやユーザー名を含む実画面から必要な項目だけを転記したもの。VBSの「実行中」、Services Runningのコード整合性、ハイパーバイザー検出を確認できた。この状態でも、休止前のアプリを復元して正常に復帰できた。
つまり、今回の結果を「VBSが動いていると休止復帰できない」「メモリ整合性をOFFにすれば直る」とまとめるのは正確ではない。
また、メモリ整合性のONとCredential Guardの再有効化は別の話だ。今回の最終画面で確認できるのはHVCIの実行であり、Credential Guardまで元の保護状態へ戻ったとは言えない。休止復帰の改善と、すべてのセキュリティ設定の復元を混同しないようにしたい。
今回分かったことと、同じ症状で確認したい順番
このPCでは、休止ファイルの再作成・容量拡大、高速スタートアップの変更、BIOS更新、メモリ整合性のOFFでは改善しなかった。DG Readiness Toolを実行し、起動時にCredential Guardの無効化を承認した後、休止復帰が成功した。
Credential GuardやDevice Guard周辺の設定変更が改善に関係した可能性はある。ただし、「内部状態がリセットされた」「Credential Guardが原因だった」というところまで裏付ける検証はできていない。同じ0xC0000411でも、別のPCで同じ対処が有効とは限らない。
同じようにアプリが戻らない場合は、まず本当に休止復帰が失敗しているのか、失敗時刻のイベントログには何があるのかを確認する。そのうえで、設定を一つずつ記録し、再起動後の実際の稼働状態と復帰結果を比べるのがよさそうだ。いきなり保護機能をまとめて無効化するより、何が変わったのか追える形で進めたい。
今回使った中古PCのWindows 11導入については、別の記事にまとめている。
休止からWindows自体は戻れるものの、GHUBだけが動かない場合は、今回とは症状が異なる。そのケースで試した対処はこちら。
今回は、メモリ整合性をONへ戻した状態でもアプリが復元されるところまで確認できた。休止後に作業を続けられるようになったことが、今回の一番大きな変化だった。
MoonlightとVDDをAIで快適化｜非プログラマーがWindows用モニター切替ツールを作るまで
Alexaで自作PCが起動しない原因｜MSI BIOSのWOL設定で解決した実体験
Amazonセールで今の俺が本気で欲しいもの13選｜今使っている物から考えた
SwitchBotをWindowsタスクバーにまとめてみた｜1つのアイコンから照明・カーテン・換気扇を操作