手元のWindows 10なDellのラップトップが 指定時間を超えてもスリープに入らなくなったのでちょっと対処した話。
Windowsでスリープに入らない問題
以前、Windows 7を使ってる時にスリープに入らなくなって 対処したした話を書きました。
この時は原因はTeamViewerのサービスが原因でした。
今回のラップトップでもTeamViewerを使っていますが 今回のはそれとは違う原因でした。
電源関連のレポートを作る
上のポストでも書きましたが、
Windowsではpowercfgというコマンドを使って
電源関連のレポートを作ることが出来ます。
PowerShell(もしくはコマンドプロンプト)を管理者として実行して、
PS C:\WINDOWS\system32> powercfg -energy
を実行します。
管理者として実行するとC:\Windows\System32のフォルダで開始します。 デフォルトでは今いるフォルダにファイルを作るので、 上のコマンドを実行すると、 C:/Windows/System32/energy-report.htmlというファイルが出来ます。
ファイルの場所や名前を変更したい場合は-outputオプションを使って
ファイル名を指定します。
取り敢えずこれを作ってみてみると、エラーが幾つか出てきましたが、
システムの利用可能性の要求:システムが必要な要求
デバイスまたはドライバーによって、システムが自動的にスリープ状態にならないようにする要求が行われました。
要求しているドライバー インスタンス HDAUDIO\FUNC_01&VEN_14F1&DEV_50F2&SUBSYS_102806FD&REV_1001\4&2077de27&0&0001
要求しているドライバー デバイス Conexant SmartAudio HD
というものと、
USB 中断:USB デバイスはセレクティブ サスペンドになっていません
このデバイスはセレクティブ サスペンド状態になりませんでした。この USB デバイスがセレクティブ サスペンド状態でないときには、プロセッサの電源管理が行われないことがあります。このことによって、システムのスリープが妨げられることはありません。
というUSB関連のものが2つ、 あと、
CPU 使用率:プロセッサ使用率は高レベルです
トレース中の平均的なプロセッサ使用率は高レベルでした。平均プロセッサ使用率が非常に低い場合、システムの消費電力は少なくなります。個々のプロセスのプロセッサ使用率を確認し、合計プロセッサ使用率に最も影響しているアプリケーションおよびサービスを判断してください。
平均使用率 (%) 12.35
と、
プラットフォーム電源管理機能:PCI Express Active-State Power Management (ASPM) が無効です
このコンピューターのハードウェアとの既知の非互換性のため、PCI Express Active-State Power Management (ASPM) は無効になっています。
と言った感じ。
CPUはは12%で高レベルな使用率と言われてしまうとどうしようもありませんが、 取り敢えずスリープには関係ありません。 (もちろん何かがずっと動いていて妨げる可能性はありますが、 Firefoxなど起動してるだけで割りとCPU使うので(何をしているのか。。。)直接スリープには関係ありません。)
最後のはもともと該当機能にハードウェアが対応してないというだけなので 関係なし。
なので問題は最初のドライバーのものとUSBのもの。
試しにUSB接続を全てはずしてみましたが、レポートでのエラーは消えましたが スリープにはやはり入りませんでした。
なので問題はConexant SmartAudio HDにありそう。
lastwakeを見てみる
powercfgには-lastwakeとうオプションがあり、
これを使うと最後にスリープから復帰した原因を調べる事が出来ます。
TeamViewerが原因の時はこれで見つけました。
試しにやってみると、
PS C:\WINDOWS\system32> powercfg -lastwake
スリープ状態の解除履歴カウント - 1
スリープ状態の解除履歴 [0]
スリープ状態の解除元カウント - 1
スリープ状態の解除元 [0]
種類: 固定機能
電源ボタン
と言った感じで電源ボタンを押して起動したとあります。 普通に起動した時の作業です。
以前の問題は一度はスリープには入るものの、TeamViewerによって勝手に スリープが解除される、というものだったのでこれで分かったんですが、 今回の問題は、スリープそのものに入らない、という問題なのでこれではわからなそうです。
requestsを見てみる
powercfgの他のオプションで、-requestsというものがあります。
これは電源関連に何らかの要求をしているアプリやドライバーがあるかどうか 調べるコマンドです。
やってみると、
PS C:\WINDOWS\system32> powercfg -requests
DISPLAY:
なし。
SYSTEM:
[DRIVER] Conexant SmartAudio HD (HDAUDIO\FUNC_01&VEN_14F1&DEV_50F2&SUBSYS_102806FD&REV_1001\4&2077de27&0&0001)
現在 1 つのオーディオ ストリームが使用中です。
AWAYMODE:
なし。
実行:
なし。
PERFBOOST:
なし。
ACTIVELOCKSCREEN:
なし。
こんな感じ。DISPLAYの項目はディスプレイの電源を切るのを妨げる要求をしているもの、 SYSTEMがスリープなど電源関連の作業を妨げる要求をしているものです。
ここでやはり上にも出てきたConexant SmartAudio HDがSYSTEMに要求しています。
これは手元のDellの内蔵マイク/スピーカーのドライバーです。 これをなんとかしないといけない模様。
対処法(requestsoverride)
この内蔵マイク/スピーカーが問題になる原因として、 サウンドのプロパティーから録音該当のデバイスのプロパティ にある聴くというタブで このデバイスを聴くにチェックが入っているとスリープを妨げる問題が起こる、 といったのを見つけましたが、自分の環境ではこれにチェックが入っていませんでした。
[Windows 7で自動でスリープ状態にならない問題を解決(電子証明書の期限切れ、オーディオデバイス) Like The Wind - Blog](https://likemid.wordpress.com/2012/08/22/windows-7-powercfg-srvnet-certification/)
なのでこのデバイスを削除するかなんとか要求を無視しないといけないわけですが、 デバイス自体は内蔵スピーカーなので削除することは出来ません。
一方、再びpowercfgを使うとこの要求を無視できる様になります。
-requestsoverrideというオプションを使い、うえで出てきたドライバー名を使って
PS C:\WINDOWS\system32> powercfg -requestsoverride DRIVER "Conexant SmartAudio HD" SYSTEM
を実行します。
引数は<呼び出し元の種類>、<名前>、<要求>の順です。
今回はドライバーなのでDRIVERを指定し、名前を入れ、
最後にSYSTEMに対する要求なのでこれを書きます。
requestsoverrideという名前が微妙で、説明も、
PS C:\WINDOWS\system32> .\powercfg.exe -requestsoverride /?
POWERCFG /REQUESTSOVERRIDE [<CALLER_TYPE> <名前> <要求>]
説明:
特定のプロセス、サービス、またはドライバーに対する電源要求の優先を設定します。
パラメーターを指定しないと、現在の電源要求の優先設定の
一覧が表示されます。
パラメーター一覧:
<呼び出し元の種類> 次のいずれかの呼び出し元の種類を指定します: PROCESS、
SERVICE、DRIVER。この取得には
"POWERCFG /REQUESTS" コマンドを呼び出します。
<名前> 呼び出し元の名前を指定します。この名前を返すには、
"POWERCFG /REQUESTS" コマンドを呼び出します。
<要求> 次の電源要求の種類を 1 つ以上指定します:
DISPLAY、SYSTEM、AWAYMODE。
例:
POWERCFG /REQUESTSOVERRIDE PROCESS wmplayer.exe DISPLAY SYSTEM
こんな感じなので設定すると必ず要求が通ってスリープが妨げられそうですが、 そうではなくて設定した項目からの要求よりも元の電源の要求を優先する?と言った感じの模様。
つまりは設定すればそのデバイスやアプリからの要求は無視してスリープしたりする、ということ。
この設定をしてスリープ時間まで待ってみるときちんとスリープしました。
ただし、最初の-energyによるレポートや-requestsによる項目には
まだこのConexant SmartAudio HDの項目は残ったままです。
(ドライバからの信号は出ているけど無視している状態、ということ。)
自分で設定したrequestsoverrideの設定を調べるためには引数なしに、
PS C:\WINDOWS\system32> .\powercfg.exe -requestsoverride
[SERVICE]
[PROCESS]
[DRIVER]
Conexant SmartAudio HD SYSTEM
とすれば見れます。
また、元に戻すには、最後の要求の種類を空白にして
PS C:\WINDOWS\system32> powercfg -requestsoverride DRIVER "Conexant SmartAudio HD"
としてあげれば削除できます。
まとめ
とうことで今回は内蔵スピーカーが問題でしたが、 探してみると同じようにスピーカーのドライバーが原因でスリープが妨げられてる人が結構いました。
もちろん、Dellの端末だけ、とうことではなく他の端末の人も居て その場合はもちろんドライバー名が違うものになります。
また、この問題はWindows 7や8でも起こっている模様(というか10のものは余り見つからない)。
(VistaやXPのものは見られませんでしたが、
powercfgの仕様が違うので調べられていないだけ、や同じような設定ができないだけで
見つからなかっただけかもしれません。）
なのでWindows側そのものに何らかの音源関係の問題がありそうです。
今回、そもそも最近まではこんな問題が起こってなかったですし、 このデバイスの変更はもちろん、ドライバーの更新も最近してないので いつからこうなったか、と考えていましたが、おそらく Bash on Ubuntu on Windowsを入れようと Windows Insider Preview版ビルドを入れてからかな、と言う感じがします。
まあ元に戻すのもなんなので今のところPpreview版を続けますが、 7や8で起こった問題が今回出始めたと言うことで その辺治した様なところを再び変更してしまったのかな？と。
取り敢えずInsider Preview版だしフィードバックを送ってみよう、ということで送っておきました。
フィードバックを送る際にちょっと迷ったのが、
更新プログラムとフィードバック - Microsoft Windows
にあるようにWindows フィードバックを検索しても何も出てこず、
フィードバックで検索するとフィードバック Hubというアプリが見つかって
ここからフィードバックを送ることが出来ました。
上のページにあるInsider Hubという機能も機能の追加へ行っても見つからず。
この辺Insider Preview版が結構変わっていてちょっと古いだけかも知れません。
(通常版ではまだWindows フィードバックがあるのかも。)
初めてフィードバックを送ってみましたが、他の人が送ったフィードバックも見ることが出来、 色々あって面白いです。 このサウンドに関する同じようなものはぱっと見つけられませんでしたが。 (ざっとスリープ、サウンドあたりで検索したところお同じようなものはみられませんでしたが たくさんあるので被ってしまっているかも知れません。)
また、特にbash関連でのフィードバックがいろいろあって面白いです。
色々と要求をしたいことはありますが、コンセプト的に自分が考えてるのと 方向が違いすぎるのでちょっと躊躇する所ではあります。。。