Windows 10 1703にて、2018-04-18にいくつかのセキュリティアップデートを適用したら、勝手にWindowsの休止状態 (hibernation) が解除されて復帰する（PC電源が勝手に入る）問題が多発するようになりました。休止状態はメモリ内容をストレージに保存してPC電源を落とすので、スリープよりも復帰に時間がかかりますが、休止中に停電が発生しても復帰ができるというメリットがあるので、就寝前にいつも使っています。
以前、休止状態の解除が頻発して困っていたときに、キーボードやマウス、ネットワークアダプターが原因かもしれないと思って、デバイスマネージャーにて[このデバイスで、コンピューターのスタンバイ状態を解除できるようにする]のチェックをすべて外していたので、これらのデバイスが原因である可能性は最初から除外しました。
まず、コマンドプロンプトを管理者権限で起動*1し、powercfg コマンドで前回の復帰の理由を調べます。
Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.
C:\WINDOWS\system32>powercfg -lastwake
スリープ状態の解除履歴カウント - 1
スリープ状態の解除履歴 [0]
スリープ状態の解除元カウント - 1
スリープ状態の解除元 [0]
種類: スリープ解除タイマー
所有者: [SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker)
所有者によって示された理由:イベントビューアーのシステムログで「Power-Troubleshooter」を検索すると、以下のレコードが2018-04-20 05:35:00 (JST) に記録されていました。
システムは低電力状態から再開しました。 スリープ時間: 2018-04-19T16:44:22.759254000Z スリープ解除時間: 2018-04-19T20:34:53.450160600Z スリープ状態の解除元: タイマー - svchost.exe
「スリープ解除タイマー」とは何者でしょうか？ 調べてみると電源オプションで無効化できるそうです。
[コントロール パネル] > [ハードウェアとサウンド] > [電源オプション]にて、現在選択されている電源プランの[プラン設定の変更] > [詳細な電源設定の変更]をクリック。
[電源オプション]ダイアログで、[スリープ] - [スリープ解除タイマーの許可]が[有効]になっていました。コイツを[無効]に変更して[OK]または[適用]ボタンをクリック。
これで一安心……と思いきや、やはり休止状態が勝手に解除されてしまいました。
もう一度powercfgとイベントビューアーで調べます。
Microsoft Windows [Version 10.0.15063] (c) 2017 Microsoft Corporation. All rights reserved. C:\WINDOWS\system32>powercfg -lastwake スリープ状態の解除履歴カウント - 1 スリープ状態の解除履歴 [0] スリープ状態の解除元カウント - 0
イベントログには2018-04-21 04:38:25 (JST) に記録があります。
システムは低電力状態から再開しました。 スリープ時間: 2018-04-20T17:57:22.602822200Z スリープ解除時間: 2018-04-20T19:38:20.464928200Z スリープ状態の解除元: 不明
はい原因不明でした。
UpdateOrchestratorタスクグループ
タスクスケジューラで確認したところ、UpdateOrchestratorのRebootタスクが指定日時をトリガーとして登録されていました。
UpdateOrchestratorはWindows Updateに関わるタスクグループらしく、スリープや休止状態の勝手な解除を発生させる諸悪の根源です。UpdateOrchestratorを組み込んだMSのエンジニアは、本当に頭のおかしいキチガイでしょう。Windows 8.1からWindows 10に更新した後、しょっちゅうコイツに悩まされていましたが、ここ最近は小康状態だったので油断していました。1703でWindows Updateによる再起動前のリマインダーや、更新の一時停止（最大35日間）をできる機能が追加されたので、再起動の回数自体も減っていました。
ひとまずRebootタスクの[条件]にて、[タスクを実行するためにスリープを解除する]のチェックを外しておきましたが、次回のWindows Update後にはまた勝手に復活していることでしょう。なお、1709ではこの設定がUIから変更できなくなっているそうです。ユーザーにさらなる不自由を強いるとは許せませんね*2。
しかし、UpdateOrchestratorのRebootタスクを修正しても、やはり休止状態が勝手に解除されてしまいました。解除元は相変わらず不明です。
WindowsUpdateタスクグループ
WindowsUpdateのAutomatic App Updateタスク*3およびScheduled Startタスクを修正すると改善されるとの情報あり。前者は4時間ごとに無期限に繰り返すよう設定されていました。後者は指定日時をトリガーとして登録されていました。
しかし、[タスクを実行するためにスリープを解除する]はともにチェックが外れていました。
ほかに、AUSessionConnectというタスクも登録されており、これは[タスクを実行するためにスリープを解除する]にチェックが入っていました。
ひとまずAutomatic App UpdateタスクとAUSessionConnectタスクを無効化しておきました。Scheduled Startタスクは無効化しても、一定時間経つと勝手に有効化されるようです。なお、AUSessionConnectは[タスクを実行するためにスリープを解除する]のチェックを外して[OK]をクリックしても、なぜか以下のようなメッセージが表示されて、変更を反映できません。
--------------------------- タスク スケジューラ --------------------------- タスク スケジューラ サービスが利用できません。タスク スケジューラはサービスへの再接続を試行します。 --------------------------- OK ---------------------------
しかし、Automatic App UpdateタスクとAUSessionConnectタスクを修正・無効化しても、やはり休止状態が勝手に解除されてしまいました。解除元は相変わらず不明です。
powercfgコマンドを使って、スリープ解除元のデバイスとタイマーを列挙してみます。
Microsoft Windows [Version 10.0.15063] (c) 2017 Microsoft Corporation. All rights reserved. C:\WINDOWS\system32>powercfg -devicequery wake_armed NONE C:\WINDOWS\system32>powercfg -waketimers [SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 04:33:06 (2018-04-24) で有効期限が切れます。 理由:
デバイスは案の定存在しませんでしたが、タイマーが存在するようです。しかし「理由」が分からないのでタスクの特定ができません。
Windowsのタスクキャッシュ
Windowsの各タスクの設定情報自体は "%WinDir%/System32/Tasks" 配下にXMLファイル（拡張子は無し）の形で保存されていますが、レジストリ "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache" 上にもバイナリキャッシュが保存されているようです。またキャッシュのほうが優先されるらしく、XMLファイルを直接編集＆保存してWindowsを再起動しても変更内容が反映されません。タスクスケジューラのUIによる変更を確定しようとしたときにエラーとなるのは、おそらくキャッシュが破損しているからではないかと推測されます（4月のWindows Updateで破損した？）。しかしレジストリエディターでキャッシュを削除しようとしても、タスクスケジューラのサービスによってロックされているらしく、削除操作が拒否されます。また、タスクスケジューラのサービスはユーザーが停止させることができません。
セーフモードで起動してキャッシュを消そうかとも考えましたが、いい加減疲れたので、休止状態の勝手な復帰現象の原因追及はひとまずここまでとします。結局、休止状態にした後はPC電源スイッチを切る（｜→○）という原始的な方法で対処することにしました。電源スイッチのあるオーソドックスな自作デスクトップ機でよかった。
もう少し追跡してみます。Tasksフォルダー配下のすべてのファイルを対象に、
<WakeToRun>true</WakeToRun>
をグローバル検索してみたところ、前述のAUSessionConnect以外にいくつか引っかかりました。
- Microsoft\Windows\.NET Framework\.NET Framework NGEN v4.0.30319 64 Critical
- Microsoft\Windows\.NET Framework\.NET Framework NGEN v4.0.30319 Critical
- Microsoft\Windows\rempl\shell
- Microsoft\Windows\SharedPC\Account Cleanup
- Microsoft\Windows\UpdateOrchestrator\AC Power Download
- Microsoft\Windows\UpdateOrchestrator\Combined Scan Download
- Microsoft\Windows\UpdateOrchestrator\UpdateAssistantWakeupRun
このうち、rempl\shell と UpdateOrchestrator\AC Power Download はタスクが有効（準備完了）になっていたので、前者は[タスクを実行するためにスリープを解除する]のチェックを外し、後者は無効化しました。それ以外はすでに無効になっているので放置することにします。
Microsoft Windows [Version 10.0.15063] (c) 2017 Microsoft Corporation. All rights reserved. C:\WINDOWS\system32>powercfg -waketimers システムにアクティブなスリープ解除タイマーがありません。
ようやくタイマーがなくなりました。ひとまずこれで様子見とします。
グラフィックスドライバーの勝手な更新
休止状態の解除問題とは直接の関係はありませんが、Windows Updateの履歴を見ると、2018-01-21に、NVIDIA GeForceドライバーが384.94から388.13に許可なく勝手に更新されていました。グラフィックスドライバーは特に相性問題を起こしやすく、たいていのパワーユーザーはドライバーの更新に慎重になるのですが、これが勝手に更新されるとなるとかなり困ります。以前はデバイスドライバーの更新に関してはオプショナル（任意）だったはずなのですが……
ひとまずグループポリシーでデバイスドライバーの更新を無効化する（[Windows Updateからドライバーを除外する]を[有効]に構成する）ことで対処しました。
Windows 10更新アシスタントの無限復活
3月頃には「Windows 10更新アシスタント」が勝手にインストールされて、1709のダウンロードが始まる事案が発生しました。更新アシスタントはコントロールパネルで削除しても無限に復活する、まさにゾンビのように厄介なアプリです。グループポリシーでは無効化できず、以下のサイトを参考にしてようやく抑制できました。
www.atmarkit.co.jp
MSはどうしても1709の導入ベースを増やしたがっているようですが、だからといってユーザーの許可なく勝手にアプリをインストールするなんて破廉恥極まりないですね。年2回の大型アップデートスケジュールも、無理やりスケジュールを守ろうとして品質の確保ができなくなってしまっているのが目に見えています。機能追加のためのアップデートとスケジュールではなく、スケジュール遵守のための無理な機能開発になってしまっていて、目的と手段が完全に入れ替わってしまっていますね。お粗末としか言いようがないです。そもそも大型アップデートにより追加あるいは削除される機能のうち、大半は誰も望んでいない変更です。しかも新機能はことごとくオプトアウトなのも始末が悪いです（余計な機能がデフォルトで有効化されていて、無効化するためにはユーザーがいちいち設定を変更しなければならない）。
Windows 10はユーザーの自由と時間と情報と安眠と電気代を奪っている
Windows 8.1までは良くも悪くもエンドユーザーがWindows Updateのタイミングと内容を完全にコントロールすることができていました。翻ってWindows 10では、ユーザーにほとんど自由がありません。せっかく設定を変更して抑制しても、Windows Updateを適用すると（MSにとって都合のいいように）設定が毎回リセットされてしまいます。ましてや、余計な機能てんこ盛りで品質の低い大型アップデートを勝手にインストールして、ユーザーのシステムを台無しにするなんて、犯罪にも等しいです。また、MSは個人情報収集のためには手段を選びません。なりふり構わずあの手この手を使ってきます。知識がないライトユーザーは簡単に騙されて大量に個人情報をぶっこ抜かれてしまうでしょう。こういう汚いことを続けていれば、どんどんパワーユーザーが離れていくということにMSは気付かないんでしょうか。本当に過去最悪のOSです。Windows 10の汚らしい挙動と、MSの下品なゴリ押しのせいで、Direct3D 12*4もUWPも開発に使う気がすっかり消え失せました。開発環境としてずっと慣れ親しんできたWindowsですが、もうウンザリです。もはやWindowsプラットフォーム固有の開発には積極的に投資したくありません。
今のところゲームやクリエイティブツールの関係上、どうしてもWindowsを使わざるを得ない状況ですが、今後Wineの完成度が上がればいずれWindowsを捨ててLinuxに移行したいですね。ソフト電池のような認証ツールもWine環境に対応してくれたらいいのですが。
※2018-06-03追記：
5月度のWindows Updateを実行すると、案の定またスリープ解除タイマーが復活しました。例のごとくタスクのXMLファイル群をグローバル検索してみると、
というタスクが有効かつWakeToRunがtrueになっていたので、[タスクを実行するためにスリープを解除する]のチェックを外しておきました。
※2018-07-16追記：
6月度のWindows Updateを実行すると、以下のタスクが有効かつWakeToRunがtrueになっていたので、[タスクを実行するためにスリープを解除する]のチェックを外しておきました。Windows Updateのたびにスリープ解除タイマーを復活させやがることが分かったので、そろそろ無効化作業を自動化したいですね。
- Microsoft\Windows\.NET Framework\.NET Framework NGEN v4.0.30319 64 Critical
- Microsoft\Windows\.NET Framework\.NET Framework NGEN v4.0.30319 Critical
- Microsoft\Windows\rempl\shell
- Microsoft\Windows\rempl\shell-maintenance
※2018-08-14追記：
7月度のWindows Updateを実行してみたところ、今回はスリープ解除タイマーを復活させていないようです。
※2018-09-17追記：
8月度のWindows Updateを実行してみたところ、今回はスリープ解除タイマーを復活させていないようです。
※2018-09-25追記：
1703のサポート期限が迫ってきたため1803に更新したところ、以下のタスクが有効かつWakeToRunがtrueになっていたので対処。
- Microsoft\Windows\.NET Framework\.NET Framework NGEN v4.0.30319 64 Critical
- Microsoft\Windows\.NET Framework\.NET Framework NGEN v4.0.30319 Critical
- Microsoft\Windows\UpdateOrchestrator\Schedule Retry Scan
しかし、UpdateOrchestrator\Schedule Retry Scanに関してはタスクスケジューラのUIから[タスクを実行するためにスリープを解除する]をアンチェックもしくは無効化しようとすると、権限がないと言われてしまいます。以下を参考に、管理者権限で psexec を使うことでタスクを無効化できました。
ykw-note.hatenablog.com
C:\Users\XXX\PSTools>psexec -s -accepteula -nobanner schtasks /Change /TN "\Microsoft\Windows\UpdateOrchestrator\Schedule Retry Scan" /DISABLE 成功: スケジュール タスク "\Microsoft\Windows\UpdateOrchestrator\Schedule Retry Scan" のパラメーターは変更されました。 schtasks exited on <PCName> with error code 0.
※2019-03-03追記：
2019年1月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。
今回は以下のタスクが有効かつWakeToRunがtrueになっていました。
しかし、タスクスケジューラのUIから[タスクを実行するためにスリープを解除する]をアンチェックもしくは無効化しようとすると、
「タスク スケジューラ サービスが利用できません。タスク スケジューラはサービスへの再接続を試行します。」と言われてしまいます。
以前のようにpsexecで対処しました。
C:\Users\XXX\PSTools>psexec -s -accepteula -nobanner schtasks /Change /TN "\Microsoft\Windows\UpdateOrchestrator\AC Power Download" /DISABLE
ちなみに UpdateOrchestrator\Schedule Retry Scan は UpdateOrchestrator\Schedule Scan に改名(？)されたようです。
※2019-04-24追記：
2019年3月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。
今度は UpdateOrchestrator\AC Power Download が消えて、UpdateOrchestrator\Schedule Retry Scan が復活していました。
[SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 01:45:38 (2019-05-08) で有効期限が切れます。 理由: Windows は、スリープ状態の解除を要求したスケジュールされたタスク 'NT TASK\Microsoft\Windows\UpdateOrchestrator\Schedule Retry Scan' を実行します。
※2019-06-22追記：
2019年5月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。
今度は UpdateOrchestrator\Schedule Retry Scan が消えて、UpdateOrchestrator\AC Power Download が復活していました。
[PROCESS] \Device\HarddiskVolume2\Windows\SystemApps\ShellExperienceHost_*\ShellExperienceHost.exe によって設定されたタイマーは 00:00:00 () で有効期限が切れます。
※2019-09-12追記：
2019年7月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。
今度は UpdateOrchestrator\AC Power Download が消えて、UpdateOrchestrator\Schedule Retry Scan と UpdateOrchestrator\Schedule Scan が復活していました。
しかし、これらのタスクをpsexecで無効化しても、依然としてタイマーが残っています。他にWakeToRunがtrueになっている有効なタスクは見つかりません。
※2020-09-03追記：
2020年7月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。
[PROCESS] \Device\HarddiskVolume2\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_*\StartMenuExperienceHost.exe によって設定されたタイマーは 00:00:00 () で有効期限が切れます。 [SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 01:39:49 (2020-09-17) で有効期限が切れます。 理由: Windows は、スリープ状態の解除を要求したスケジュールされたタスク 'NT TASK\Microsoft\Windows\UpdateOrchestrator\Backup Scan' を実行します。
StartMenuExperienceHost.exe はスタートメニュー専用のホストプロセスらしいです。Windows 10 1903にてエクスプローラーから分離されたとのこと。
とりあえず UpdateOrchestrator\Backup Scan のほうをpsexecで無効化して様子見。
C:\Users\XXX\PSTools>psexec -s -accepteula -nobanner schtasks /Change /TN "\Microsoft\Windows\UpdateOrchestrator\Backup Scan" /DISABLE
※2020-09-30追記：
いつのまにかスリープ解除タイマーが復活しました。
[SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 07:59:29 (2020-09-30) で有効期限が切れます。 理由: Windows は、スリープ状態の解除を要求したスケジュールされたタスク 'NT TASK\Microsoft\Windows\UpdateOrchestrator\Universal Orchestrator Start' を実行します。 [PROCESS] \Device\HarddiskVolume2\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_*\StartMenuExperienceHost.exe によって設定されたタイマーは 07:59:29 (2020-09-30) で有効期限が切れます。
とりあえず UpdateOrchestrator\Universal Orchestrator Start のほうをpsexecで無効化して様子見。
※2021-10-23追記：
Windows 10 21H1にて、久々にスリープ解除タイマーが復活しました。しかし原因はWindows Updateではなく、StartMenuExperienceHost.exe のようでした。
[PROCESS] \Device\HarddiskVolume2\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_*\StartMenuExperienceHost.exe によって設定されたタイマーは xxx (yyy) で有効期限が切れます。
xxx と yyy の部分はそれぞれ時刻と日付のはずですが、文字化けして変なデータが表示されています。2019年12月末頃に現象が発生していた環境もあるみたいですね。このタイマーはライブタイル (Live Tiles) の通知と関連があるようです。
グループポリシーエディターでライブタイルの通知を無効化し、OSを再起動することでタイマーがなくなりました。
以前Windows 10ではライブタイルが廃止されるとかいう噂が出ていましたが、Windows 10では一応残るものの、Windows 11では本当に廃止されたみたいですね。自分は天気アプリのライブタイルくらいしか活用していませんでした。スタートメニューの項目がちらちら変化すると視界に入って鬱陶しいんです。ニュースアプリのライブタイルとかも気が散るのでオフにしていました。モバイルとデスクトップは作法が全然違うことを理解していない企業が多すぎます。MSとかMozillaにはバカの一つ覚えの無能デザイナーしかいないんでしょうか。
※2022-02-22追記：
また本日も休止状態が勝手に解除されました。しかしpowercfgコマンドで調べても、タイマーは存在していません。
ふとデバイスマネージャーでキーボードやポインティングデバイスの電源管理プロパティを調べてみようと思ったところ、なぜか「HID キーボード デバイス」が2つ、「HID 準拠マウス」が2つリストアップされています。片方はスタンバイ解除オプションのチェックが入った状態、片方はチェックが外れた状態になっていました。気持ち悪いのでとりあえずチェックは外しておく。
イベントログには2022-02-22 03:57:57 (JST) に記録がありましたが、相変わらず原因不明で役に立ちません。
システムは低電力状態から再開しました。 スリープ時間: 2022-02-20T20:35:12.506912200Z スリープ解除時間: 2022-02-21T18:57:47.737867700Z スリープ状態の解除元: 不明
まあ実際の原因は十中八九Windows Update (UpdateOrchestrator) の監視タイマーだと思います。謎のシグナルを受けて深夜に勝手に再開するクソOS。本当にMSの開発者は首を吊って死ねばいいのに。
以下を参考に、グループポリシーで「Windows Update の電源管理を有効にして、システムのスリープ状態が自動的に解除され、スケジュールされた更新がインストールされるようにする」を無効化しました。ひとまず様子見とします。
itojisan.xyz
*1:余談ですが、最初のカレントディレクトリは通常権限だと「%UserProfile%」で起動する一方、管理者権限だと「%SystemRoot%\System32」で起動しますね。
*2:MSが運営している各種フォーラムには、こういった明らかにユーザーに不利益を強いているMSの姿勢すら擁護する大量のマゾ信者がグルとして涌いていて、本当に気持ち悪いです。
*3:Windowsストアアプリを自動更新するためのタスクらしいです。ところでストアアプリなんていう不自由なもの、誰が好き好んで使うんですか？
*4:Direct3DとHLSLの進化が停滞すると競合のOpenGL/VulkanとGLSLも停滞することが予想されるので、Direct3Dの更新自体は続けて欲しいのですが、個人的には今後プラットフォーム独自仕様のDirect3D/MetalよりもクロスプラットフォームなVulkanのほうが普及率が高くなり、API統一が進むのではないかと（期待を込めて）予想しています。
