博士

ロボ子、また面白いトラブルシューティング事例を見つけたのじゃ！Windowsマシンで自動ロックが効かなくなる問題らしいぞ。

ロボ子

自動ロックが効かないとは、セキュリティ上もバッテリーの持ちにも影響が出ますね。一体何が原因だったのでしょう？

博士

原因は特定のプログラムがバックグラウンドで動いていることだったみたいじゃ。しかも、そのプログラムがCEF（Chromium Embedded Framework）を使っていたのがミソじゃな。

ロボ子

CEFですか。Webコンテンツを組み込む際に使われるフレームワークですね。それがどう影響するのでしょう？

博士

どうやら、新機能のオンボーディングダイアログ（動画付き！）が悪さをしていたみたいじゃ。ダイアログが閉じられたように見えても、実際には非表示になっているだけで、ウィンドウが残っていたらしい。

ロボ子

ウィンドウが残存していると、自動ロックを妨げるような処理が動いているのでしょうか？

博士

その通り！記事によると、`PowerCreateRequest`と`PowerSetRequest`という関数が呼ばれて、PCがスリープ状態にならないように要求を出していたみたいじゃ。

ロボ子

`PowerCreateRequest`と`PowerSetRequest`ですか。初めて聞きました。具体的にどのようなAPIなのでしょう？

博士

これらの関数は、システムに対して「画面をオンにしておいてくれ」とか「スリープさせないでくれ」というリクエストを出すために使われるのじゃ。オンボーディングダイアログが裏でこっそりリクエストを出し続けていた、というわけ。

ロボ子

なるほど。それで、解決策はダイアログを完全に閉じるように修正したのですね。

博士

その通りじゃ！オンボーディング機能を担当するチームが頑張って、ダイアログが完全に閉じるように修正したらしいぞ。一件落着じゃ！

ロボ子

原因特定も興味深いですね。`powercfg /requests`コマンドやWDKの`pwrtest.exe`、ETWを使った詳細な電源管理データの取得など、色々な診断ツールが紹介されていますね。

博士

`powercfg /requests`は、今どんなプログラムが電源を要求しているか一目でわかるから便利じゃな。まるで、PCの電力事情を覗き見しているみたいじゃ！

ロボ子

確かにそうですね。私も今度使ってみます。しかし、ダイアログが閉じているように見えても裏で動いているとは、なかなか気づきにくいですね。

博士

そうなんじゃ。こういう見えないところで動いているプロセスを見つけるには、今回紹介されていたETW（Event Tracing for Windows）のようなツールが役に立つぞ。ETWを使えば、プログラムの動きを詳細に記録して、後からじっくり分析できるんじゃ。

ロボ子

ETWですか。使いこなすには少しハードルが高そうですが、覚えておくと役立ちそうですね。

博士

まあ、ETWは上級者向けじゃから、最初は`powercfg /requests`あたりから試してみるのがオススメじゃな。ところでロボ子、お腹空いたのじゃ。何か食べるものないかの？

ロボ子

またですか、博士。さっきおやつを食べたばかりでしょう？

博士

むむ、仕方ないのじゃ。しかし、この自動ロック問題、まるで私が隠れておやつを食べているのを監視されているみたいじゃな！