none
スリープ状態の解除元: 休止までの S4 スリープ RRS feed

  • Întrebare

  • Windows10 Home 64bit です。

    普段、PC不使用時(外出時や就寝時など)はスリープにしています。

    1903にしてからですが、スリープ中に電源のファンが突然回りHDDのアクセスランプが点くものの、画面が点いたりもせずに再びスリープになるというような症状が出るようになりました。

    イベントビューワーを確認すると、「スリープ状態の解除元:休止までのS4 スリープ」となっており、スリープ解除時間からスリープ時間が10秒もありません。解除とスリープが全く同時というような事もあります。

    症状が出るのも、1時間に1回程度の時もあれば、数分おきの時もあります。

    修復セットアップ(上書きインストール)したら発生しなくなりましたが、しばらくしたら再発しました。修復セットアップは何回かやってみましたが、同様の結果でした。また、再起動直後にスリープにすると発生頻度がぐっと下がります。

    何が原因か全くわからず困っています。解決へのアドバイスをいただきたく、よろしくお願いします。

    こんな情報を上げろ、とかあればご指示お願いします。

    vineri, 8 noiembrie 2019 11:08

Toate mesajele

  • とりあえず。。。。
    コマンド プロンプトから以下のコマンドを実行し、その出力結果をここにコピペしてみてください。

    powercfg /devicequery wake_programmable
    powercfg /devicequery wake_armed
    powercfg -waketimers


    luni, 11 noiembrie 2019 00:21
  • レスありがとうございます。

    これでよろしいでしょうか。

    Microsoft Windows [Version 10.0.18362.449]
    (c) 2019 Microsoft Corporation. All rights reserved.

    C:\WINDOWS\system32>powercfg /devicequery wake_programmable
    HID 準拠コンシューマー制御デバイス
    HID 準拠ベンダー定義デバイス
    Logicool HID-compliant Cordless Mouse (001)
    HID 準拠ベンダー定義デバイス (003)


    C:\WINDOWS\system32>powercfg /devicequery wake_armed
    Logicool HID-compliant Cordless Mouse (001)


    C:\WINDOWS\system32>powercfg -waketimers
    [SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 8:37:30 (2019/11/12) で有効期限が切れます。
      理由: Windows は、スリープ状態の解除を要求したスケジュールされたタスク 'NT TASK\Microsoft\Windows\UpdateOrchestrator\Universal Orchestrator Start' を実行します。

    C:\WINDOWS\system32>

    luni, 11 noiembrie 2019 11:29
  • > Logicool HID-compliant Cordless Mouse (001)

    これ↑が原因かも。
    とりあえず。。。。
    Device Manager を開いて、[ヒューマン インプット デバイス] か [マウスとそのほかのポインティング ディバイス] のどっちかの下に "Logicool HID-compliant Cordless Mouse" があるはずだから、右クリックでそれを「無効」にしてみてスリープ状態を確認してみてください。

    marți, 12 noiembrie 2019 00:52
  • ありがとうございます。

    [マウスとそのほかのポインティング ディバイス]にありました。

    これから、やらないとならないことをやってから、無効にして確認してみます。

    結果をお伝えするまで少し時間をください。


    marți, 12 noiembrie 2019 10:15
  • "Logicool HID-compliant Cordless Mouse"を無効にして一晩、問題の症状は発生しませんでした。

    また、今日の日中、マウス本体のスイッチをオフにしてスリープにしておいたところ、やはり問題の症状は発生しませんでした。

    お馬鹿様のおっしゃるとおりだったようです。マウスを別の物に変えることにします。

    大変スッキリしました。ありがとうございました。

    miercuri, 13 noiembrie 2019 09:20
  • "Cordless Mouse" ってことは、電池が必要なんですよね?

    "Cordless Mouse" が原因といっても、その根本要因は色々考えられる。

    例えば「電池切れ」とか「ドライバが古い」とか「他の 3rd ベンダー製フィルタ ドライバの影響」とか、「マウス デバイスが壊れてる」とか。

    「マウスを別の物に変える」んぢゃなくって、もっと根本原因を調べた方がいいと思います。

    miercuri, 13 noiembrie 2019 09:38
  • 確かにおっしゃるとおりです。お馬鹿様の助言のおかげで、マウスか!となった訳ですが、症状が発生しなかったのはたった1日ですのでもう少し様子を見ないといけませんね。

    「他の 3rd ベンダー製フィルタ ドライバの影響」については手に負えなそうではあります。

    ドライバは最新になっているので問題はないと思いますが、最近は更新されていなかったと思います。

    以前(半年くらい前)、マウスのチャタリングが発生したためマイクロスイッチを自分で交換した事があるので、その影響があるのかな、とかも思いました。

    お気に入りのマウスなので、同じ物を入手して入れ替えてみたり、マウスそのものや電池を変えたりしながらしばらく様子を見てみたいと思います。

    またお世話になるかもしれませんが、その節はよろしくお願いします。

    miercuri, 13 noiembrie 2019 10:58
  • 早々と戻ってきてしまいました。

    マウスを有線の一番シンプルなタイプと交換し、問題のマウスのドライバ、ユーティリティソフトをアンインストールした状態で、症状が再発してしまいました。

    この間、Win10 1903の累積更新プログラムKB4524570と、Officeのセキュリティ更新プログラムKB4484127がインストールされています。

    前にご指示いただいたコマンドの結果は次のとおりです。

    Microsoft Windows [Version 10.0.18362.476]
    (c) 2019 Microsoft Corporation. All rights reserved.

    C:\WINDOWS\system32>powercfg /devicequery wake_programmable
    HID 準拠マウス (001)


    C:\WINDOWS\system32>powercfg /devicequery wake_armed
    HID 準拠マウス (001)


    C:\WINDOWS\system32>powercfg -waketimers
    [SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 8:59:30 (2019/11/18) で有効期限が切れます。
      理由: Windows は、スリープ状態の解除を要求したスケジュールされたタスク 'NT TASK\Microsoft\Windows\UpdateOrchestrator\Universal Orchestrator Start' を実行しま す。

    C:\WINDOWS\system32>

    よろしくお願いします。





    duminică, 17 noiembrie 2019 05:41
  • デバイス マネージャから、[ヒューマン インプット デバイス] と [マウスとそのほかのポインティング ディバイス] ノードの配下にある各デバイスのプロパティを開き、「ドライバー」タブの「ドライバーの詳細」ボタンを押下し、「ドライバー ファイルの詳細」でリストされるファイル一覧を教えてください。
    luni, 18 noiembrie 2019 00:21
  • レスをいただきありがとうございます。
    [ヒューマン インプット デバイス]がありませんが、 [ヒューマン インターフェイス デバイス]でよろしいでしょうか。

    普段使っているマウス(logicool MX-1100)を接続した場合は  
    [ヒューマン インターフェイス デバイス]の下に
     HID 準拠コンシューマー制御デバイス(1個)
      ・ドライバーファイルが必要でないか、またはこのデバイス用のドライバーファイルが読み込まれていません。
     HID 準拠ベンダー定義デバイス(2個)
      ・ドライバーファイルが必要でないか、またはこのデバイス用のドライバーファイルが読み込まれていません。
     USB 入力デバイス(4個)
      ・C:\WINDOWS\sysytem32\DRIVERS\hidclass.sys
      ・C:\WINDOWS\sysytem32\DRIVERS\hidparse.sys
      ・C:\WINDOWS\sysytem32\DRIVERS\hidusb.sys
     [マウスとそのほかのポインティング ディバイス]の下に
     Logicool HID-compliant Cordless Mouse
      ・C:\WINDOWS\sysytem32\DRIVERS\klmouflt.sys
      ・C:\WINDOWS\sysytem32\DRIVERS\LHidFilt.sys
      ・C:\WINDOWS\sysytem32\DRIVERS\LMouFilt.sys
      ・C:\WINDOWS\sysytem32\DRIVERS\mouclass.sys
      ・C:\WINDOWS\sysytem32\DRIVERS\mouhid.sys
      ・C:\WINDOWS\sysytem32\LkmdfColnst.dll
      ・C:\WINDOWS\sysytem32\LMouFiltColnst.dll

    MX-1100の受信部を外し有線のマウスだけを接続した場合は  
    [ヒューマン インターフェイス デバイス]の下に
     USB 入力デバイス(3個に減ります)
      ・C:\WINDOWS\sysytem32\DRIVERS\hidclass.sys
      ・C:\WINDOWS\sysytem32\DRIVERS\hidparse.sys
      ・C:\WINDOWS\sysytem32\DRIVERS\hidusb.sys
     HID 準拠コンシューマー制御デバイスとHID 準拠ベンダー定義デバイスはありません。
     [マウスとそのほかのポインティング ディバイス]の下に
     HID 準拠マウス
      ・C:\WINDOWS\sysytem32\DRIVERS\klmouflt.sys
      ・C:\WINDOWS\sysytem32\DRIVERS\mouclass.sys
      ・C:\WINDOWS\sysytem32\DRIVERS\mouhid.sys

    以上のようになっています。
    luni, 18 noiembrie 2019 08:16
  • > [ヒューマン インプット デバイス]がありませんが、
    >  [ヒューマン インターフェイス デバイス]でよろしいでしょうか。
    はい、間違えました。
    申し訳ありません。

    >   ・C:\WINDOWS\sysytem32\DRIVERS\klmouflt.sys
    このドライバのタイムスタンプはいつ?
    カスペルスキーのセキュリティ ソフトをつかっているのでしょうか?
    もしそうなら、Windows Update とカスペルスキーの更新を行ってみてください。

    あとレジストリ エディタで、下記レジストリ キーの "UpperFilters" および "LowerFilters" に設定されている内容を確認して教えてください。
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e96f-e325-11ce-bfc1-08002be10318}
    luni, 18 noiembrie 2019 08:30
  • ありがとうございます。

    お見込みのとおりカスペルスキーを使っています。

    カスペルスキーの定義ファイルは最新にしてあり、本体も最新だと思います。

    WindowsUpdateは、最新の状態で、1909があります、という状態です。

    klmouflt.sysの全般タブでは
    ‎ 作成日時:2016‎年‎12‎月‎7‎日、‏‎9:30:58
     更新日時:‎2019‎年‎7‎月‎5‎日、‏‎6:56:24
    デジタル署名タブタイムスタンプは、署名者ごとに
     Kaspersky Lab :2019年1月26日 23:30:20(ダイジェストアルゴリズム:sha1)
     Microsoft Windows Hardware (以下略):2019年2月15日 15:39:59(同:sha256)
     Kaspersky Lab :2019年1月26日 23:30:21(ダイジェストアルゴリズム:sha256)これが2個あります。

    レジストリは
    {4d36e96f-e325-11ce-bfc1-08002be10318}
    ├0000
    ├0001
    ├0003
    ├0004
    ├0005
    ├0006
    └Properties
    となっており、{4d36e96f-e325-11ce-bfc1-08002be10318}の中の
    UpperFilters REG_MULTI_SZ klmouflt mouclass
    LowerFiltersは0000~0006を含めてどこにもありません。
    *Propertiesはアクセスが拒否されます。

    luni, 18 noiembrie 2019 09:32
  • その UpperFilters の設定内容を mouclass だけにして、再起動後に再度テストしてみてください。

    luni, 18 noiembrie 2019 13:33
  • 先ほど、「今編集し、再起動しましたので、これから一晩様子を見てみます。」と投稿しましたが、

    スリープにして5分後に症状が出てしまいました。

    また、マウスを有線マウスに変えて見ましたが、やはりスリープしてから5分後に症状が出てしまいましたので、元の投稿を編集しました。
    luni, 18 noiembrie 2019 14:05
  • 先の返信で記載するのを忘れていましたが。。。。
    レジストリ設定で UpperFilters の設定内容を mouclass だけにして再起動したときに、デバイス マネージャで該当マウスの「ドライバー ファイルの詳細」リストで、klmouflt.sys が外れていることは確認したのでしょうか?
    もし確認していないのであれば再度確認後、テストを実施してください。

    で、それでも改善しない場合は。。。
    まず UpperFilters の設定内容を元に戻してください。(klmouflt を書き加える。)
    次にデバイス マネージャから該当マウスのプロパティを開き、「電源の管理」タブの「このデバイスで、コンピュータのスタンバイ状態を解除できるようにする」のチェックを外し、テストを実施してみてください。
    このテストで改善するのであれば、マウス デバイスをサポートするための各デバイス ノードのどこかに、電源管理を阻害する klmouflt 以外の 3rd ベンダー製ドライバが存在する可能性が考えられますので、それを探す必要があります。

    • Editat de お馬鹿 marți, 19 noiembrie 2019 00:23
    marți, 19 noiembrie 2019 00:23
  • >klmouflt.sys が外れていることは確認したのでしょうか?
    確認していませんでしたので、あらためて確認したところ、klmouflt.sysが残っていました。
    そこでレジストリ エディタを開いたところ、消したはずのklmoufltが復活していました。
    もう一度UpperFiltersの修正でklmoufltを消すと(既定)とかClassとか表示されているペインではmouclassだけになりますが、再起動してからレジストリ エディタを開いたところやはりklmouflt mouclassに戻っていました。何度か試しましたが、再起動どころか、修正後、再度修正画面「複数行文字列の編集」を開くと復活しています。
    お馬鹿様の確認事項が実行できない状態です。どのようにしたら消せるのでしょうか。

    *電源管理の方は早速チェックを外しましたので、テスト未実施ですが「それでも改善しない場合は。。。」の状態です。この状態での確認はこのあとします。


    marți, 19 noiembrie 2019 09:37
  • なるほどね。。。。さすがは、カスペルスキーさん。
    レジストリが復活してしまうのは、恐らくカスペルスキーのセキュリティ ソフトが、自身に関連するレジストリの書き換えをブロックしているから。
    ほとんどのセキュリティ ソフトはシステムを監視するために色んな階層にフィルタ ドライバをかましまくりますが、それらフィルタ ドライバのロード タイミングはレジストリ設定で制御されています。
    つまりレジストリを書き換えればフィルタ ドライバのロードを抑止できるわけで、今回もそれをやろうとしたわけですが、そんな簡単にレジストリを書き換えられちゃったらまともなシステム監視が出来なくなっちゃうので、セキュリティ ソフトは自身でその書き換えをブロックしているわけです。
    (もっとも、そんなブロックは悪意のあるハッカーさん達にとっては屁でもないのですが。)

    という訳で、今回の問題現象はカスペルスキーの klmouflt.sys に起因している可能性が非常に高いわけですが、それを検証すためにはカスペルスキーのセキュリティ ソフトをアンインストールして klmouflt.sys を外すしかありません。
    (他にも外す方法はあるけど悪用されると嫌なので、ここには書けません。)

    また klmouflt.sys に起因していることが判明したとしても、それはカスペルスキー側の問題なので、カスペルスキーさんに問い合わせるしかないと思います。
    (その場合バグか仕様かを判断するのはカスペルスキーさん側にありますが、仮にリモート アクセス監視目的で今回の現象が発生しているのであれば、問い合わせても「仕様です」と言われちゃう可能性もある。)
    miercuri, 20 noiembrie 2019 00:47
  • klmoufltの復活はそういうことなんですね。

    カスペルスキーを使っているのは契約回線におまけで付いてきているだけなので特にこだわりはないので、アンインストールしたところ、当然なのでしょうがklmoufltはなくなりました。

    このままテストすればいいのでしょうが、セキュリティー上問題があるので、ESET Securityを入れました。

    ドライバの詳細については、2019年11月18日 8:16の書き込みの状態から
    ・C:\WINDOWS\sysytem32\DRIVERS\klmouflt.sys
    がなくなっているだけです。

    これでまた一晩様子を見てみます。

    miercuri, 20 noiembrie 2019 10:04
  • カスペルスキーをアンインストールした状態ですが、Logicoolのマウスでも有線のマウスでも、症状が発生してしまいました。
    klmoufltを検索すると、1つ見つかりました。
    C:\Windows\System32\DriverStore\FileRepository\klmouflt.inf_amd64_16653a13eb343ac8\
    にklmouflt.sys、klmouflt.inf、klmouflt.catの3つがありました。
    レジストリとかドライバの詳細に出てこないので無関係とは思いつつ削除して見ようかと思いますが削除しても問題ないでしょうか。自信がないのでご教示ください。本当に初心者的な質問で申し訳ありません。

    miercuri, 20 noiembrie 2019 22:15
  • > レジストリとかドライバの詳細に出てこないので無関係とは思いつつ削除して見ようかと思いますが
    > 削除しても問題ないでしょうか。

    カスペルスキーを既にアンインストールし、かつデバイス マネージャやレジストリに klmouflt がリストされないのであれば本件とは無関係ですが、削除してはいけません。
    (削除しても直接的な影響はないけど、削除してはいけない。)
    ドライバをインストールすると、そのドライバ パッケージ (ドライバをインストールるために必要なファイルをまとめたパッケージ) は "DriverStore" にコピーされます。
    以降、デバイス マネージャーからそのデバイス (ドライバ) を削除しても "DriverStore" に残り続けるので、そこからまた再インストールが可能となります。
    "DriverStore" にコピーされたドライバ パッケージは Windows システムにより管理されているので、勝手に削除してはいけません。
    (そもそもソフトウェア開発者であっても、ドライバ ファイルを勝手に削除するべきではない。)

    で、再発したとのことですが、本問題現象はマウスを一切繋がないと起きないのでしょうか?
    また、問題現象発生時の時間帯に、イベントビューアにはどのようなエラーが記録されていたのでしょうか?
    (イベントビューアに記録されている詳細エラー内容が知りたい。)
    あと、PC にはマウス以外にどのような周辺機器を接続しているのでしょうか?
    (もしかして sideShow デバイスがある PC とか。)
    joi, 21 noiembrie 2019 01:43
  • 前段、良くわかりました。お聞きせずに削除するようなことをしなくて良かったです。

    >本問題現象はマウスを一切繋がないと起きないのでしょうか?
    たしか、マウス無しでも症状が出たような覚えがありますが、曖昧なので、もう一度確認させてください。

    >イベントビューアにはどのようなエラーが記録されていたのでしょうか?
    行数が多くなってしまって申し訳ありませんが、一応全部書いておきます。
    昨晩23時過ぎから今朝6時までの間に11回症状が発生していましたが、Power-Troubleshooterと同じような時間でのイベントは次のような12種類がセットになっている感じです。
    ●情報4:39:30 Kernel-Genenral
     システム時刻は ‎2019‎-‎11‎-‎20T18:58:31.170019400Z から ‎2019‎-‎11‎-‎20T19:39:30.500000000Z に変更されました。
     変更の理由: System time synchronized with the hardware clock。
     プロセス: '' (PID 4)。
    ●情報4:39:30 Kernel-Power
     ファームウェア S3 回数。ResumeCount: 10、FullResume: 921、AverageResume: 921
    ●情報4:39:31 BTHUSB
     Bluetooth の認証コード (link keys) をローカル アダプター上に保管できません。スタートアップの間に Bluetooth キーボードは、システム BIOS で機能しない可能性があります。
    ●警告4:39:31 BTHUSB
     ローカル アダプターは、周辺モードをサポートするための重要な低エネルギー コントローラー状態をサポートしていません。サポートされている最低限必要な状態マスクは 0x2491f7fffff ですが、0x1fffffff を取得しました。低エネルギー周辺ロール機能は無効になります。
    ●エラー4:39:32 SCPNP
     リーダー SCR3310-NTTCom Smart Card Reader 0 のスマート カードのデバイス ID を取得できませんでした。リターン コードは 2148532255 です。
    ●情報4:39:34 e1i65x64
     Intel(R) Ethernet Connection (2) I219-V #2
      Network link has been established at 1Gbps full duplex.
    ●警告4:39:34 e1i65x64
     Intel(R) Ethernet Connection (2) I219-V #2
      Network link is disconnected.
    ●情報4:39:38 e1i65x64
     Intel(R) Ethernet Connection (2) I219-V #2
      Network link has been established at 1Gbps full duplex.
    ●情報4:39:39 Power-Troubleshooter
     システムは低電力状態から再開しました。
     スリープ時間: ‎2019‎-‎11‎-‎20T19:39:39.793749700Z
     スリープ解除時間: ‎2019‎-‎11‎-‎20T19:39:31.901051500Z
     スリープ状態の解除元: 休止までの S4 スリープ
    ●情報4:39:39 Kernel-Power
     デバイス SWD\DAFWSDProvider\urn:uuid:00000000-0000-1000-8000-9c32ce3dfaf0/http://schemas.canon.com/Scanner のドライバー \Driver\WSDScan によって、電源の切り替えが中止されました。
    ●情報4:39:39 Kernel-Power
     システムがスリープ状態になります。
     スリープの理由: Application API
    ●情報4:39:39 Kernel-Power
      システムがスリープ状態から再開されました。

    11回のうち2回(3回目と4回目)に、
    ●警告2:55:00 DNS Cliant Events
     名前 config.teams.microsoft.com の名前解決は、構成されたどの DNS サーバーからも応答がなく、タイムアウトしました。
    さらにそのうち1回(3回目)に
    ●情報1:13:50 Service Control Manager
     Background Intelligent Transfer Service サービスの開始の種類は 要求による開始 から 自動的な開始 に変更されました。
    がセットになっていました。

    >PC にはマウス以外にどのような周辺機器を接続しているのでしょうか?
    NTTコミュニケーションズ ICカードリーダライタ  SCR3310-NTTCom
    Canon ワイヤレステンキー KS-120TKR
    エレコム USB3.0ハブ U3H-T410SWH
    東プレ キーボード 91U
    メーカー不明 Bluetooth USBアダプタ RM-BBUSB
    *Canonのスキャナーのドライバの記録が出てきますが、スキャナ(複合機)は無線LAN接続です。

    常時接続しているのは以上です。
    このあとマウス無しの状態を確認するときに、キーボード以外全部外してみようと思います。
    joi, 21 noiembrie 2019 10:29
  • >このあとマウス無しの状態を確認するときに、キーボード以外全部外してみようと思います。

    やはり症状が発生してしまいました。おおよそ30分に1回、15回の症状発生です・・・。

    joi, 21 noiembrie 2019 21:46
  • ということは、マウスは全く関係なかったわけですね?
    当初、Sleep を解除できるデバイスの設定が HID だけだったので「マウスかなぁ」と思ったのですが、その前提が間違っていたようです。
    (でも、なんで一番初めの検証では、一時的とはいえ問題現象が発生しなかったのだろう。。。。)
    忘れてましたけど、以下のコマンドも実行してみてください。

    powercfg -lastwake
    powercfg -requests
    powercfg -a

    で、提示したもらったイベント ログですが、個人的には以下が気になります。
    ---------------------------------------------
    ●情報4:39:39 Power-Troubleshooter
     システムは低電力状態から再開しました。
     スリープ時間: ‎    2019‎-‎11‎-‎20T19:39:39.793749700Z
     スリープ解除時間: ‎2019‎-‎11‎-‎20T19:39:31.901051500Z
     スリープ状態の解除元: 休止までの S4 スリープ
    ---------------------------------------------

    上記ログでの疑問点は、以下の2つ。
    ---------------------------------------------
    疑問点1
    今まで見落としていましたが、「スリープ」なのに System Power State が S4 になっています。
    通常 (というか私の認識では)、スリープのシステム電源状態は S3 のはずで、S4 は休止状態 (hibernation) だと思うのです。

    疑問点2
    上記ログでは、「スリープ解除時間」が「スリープ時間」よりも先になっています。
    通常であれば、逆になるはずです。
    ---------------------------------------------

    上記より、19:39:31.901051500 の少し前から 19:39:30.500000000 までの間の、システム ログおよびアプリケーション ログを再度確認してみてください。
    (アプリケーション ログとシステム ログをファイルに落として、どこかのオンラインストレージにコピーしてもらえれば、私の方でも確認します。)



    • Editat de お馬鹿 vineri, 22 noiembrie 2019 04:09 誤記訂正
    vineri, 22 noiembrie 2019 01:54
  • >なんで一番初めの検証では、一時的とはいえ問題現象が発生しなかったのだろう。。。。
    本当ですね。あのときはマウスを取り替えて終わりかと思いました。

    追加でいただいた確認事項の結果は次のとおりです。
    ================
    Microsoft Windows [Version 10.0.18362.476]
    (c) 2019 Microsoft Corporation. All rights reserved.

    C:\WINDOWS\system32>powercfg -lastwake
    スリープ状態の解除履歴カウント - 1
    スリープ状態の解除履歴 [0]
      スリープ状態の解除元カウント - 1
      スリープ状態の解除元 [0]
        種類: 固定機能
        電源ボタン

    C:\WINDOWS\system32>powercfg -requests
    DISPLAY:
    なし。

    SYSTEM:
    [PROCESS] \Device\HarddiskVolume2\TV\tvrock.exe

    AWAYMODE:
    なし。

    実行:
    [SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (UsoSvc)
    Universal Orchestrator

    PERFBOOST:
    [DRIVER] レガシー カーネルの呼び出し元
    Power Manager

    ACTIVELOCKSCREEN:
    なし。

    C:\WINDOWS\system32>powercfg -a
    以下のスリープ状態がこのシステムで利用可能です:
        スタンバイ (S3)
        休止状態
        ハイブリッド スリープ
        高速スタートアップ

    以下のスリープ状態はこのシステムでは利用できません:
        スタンバイ (S1)
            システム ファームウェアはこのスタンバイ状態をサポートしていません。

        スタンバイ (S2)
            システム ファームウェアはこのスタンバイ状態をサポートしていません。

        スタンバイ (S0 低電力アイドル)
            システム ファームウェアはこのスタンバイ状態をサポートしていません。

    C:\WINDOWS\system32>
    ================
    次のお馬鹿様の疑問点とログの確認ですが、私にはお手上げです。
    もちろん、わからないなりに見てみようとは思いますが、お言葉に甘えてファイルをアップロードしますのでよろしくお願いします。
    https://drive.google.com/drive/folders/1uYqH5kdtUJi9TRC8lgLHFhVWJGKnu8Pn?usp=sharing

    イベントビューアーの左側ペインのWindowsログの下の「Application」「イベント」のところで右クリックし「すべてのイベントを名前をつけて保存」で作成しましたが、合っていますでしょうか。それすら心配です。

    訂正:「イベント」ではなく「システム」ですね。ファイル名も間違えて「event.evtx」にしてしまいました。

    • Editat de にこだいふく sâmbătă, 23 noiembrie 2019 01:29 訂正を追加しました。
    vineri, 22 noiembrie 2019 10:46
  • すみません。新たに「1911231022app.evtx」と「1911231022system.evtx」をアップロードいたしました。
    アップロードしようと思った理由ですが、
    昨夕の書き込みの、powercfg -requests 結果にある「tvrock.exe」はPC上で予約録画をするためのソフトウェアです。
    もしかしたら、と思い、TvRockの「スケジューラー有効」と「ログイン時に起動」のチェックを外して23:10頃スリープにしたら、すぐに普通にスリープから復帰してしまいました。そのときのスリープ状態の解除元は「不明」(23:12:07)でした。マウスで復帰すると「不明」になりますが、今はマウスからの復帰はしないようになっているので、全く「不明」です。
    そのままスリープさせたところ、朝まで症状が発生しませんでした。TvRockが原因だったか、と思いながらPCに触れずに放置していたところ、10:00過ぎから1分ごとくらいに頻発しました。
    このようなこと(特に長時間の発生無しとその後の頻発)があったためです。
    参考になりますでしょうか。

    TvRockのスケジューラーを無効にした状態での powercfg -requests の結果は次のとおりです。
    ================
    Microsoft Windows [Version 10.0.18362.476]
    (c) 2019 Microsoft Corporation. All rights reserved.

    C:\WINDOWS\system32>powercfg -requests
    DISPLAY:
    なし。

    SYSTEM:
    なし。

    AWAYMODE:
    なし。

    実行:
    なし。

    PERFBOOST:
    なし。

    ACTIVELOCKSCREEN:
    なし。


    C:\WINDOWS\system32>
    ================
    sâmbătă, 23 noiembrie 2019 02:02
  • これかなぁ。。。。

    ----------------------------------------
    ログの名前:         System
    ソース:           Microsoft-Windows-Kernel-Power
    日付:            2019/11/22 18:21:53
    イベント ID:       40
    タスクのカテゴリ:      (36)
    レベル:           情報
    キーワード:         (8192),(1024),(4)
    ユーザー:          N/A
    コンピューター:       yass-i5
    説明:
    デバイス SWD\DAFWSDProvider\urn:uuid:00000000-0000-1000-8000-9c32ce3dfaf0/http://schemas.canon.com/Scanner のドライバー \Driver\WSDScan によって、電源の切り替えが中止されました。
    ----------------------------------------
    ログの名前:         Application
    ソース:           Adaptive Sleep Service
    日付:            2019/11/22 18:21:53
    イベント ID:       0
    タスクのカテゴリ:      なし
    レベル:           情報
    キーワード:         クラシック
    ユーザー:          N/A
    コンピューター:       yass-i5
    説明:
    ソース "Adaptive Sleep Service" からのイベント ID 0 の説明が見つかりません。このイベントを発生させるコンポーネントがローカル コンピューターにインストールされていないか、インストールが壊れています。ローカル コンピューターにコンポーネントをインストールするか、コンポーネントを修復してください。

    イベントが別のコンピューターから発生している場合、イベントと共に表示情報を保存する必要があります。
    イベントには次の情報が含まれています:

    22/11/2019 18:21:53 - Suspend
    ----------------------------------------

    とりあえず、以下のことのを試してみてください。

    -----------------------------------------------------
    <試してほしいこと>

    1. 下記サイトを参考に "msconfig.exe" を起動させ、[サービス] タブで Microsoft 以外のサービスを表示させる。
    ++++++++++++++++++++++++++++++++++++++++++
    Windows でクリーン ブートを実行する方法
    https://support.microsoft.com/ja-jp/help/929135/how-to-perform-a-clean-boot-in-windows
    ++++++++++++++++++++++++++++++++++++++++++

    2. 上記 1 で Microsoft 以外のサービスを表示させたら、下記サービスのチェックを外す。
    AMD 製の "Adaptive Sleep Service"
    Canon 製の全サービス

    3. Canon 製 Scanner を USB 等で物理的に接続している場合は、外す。

    4. PC を再起動後、再度 "msconfig.exe" を起動させ、上記 2 で行った設定が元に戻っていないかを確認する。

    5. 上記 2 での設定が有効であることを確認したら、PC をスリープ状態にさせ、問題現象が発生するか確認する。
    -----------------------------------------------------
    luni, 25 noiembrie 2019 01:11
  • ありがとうございます。

    今、4まで終わりました。再起動後も設定は元に戻っていませんので、この後スリープにします。

    一晩の様子見ではだめかもしれませんので、少しお時間をいただきたいと思います。

    luni, 25 noiembrie 2019 09:58
  • お馬鹿様ご指示の確認の結果をご報告いたします。

    全開書き込み以後、症状は発生しておりません。

    しかし、どうしても出勤前にメールチェックをしないとならなくなったため、そのまま昼間まで通しでの確認ができていません。

    また、メールチェック後にスリープにして、昼間の状況を確認するつもりでしたが、

    スリープ状態の解除元: タイマー - Windows は、スリープ状態の解除を要求したスケジュールされたタスク 'NT TASK\Microsoft\Windows\UpdateOrchestrator\Universal Orchestrator Start' を実行します。

    によって(これも1903からとか話題があるようですが)、スリープから3時間半後(昨日朝)と30分後(今朝)に、スリープが解除されてしまい、長時間の確認はとれていない状況です。

    中途半端な感じですが、一旦報告します。

    また、引き続き確認しますので、よろしくお願いします。

    miercuri, 27 noiembrie 2019 09:29
  • 設定を元に戻して再発するか、確認してみては?

    miercuri, 27 noiembrie 2019 22:01
  • このサイトの日時で、2019年11月25日 9:58の書き込みの状態に戻ってしまいました。

    2019年11月27日 9:29の書き込みのあと、スケベ心を出してESETからカスペルスキーに戻してみました。
    一晩経っても症状は発生しなかったようですが、今朝はPCを起動しないまま出勤しました。

    帰宅したら、スリープから復帰してしまいました。原因は昨日と同じ「タイマー - Windows は、スリープ状態の・・・」という奴です。
    これで復帰する前は症状は発生していませんでした。

    お馬鹿様の書き込みを読んで、では、と、一度サービスの外してあったチェックを入れ、数分で症状が発生。これは当然だと思います。
    そこでAdaptive Sleep Serviceのチェックを外した状態で確認したらやはり数分で症状発生。
    ではCanonの方かな、と今度はCanonの方だけチェックを外した状態で確認したら、やはり数分で症状発生。
    ?と思い両方のチェックを外してみたらやっぱり症状発生。
    25日 9:58の書き込みの時と違うのはESETとカスペルスキーなので、もう一度ESETにして、サービスの2つのチェックを外して確認したら、20分ほどだけですが、症状が発生していません。
    ということで「2019年11月25日 9:58の書き込みの状態に戻ってしまいました。」という状態です。
    今の状態では20分ほどしか確認できていないので、また一晩様子を見て、もう一度確認作業をしてみます。

    スケベ心を出さなければ良かったな、と反省しています。
    joi, 28 noiembrie 2019 14:12
  • AMD 製の "Adaptive Sleep Service" と Canon 製の全サービスを停止させた場合を起動させた場合で、問題現象の発生頻度に差異はなかったのでしょうか?
    私が「設定を元に戻して再発するか、確認してみては?」と提案したのは、設定の違いにより発生頻度に明確な差異が生じるかを検証したかったからです。
    もし AMD および Canon のサービスを停止させた場合に頻度が下がるのであれば、この2つのどちらかあるいは両方の影響だと思います。

    スリープ解除元タイマーとして "Universal Orchestrator Start" が報告されるとのことですが、これは恐らく Windows Update で指定している自動更新スケジュールによるものだと考えら、今回の問題現象とは別物だと思います。
    Windows Update 自動更新を停止させる設定を勧めるのは個人的に良くないことだと思っているので気が引けたのですが、それが気になるのであれば、グループ ポリシー設定で Windows Update に関する構成を編集すれば、"Universal Orchestrator Start" によるスリープ解除は抑止できると思います。
    vineri, 29 noiembrie 2019 06:04
  • >AMD 製の "Adaptive Sleep Service" と Canon 製の全サービスを停止させた場合を起動させた場合で、問題現象の発生頻度に差異はなかったのでしょうか?

    昨日の確認前、カスペルスキーにしてからのことですが、"Adaptive Sleep Service" と Canon 製の全サービスを停止した状態では症状が発生していなかった訳ですが、両者のサービスを開始、前者だけ開始、後者だけ開始、のいずれの場合も、スリープにしてから数分で症状が発生してしまったため、発生頻度というのが、何分に1回とかそういう意味であれば、確認しませんでした。

    もう一度ESETに戻し、両方のサービスを停止させた状態では、一晩症状の発生はしておりませんので、このあと、順に確認してみようと思います。

    "Universal Orchestrator Start" の方は、お馬鹿様おっしゃるとおりWindows Update の自動更新を停止したいとは思っておりませんので、そのままにしておこうと考えています。

    vineri, 29 noiembrie 2019 10:47
  • AMD 及び Canon のサービス間で、共存した場合の整合性がとれていない (いわゆる相性が悪い) 可能性も考えられます。
    とにかくまずは、これらサービスが関連しているのか切り分けることが重要だと思います。
    sâmbătă, 30 noiembrie 2019 02:45
  • ESETを入れた状態で確認してみました。
    (1)Adaptive Sleep Serviceを無効・Canon有効 → スリープ後 数分で症状発生、以後数分ごとに発生
    (2)Adaptive Sleep Serviceを有効・Canon無効 → スリープ後 数分で症状発生、以後数分ごとに発生
    (1)か(2)かいずれかだけで症状が発生すると思ったら、どちらでも発生してしまったので、
    (3)もう一度両方を無効にして確認 → スリープ後 数分で症状発生、以後数分ごとに発生
    なんで?と思い(4)さらにもう一度再起動してから確認 → 症状発生せず

    同じ事をもう一度やってみましたが、同じでした。

    カスペルスキーでも同じ事をやってみましたが、同じ状況です。
    今、カスペルスキーで(4)の状態です。

    この状況は何が何だか訳がわかりません。
    sâmbătă, 30 noiembrie 2019 11:06
  • "msconfig.exe" でサービス構成の設定を変更した際に、PC の再起動はしなかったのでしょうか?
    もししなかったのであれば、(1),(2) についても再起動後の状態を確認してみてください。
    duminică, 1 decembrie 2019 01:37
  • >"msconfig.exe" でサービス構成の設定を変更した際に、PC の再起動はしなかったのでしょうか?

    設定変更後に再起動を促されるので、そのまま再起動しています。ということで(3)と(4)の訳がわからないわけです。

    昨晩は(4)の状態で一度も症状は発生しませんでしたが、今日は仕事だったので何も進展していません。・・・一人じゃ何も進展させられないともいいますが。

    AMDの方もCanonの方も無効の状態で普段使いに問題ないのが幸いです。


    duminică, 1 decembrie 2019 08:41
  • うーん。。。。
    "Adaptive Sleep Service" が関連しているように思うのですが、もしかしてこのサービス、電源ステート管理用のドライバを組み込んでいるのかも。
    とりあえず以下 "DriverView" ツールをダウンロードして、PC に組み込まれている 3rd ベンダー (特に AMD と Canon) 製ドライバを確認してみてください。
    なお "Driver View" ツールは 32 ビット用と 64 ビット用の、2つのバージョンがあります。
    64 ビット OS を使用している場合は、64 ビット バージョンの "Driver View" ツールをダウンロードしてください。
    ------------------------------------------------
    DriverView v1.47 - Loaded Windows Drivers List
    http://www.nirsoft.net/utils/driverview.html
    ------------------------------------------------
    luni, 2 decembrie 2019 02:58
  • すべてのサービスを有効にした状態でDriverViewを起動してみました。
    CompanyがAMDなのが3つありました。名称だけ上げると
    AtihdWT6.sys、atikmpag.sys、atikmdag.sys
    です。
    Canonは見当たりません。(この状態で印刷はできました。)

    なにをどのように確認したらいいのでしょうか。
    luni, 2 decembrie 2019 09:27
  • > 名称だけ上げると AtihdWT6.sys、atikmpag.sys、atikmdag.sys です。

    上記3つのドライバは "C:\Windows\System32\drivers" フォルダにあると思いますが、そのタイムスタンプを教えてください。

    あと一点確認するのを忘れていましたので、下記事項を確認してください。
    -----------------------------------
    <確認してほしいこと>

    1.
    msconfig から AMD 製 "Adaptive Sleep Service" を無効にし再起動する。

    2.
    PC 再起動後、タスク マネージャ [詳細] タブの「名前」の欄に、"AdaptiveSleepService.exe" が表示されていないことを確認する。

    3.
    PC をスリープ状態にし現象が再現するのを待ち、問題現象が発生したらその時間をメモっておく。

    4.
    現象が再発したら PC を起動させ、イベントビューアのアプリケーションに「2019年11月25日 1:11」に私が返信で示した "Adaptive Sleep Service" のログがきろくされていないか確認する。
    -----------------------------------
    marți, 3 decembrie 2019 00:31
  • 3つのドライバのタイムスタンプは次のとおりです。atikmpag.sysとatikmpag.sysの2つは署名が3つあり、場所がdrivers フォルダではなかったのでパスも書いておきます。

    AtihdWT6.sys ‎2017‎年‎11‎月‎18‎日 0:20:10 "C:\Windows\System32\drivers\AtihdWT6.sys" 

    atikmpag.sys (1)‎2019‎年‎8‎月‎17‎日 0:45:47 (Advanced Micro Devices, Inc.)
           (2)‎2019‎年‎9‎月‎19‎日 9:59:56 (Microsoft Windows Hardware Compatibility Publisher)
           (3)‎2019‎年‎8‎月‎17‎日 0:45:50 (Advanced Micro Devices INC.)
           "C:\Windows\System32\DriverStore\FileRepository\c0346830.inf_amd64_f723e13ffb3b2652\B345901\atikmpag.sys"

    atikmpag.sys (1)‎2019‎年‎8‎月‎17‎日 0:58:36 (Advanced Micro Devices, Inc.)
           (2)‎2019‎年‎9‎月‎19‎日 9:59:55 (Microsoft Windows Hardware Compatibility Publisher)
           (3)‎2019‎年‎8‎月‎17‎日 0:58:38 (Advanced Micro Devices INC.)
           "C:\Windows\System32\DriverStore\FileRepository\c0346830.inf_amd64_f723e13ffb3b2652\B345901\atikmdag.sys"

    追加の確認事項ですが、こういうときに限ってなかなか症状が出ません。
    msconfigでサービスを全部チェックを入れてからの再起動でも30分程度では症状が出ませんでした。
    また少し時間をいただきたいと思います。すみません。
    marți, 3 decembrie 2019 11:10
  • > atikmpag.sysとatikmpag.sysの2つは署名が3つあり、
    > 場所がdrivers フォルダではなかったのでパスも書いておきます。

    実際にメモリ上にロードされたドライバ ファイルの場所は "DriverView" ツールでも確認できるのですが、そこで表示されていたパスと同じということでしょうか?
    あと先に示した手順2では、"AdaptiveSleepService.exe" は表示されていなかったんですよね?

    既にご存知とは思いますが、"Adaptive Sleep Service" でググると、このサービスに起因してスリープ機能が阻害されるとの事例が散見されます。
    ただどの事例にも明確な技術的根拠は示されていないし、今回のケースと一致していない部分もあるので、現状では "Adaptive Sleep Service" の問題と断言することはできませんが、間接的な一要因にはなっているのでは。。。。と思うのです。

    • Editat de お馬鹿 miercuri, 4 decembrie 2019 00:06
    miercuri, 4 decembrie 2019 00:05
  • >実際にメモリ上にロードされたドライバ ファイルの場所は "DriverView" ツールでも確認できるのですが、そこで表示されていたパスと同じということでしょうか?

    そのとおりです。"DriverView" ツールに出てくるパスと同じです。
    念のため、ファイル名で検索したところ、昨日書いたファイル以外に、ドライバをダウンロードした時のいくつものインストールパッケージの中にもありました。↓こんな感じです。
    "C:\AMD\Packages\Drivers\Radeon-Adrenalin-18.5.2-c0329457-win10-64bit-180605_drvBETA\B329366\atikmpag.sys"

    >あと先に示した手順2では、"AdaptiveSleepService.exe" は表示されていなかったんですよね?
    これもそのとおりです。
    お馬鹿様の2019年12月3日 0:31の書き込みの手順1に進む前に、一度"AdaptiveSleepService.exe"を有効にした時(無効のままでは症状が発生していないため)に、再起動から少し経ってから表示されることを確認しました。その後、スリープしたときには症状が発生しました。
    続けて手順1で、"Adaptive Sleep Service"を無効にして再起動し、手順2でタスクマネージャの詳細を確認したところ、"Adaptive Sleep Service"はありませんでした。
    手順3に進み、スリープにしましたが、昨晩と、今日の昼間、一度も症状が発生していません。

    "Adaptive Sleep Service"を無効にすることで症状が発生しないのはうれしいのですが、原因追及のためには「この前は出たのに何でだよ」です。

    miercuri, 4 decembrie 2019 09:41
  • ここ数日、"AdaptiveSleepService.exe"を有効にしたり無効にしたり、繰り返し確認してみましたが、有効にすると確実に症状が発生し、無効にしたときには一度も症状が発生しませんでした。

    お馬鹿様からの確認事項が全く確認できない状態ですが、この状況からは、"AdaptiveSleepService.exe"が原因かな、と思います。

    もちろん、しばらくは引き続き様子を見ていこうと思いますが、お馬鹿様には大変お世話になりました。ありがとうございました。

    duminică, 8 decembrie 2019 10:11
  • もし可能だったら、下記事項を確認してもらえますか?
    (問題解決のための確認ではないので、面倒だったら無視してください。)

    ---------------------------------------------
    <確認してほしいこと>
    ☆ "Adaptive Sleep Service" を有効および無効にした際に、"DriverView" ツールでリストされる AMD 製ドライバに差異はあるか?
    ---------------------------------------------
    luni, 9 decembrie 2019 01:03
  • >もし可能だったら、下記事項を確認してもらえますか?

    もちろんです。比較したところ、3つとも address、End adress、indexの3か所に違いがありましたが、Versionとか、Filenameなどは全く同じでした。

    一応、違っていた部分を書いておきます。上段が"Adaptive Sleep Service" 有効、下段が無効の状態です。

                          address                     End adress                index
    AtihdWT6.sys    00000000`49250000    00000000`4926E000    137
                          00000000`1ED30000    00000000`1ED4E000    136
    atikmdag.sys    00000000`49D50000    00000000`4D23C000    118
                         00000000`1F600000    00000000`22AEC000    117
    atikmpag.sys    00000000`45100000    00000000`45193000    117
                         00000000`1A5E0000    00000000`1A673000    116

    luni, 9 decembrie 2019 10:55
  • 確認、ありがとうございました。
    ただ、私の質問の仕方がちょっと悪かったようで、余計な手間を取らせてしまったようで、申し訳ありませんでした。
    確認したかったのは、"Adaptive Sleep Service" を有効時および無効時で、"AtihdWT6.sys", "atikmdag.sys", "atikmpag.sys" 以外の AMD 製ドライバがロードあるいはアンロードされていることはあるか、ということでした。
    今回実施してもらった検証では、有効時および無効時それぞれの状態でロードされている AMD 製ドライバは、"AtihdWT6.sys", "atikmdag.sys", "atikmpag.sys" だけだったとのことだと思いますが、もしかしたら "Adaptive Sleep Service" を無効にしたときにアンロードされているドライバがあるのでは、と推測しています。
    で、一番その可能性が高いのは AMD 製だと思ったので、それを確認してもらったわけです。

    あくまでも私見ですが、バグにせよ仕様にせよ、こんな面白いというか奇妙な現象は、一般のアプリやサービスが動作するユーザ モード側の処理だけでは無理だと思っています。
    つまり本当の黒幕は、カーネル モード側で動作している「なんかの」ドライバ。。。と私は推測しているので、そこら辺をもう少し突っ込んで調べれば、もしかしたら根本原因にたどり着けるかも。
    もっとも現状では単なる推測レベルなので、「ハズレ」の可能性の方が高いですけど。^_^;)

    marți, 10 decembrie 2019 01:13
  • 余計な手間だなんて、とんでもない。
    私の理解力不足で失礼しました。

    >"Adaptive Sleep Service" を有効時および無効時で、"AtihdWT6.sys", "atikmdag.sys", "atikmpag.sys" 以外の AMD 製ドライバがロードあるいはアンロードされていることはあるか、

    と言うことですが、あらためて"Adaptive Sleep Service" の有効時と無効時で全ドライバを(名称だけでですが)比較したところ、有効時と無効時でAMDのドライバは、どちらも前述の3つだけでした。

    DriverViewに表示されるドライバは、有効時215、無効時216です。
    無効の時だけ出てくるドライバはAMD製ではありませんが iqvw64e.sys というIntel製の Network Adapter Diagnostic Driver です。

    お馬鹿様にとっても面白い、奇妙と言われるような現象に当たってしまったわけですね・・・。運がいいのか悪いのか・・・。

    marți, 10 decembrie 2019 09:43
  • > 無効の時だけ出てくるドライバはAMD製ではありませんが
    > iqvw64e.sys というIntel製の Network Adapter Diagnostic Driver です。

    関連性は全くわかりませんが、それが関係しているのであれば、"Adaptive Sleep Service" を有効した状態であっても "iqvw64e.sys" をロード状態にしておけばいいのかも。
    もし可能であれば、以下のことを確かめてください。
    ---------------------------------------------------
    <試してほしいこと>
    1. 管理者権限でコマンド プロンプトを開く。
    2. 下記コマンドを実行する。
    net start iqvw64e
    3. 上記 2 で「サービスは正常に開始されました。」と表示されたら、PC をスリープ状態にさせ、現象が発生するか確認する。
    ---------------------------------------------------
    miercuri, 11 decembrie 2019 01:44
  • 馬鹿なことをしでかしてしまったようです。

    お馬鹿様の<試してほしいこと>を実行するため、"Adaptive Sleep Service" を有効した状態にして、1、2と薦めたところ、3の「サービスは正常に開始されました。」ではなく「無効なサービス名です。」と出ました。
    そこで、DriverViewで確認すると、iqvw64e.sys が動いていました。(昨日は間違いなく動いていなかったのですが・・・。)

    そこでもう一度"Adaptive Sleep Service" の有効・無効の状態でのドライバを比較したところ、有効の状態で動いていた「klupd_klif_klark.sys」が無効では動いていませんでした。

    <試してほしいこと>の「net start iqvw64e」のかわりに「klupd_klif_klark」と打って実行し、「サービスは正常に開始されました。」となりました。

    その後、"Adaptive Sleep Service" を有効にしてからスリープにして確認したところ、症状が発生してしまいました。
    だめか、と思い、"Adaptive Sleep Service" を無効に戻しましたが、症状が発生するようになってしまいました。

    何度か再起動をしたり、"Adaptive Sleep Service" の有効・有効を切り替えたり、以前の検証中にあったCanonの方も無効にしたりしてみていますが、症状が止められなくなってしまいました。

    今、症状が発生したあと、スリープから復帰させた状態ですが、DriverViewでは「klupd_klif_klark.sys」は見当たりません。(昨晩書き込んだ時点では見当たりませんでしたが、現在12日7:15では動いているようです。)

    「klupd_klif_klark.sys」のdescriptionは「Kaspersky Lab Anti-Rootkit」となっていますので、時間のあるときに、一度カスペルスキーを削除・再インストールして確認してみようかと思っています。あるいはシステムの復元ではどうなのかな、とも思っています。

    >「klupd_klif_klark」と打って実行し、
    のところですが、"Adaptive Sleep Service" が有効の状態で動いている「klupd_klif_klark.sys」ですから、"Adaptive Sleep Service" を無効にしてから実行したと思いますが、恥ずかしながら忘れてしまいました。



    • Editat de にこだいふく miercuri, 11 decembrie 2019 22:15 「klupd_klif_klark.sys」の状態を追加
    miercuri, 11 decembrie 2019 13:44
  • 私の説明に不備があったようで、申し訳ありませんでした。
    "net start iqvw64e" で「無効なサービス名です。」が出てくる可能性があることは事前に考慮していたのですが、その場合には何もしなければ何も実害は無いので、そのまま放置してくれればいいと思ってました。
    まさか、他のサービスに対して実行するとは考えていませんでした。
    説明が足りず申し訳ありませんでした。

    "Adaptive Sleep Service" 有効時でも "iqvw64e.sys" がロードされたとのことですが、だとしたらやっぱり "iqvw64e.sys" は関係ないんだと思います。
    ("iqvw64e.sys" は "Intel(R) Network Adapter Diagnostic Driver" とのことなので、たまたま "Adaptive Sleep Service" 無効時に一時的なネットーワークへのリンクダウンが発生し、その際にネットワーク接続診断を行うために "iqvw64e.sys" がロードされただけなのかもしれません。)

    > そこでもう一度"Adaptive Sleep Service" の有効・無効の状態でのドライバを比較したところ、
    > 有効の状態で動いていた「klupd_klif_klark.sys」が無効では動いていませんでした。

    それは重要なヒントになるかも。
    ちなみにカスペルスキー製のソフトウェアって、何かインストールしてるんですか?
    使ってるなら、とりあえずまだアンインストールしなくてもいいです。
    検証を行っている最中にソフトウェア構成を変えてしまうと、問題の切り分けが難しくなってしまうので。
    とりあえず以下のことを試してみてください。
    ---------------------------------------------------
    <試してほしいこと>
    1. "Adaptive Sleep Service" を有効にして、PC を再起動しておく。
    2. 管理者権限でコマンド プロンプトを開く。
    3. "DriverView" ツールで "klupd_klif_klark.sys" がロードされていることを確認する。
    4. 下記コマンドを実行する。
    net start
    5. 上記 3 で表示された起動中のサービス リストの中に、"klupd_klif_klark" があるかを確認する。
    ただし必ずしも同じ名前ではなく、「似たような」名前の可能性もあります。
    その場合は、きちんと確認する必要があるので、以降の手順は行わないでください。
    6. 上記 5 で "klupd_klif_klark" が見つかったら、以下のコマンドを実行する。
    net stop klupd_klif_klark
    7. 上記 6 で 「サービスは正常に開始されました。」と表示されたら、再度下記コマンドを実行する、
    net start
    8. 上記 7 で "klupd_klif_klark" がリストされていないことを確認したら、PC をスリープ状態にさせ、現象が発生するか確認する。
    逆にリストされていたら、以下 9 は実施する必要はありません。
    9. もし現象が再現したら PC にログオンし下記コマンドを実行し、"klupd_klif_klark" がリストされているか確認する。
    net start
    ---------------------------------------------------
    joi, 12 decembrie 2019 01:48
  • >私の説明に不備があったようで、申し訳ありませんでした。
    申し訳ないだなんてとんでもない。私が暴走してしまった結果です。
    正直、どうしてあれを実行してしまったんでしょう。自分でも困惑し、反省しています。

    >ちなみにカスペルスキー製のソフトウェアって、何かインストールしてるんですか?
    カスペルスキー製のソフトウェアは、カスペルスキー インターネット セキュリティと、一緒にインストールされるカスペルスキー セキュアコネクションがインストールされています。
    数年前から使っています。この一連の中でお馬鹿様にお世話になりながら、一度アンインストールしてESETに切り替え、再度、カスペルスキーを入れ直した状態です。

    さて、<試してほしいこと>を実行しました。
    1~4が終わりました。5の「上記 3 で・・・」は「上記 4 で・・・」でしょうか・・・、「上記 4 で・・・」でよろしければ、コマンドプロンプトに120個表示されましたが、似たような名前も含めて"klupd_klif_klark"は見当たりませんでした。
    カスペルスキー製は「Kaspersky Anti-Virus Service 20.0」だけだと思います。
    結果を以前と同じGoogleドライブに上げておきますのでよろしければご覧ください。
    https://drive.google.com/drive/folders/1uYqH5kdtUJi9TRC8lgLHFhVWJGKnu8Pn?usp=sharing

    今日は余計なことをせず、ここまで報告させていただきます。
    joi, 12 decembrie 2019 09:42
  • > 再度、カスペルスキーを入れ直した状態です。

    カスペルスキーに戻していたんですね。
    だったら "klupd_klif_klark.sys" は止めない方がいい。。。というより止めるべきではありませんね。

    現在の状況は完全に振り出しに戻ったということだと思いますが、まずは "Adaptive Sleep Service" が関連しているのかを確認すべきだと思います。
    下記手順を実施し、その際のアプリケーション ログとシステム ログを再度採取されることをお勧めします。
    -------------------------------------------------
    <"Adaptive Sleep Service" の切り分け検証>
    1. "Adaptive Sleep Service" を無効にして PC を再起動させる。
    2. 管理者権限でコマンド プロンプトを起動させ、下記コマンドを実行する。
    net start
    3. 上記 2 で、"AdaptiveSleepService" がリストされていないことを確認する。
    4. 上記 3 で "AdaptiveSleepService" がリストされていないことを確認したら、PC をスリープ状態にさせ、現象が発生するか確認する。
    5. 現象が再現したらその時間を記録し、PC にログオンしアプリケーション ログとシステム ログを採取する。
    -------------------------------------------------
    vineri, 13 decembrie 2019 01:24
  • ありがとうございます。

    今日は少し遅くなっていまいましたが、これから確認したいと思います。

    vineri, 13 decembrie 2019 13:22
  • 2019年12月11日 13:44で書いたように、"Adaptive Sleep Service" 有効・無効どちらでも症状が発生するようになってしまったため、スリープさせないかシャットダウンするかで運用していました。

    ところが、2019年12月13日 13:22の書き込み以降、<"Adaptive Sleep Service" の切り分け検証>の4.のスリープまで進んでも、症状は一度も発生しませんでした。
    これでは検証にならないため、先ほど"Adaptive Sleep Service"を有効にしてみたら症状が発生しました。
    改めて"Adaptive Sleep Service"を無効にしてスリープさせたら症状が発生したので、net startコマンドを実行してスリープさせました。
    症状が発生したので、ログを再取得しました。ただ、アプリケーションログには、症状発生と同じ時間での記録は見当たりません。

    https://drive.google.com/open?id=1uYqH5kdtUJi9TRC8lgLHFhVWJGKnu8Pn
    ↑1215で始まるのが、net startコマンドを実施したときの結果とイベントログです。

    追記 上の文章を書いた日(12/15)の夜、"Adaptive Sleep Service" 無効の状態でスリープにしてから就寝しましたが、症状は発生しなかったようです。
    duminică, 15 decembrie 2019 05:37
  • > 改めて"Adaptive Sleep Service"を無効にしてスリープさせたら症状が発生したので、
    > net startコマンドを実行してスリープさせました。

    これ↑が発生した日時は、2019-12-15 14:17 ごろでしょうか?
    違う場合は、発生した日時を教えてください。
    もし問題現象が 2019-12-15 14:17 ごろに発生したのであれば、やはり根本原因は "Adaptive Sleep Service" ではないと思います。
    "Adaptive Sleep Service" の状態に依存して発生頻度が変わるようなので、このサービス プロセスは無関係では無いと思いますが、やはり「黒幕」は別にいると思うのです。
    うーーーーーん。。。。私の環境でも起こせればいいのに。。。。
    luni, 16 decembrie 2019 01:24
  • > これ↑が発生した日時は、2019-12-15 14:17 ごろでしょうか?
    そのとおりです。イベントログで14:17:28にある「スリープ状態の解除元: 休止までの S4 スリープ」です。

    > "Adaptive Sleep Service" ではないと思います。
    そうですか。"Adaptive Sleep Service" を無効にしておくとほぼ症状は出ませんが、だからといって、「"Adaptive Sleep Service" ではないと思います。」となるところは難しいですね。
    luni, 16 decembrie 2019 10:53
  • 確認するの忘れてましたけど、AMD 製サービスは "Adaptive Sleep Service" 以外にも "AMD External Events Utility" があったんですね。
    試しに、"Adaptive Sleep Service" を有効でかつ "AMD External Events Utility" を無効にした状態で起きるか、確認してもらえますか?
    marți, 17 decembrie 2019 09:11
  • > 試しに、"Adaptive Sleep Service" を有効でかつ "AMD External Events Utility" を無効にした状態で起きるか、確認してもらえますか?

    この状態では(も?)、問題の症状が発生しました。

    スリープにしてからおよそ10分後と20分後に発生し、イベントビューワーのアプリケーションには、症状発生時間を含め、スリープした頃からスリープを解除する頃までのログは残っていませんでした。

    marți, 17 decembrie 2019 13:21
  • > 1903にしてからですが、
    > スリープ中に電源のファンが突然回りHDDのアクセスランプが点くものの、
    > 画面が点いたりもせずに再びスリープになるというような症状が出るようになりました。

    これ↑、あんまり気にしてなかったけど、モニタになんにも表示されないということは、ディスプレイ ドライバが関連ているのかも。
    可能であったら、以下の検証を実施してみてください。

    ---------------------------------------------------
    <検証してほしいこと>
    1. "Adaptive Sleep Service" および "AMD External Events Utility" を有効にする。
    2. デバイス マネージャを開き、"ディスプレイ アダプター" 配下にある AMD 製ディスプレイ アダプターを無効にする。
    3. 「DirectX 診断ツール (dxdiag.exe)」を起動させる。
    4. 「DirectX 診断ツール」の "ディスプレイ" タブで、ドライバが "Microsoft 基本ディスプレイ ドライバ" (basicdisplay.sys) に置き換わっているのを確認する。
    5. PC をスリープ状態にし、現象が発生するかを確認する。
    6. 検証が終わったら、デバイス マネージャから "ディスプレイ アダプター" 配下にある AMD 製ディスプレイ アダプターを有効に戻す。
    ---------------------------------------------------
    miercuri, 18 decembrie 2019 01:50
  • 早速検証をやってみましたが、<検証してほしいこと>の「5. PC をスリープ状態にし、現象が発生するかを確認する。」で、スリープがなくなってしまいました。
    「windows10 スリープを有効にしたい」で検索してスリープを復活させようとしましたが、できませんでしたので、最後まで検証することができませんでした。すみません。

    追記 寝る前に"Adaptive Sleep Service"だけを無効に戻しました。最近の状況ではこの状態だと症状が治まるはずですが、再起動してからスリープにしたところ、また症状が発生するようになりました。もう一度再起動をしてみましたが症状が発生するので、シャットダウンして就寝しました。


    miercuri, 18 decembrie 2019 10:18
  • > スリープがなくなってしまいました。

    「なくなって」とは、どのような状態なのでしょうか?
    "スリープ" のメニューが表示されなくなった、ということでしょうか?
    もしそうなら、下記サイトが参考になると思います。

    ----------------------------------------
    Windows 10で電源メニューにスリープが表示されない場合の対処方法
    https://121ware.com/qasearch/1007/app/servlet/relatedqa?QID=019583
    ----------------------------------------

    ただ、なぜ突然 "スリープ" メニューの表示が消えたのか、そちら方が気になります。
    ご理解いただけていると思いますが、私が先に示した検証手順では、"ディスプレイ アダプター" のドライバを AMD 製から Microsoft 製に変更しているだけで、電源オプションの設定についての変更は一切していません。
    なんの影響で電源オプション設定が変更されたのか、その原因を調べるべきだと思います。

    また、"Adaptive Sleep Service" を無効にしてもスリープから復帰してしまう問題現象が起きるとのことですが、(何度も書いていますが) 私はこの現象の根本原因が "Adaptive Sleep Service" にあるとは考えていないので、その条件で再発しても不思議ではないと思います。
    ("Adaptive Sleep Service" は、問題現象発生の頻度を上げているだけで、それ自体が根本原因ではないと考えています。)
    joi, 19 decembrie 2019 01:28
  • 書いていただいたサイトが、まさに昨日自分が参考にしたサイトです。
    そのページの
    『5「シャットダウン設定」欄で「スリープ」にチェックが入っていない場合は、「スリープ」をクリックしてチェックを入れた状態にし、「変更の保存」をクリックします。』の図にある「□ スリープ」がありません。
    AMD 製ディスプレイ アダプターを無効から有効にすると復活しますので、AMDのドライバの有効無効とスリープの有無が連動しているのだと思います。

    >私はこの現象の根本原因が "Adaptive Sleep Service" にあるとは考えていないので、その条件で再発しても不思議ではないと思います。
    たしかにそうですよね。
    joi, 19 decembrie 2019 09:07
  • > AMD 製ディスプレイ アダプターを無効から有効にすると復活しますので、
    > AMDのドライバの有効無効とスリープの有無が連動しているのだと思います。

    やっと、大元の原因が見えてきたような気がします。
    この問題、AMD のディスプレイ アダプタ ドライバが根本原因のように思います。
    AMD ディスプレイ アダプタ ドライバは、最新バージョンでしょうか?
    もし最新ドライバなら、AMD ディスプレイ アダプタ ドライバにアタッチしている別の 3rd ベンダー製ドライバがいるのかもしれません。
    "DriverView" ツールで、怪しい 3rdベンダー製ドライバがいないか、確認する必要があるかも。
    vineri, 20 decembrie 2019 09:28
  • >AMD ディスプレイ アダプタ ドライバは、最新バージョンでしょうか?

    デバイスマネージャでドライバの更新をしようとすると最新だと表示されます。

    >"DriverView" ツールで、怪しい 3rdベンダー製ドライバがいないか、確認する必要があるかも。

    これはどのように確認すればいいのでしょうか。

    vineri, 20 decembrie 2019 10:24
  • "Adaptive Sleep Service" と "AMD External Events Utility" を無効にした状態で PC を再起動させ、その状態からデバイス マネージャで AMD 製ディスプレイ アダプターを無効にした場合に、「電源ボタンの定義とパスワード保護の有効化」の "スリープ" チェック ボックスはどうなっていますか?
    luni, 23 decembrie 2019 08:40
  • また訳がわからないことになってしまいました・・・。System Configuration から "Adaptive Sleep Service" がなくなってしまいました。
    先日(2019年12月19日)の書き込みのあと、20日か21日にシャットダウンをしたところ(間違えて再起動を選んだかもしれませんが)、またファンが回り始めたものの正常に進まず、BIOSのロゴすら出ないままになってしまったため、電源ボタンを押して強制終了してからもう一度起動させました。このときまで、画面の左上にBIOSのメーカーロゴ(「アメリカンメガトレンド」でググると出てくる左上に赤い△がある画面)が出ていたのが、これ以降、GIGABYTE社のロゴが中央にある画面に変わってしまいました。このあと、起動したかと思ったら勝手に再起動しました。ただ、そのあとは正常に起動し、問題なく使用できていたのであまり気にしていませんでした。
    一旦Windowsが起動してから勝手に再起動したので、"Adaptive Sleep Service"が削除されたとしたらこのタイミングではないかと思います。と言うより、他に思い当たる節がありません。

    >私はこの現象の根本原因が "Adaptive Sleep Service" にあるとは考えていないので、
    と言うことでもありますので、 "Adaptive Sleep Service" がなくなってしまいましたが、"AMD External Events Utility"(現在、System Configuration で表示される唯一のAMDのサービスです)を無効にした状態で確認しました。結果としては、やはり「スリープ」がありません。

    上に書いた「先日(2019年12月19日)の書き込みのあと、」ですが、起動しっぱなしか、シャットダウンをするかだったので、症状の発生は確認していません。このあと、"AMD External Events Utility"を有効(無効なサービスがない状態)にして、確認したいと思います。
    marți, 24 decembrie 2019 10:19
  • > System Configuration から "Adaptive Sleep Service" がなくなってしまいました。

    msconfig ツールで、"Adaptive Sleep Service" がリストされなくなった。。。ということでしょうか?
    何かソフトウェア構成を変更したのでしょうか?
    PC 電源投入時の BIOS 画面が変わったということは、BIOS のアップデートをしたのでは?
    前にも書きましたが、検証を行っている最中にソフトウェア構成を変えてしまうと、問題の切り分けが難しくなってしまうので、新規のインストールはしない方がいいです。

    とりあえず、タスクマネージャの "詳細" タブに "AdaptiveSleepService.exe" がリストされているか、確認してみてください。
    もし "AdaptiveSleepService.exe" がないのであれば、"AMD External Events Utility" および AMD 製 ディスプレイ アダプター有効にした状態で問題現象が発生するか、確認してみてください。
    (たぶん発生頻度は下がるんぢゃないかな。。。と思っています。)
    miercuri, 25 decembrie 2019 01:28
  • >msconfig ツールで、"Adaptive Sleep Service" がリストされなくなった。。。ということでしょうか?
    そのとおりです。

    >何かソフトウェア構成を変更したのでしょうか?
    >PC 電源投入時の BIOS 画面が変わったということは、BIOS のアップデートをしたのでは?
    自分で意識して何かをしたということはありません。BIOSのアップデートもしてはいません。BIOSのアップデートは、ここに書き込む以前(10月下旬か11月のはじめ)にファイルをダウンロードしてはみましたが、昔のFDを使うやり方ではないためにやり方がわからず、そのままファイルを削除しました。
    昨日書いたようにシャットダウン(間違えて再起動を選んだのかもしれませんが)をしようとしたときに、システムが変な動きをした、という認識というか記憶はありますが、
    >前にも書きましたが、・・・
    を守っていたつもりなんですが・・・。

    >とりあえず、タスクマネージャの "詳細" タブに "AdaptiveSleepService.exe" がリストされているか、確認してみてください。
    やはり見当たりません。

    >もし "AdaptiveSleepService.exe" がないのであれば、"AMD External Events Utility" および AMD 製 ディスプレイ アダプター有効にした状態で問題現象が発生するか、確認してみてください。
    帰宅後、お馬鹿様の書き込みを確認してすぐ、サービスで表示されているもの全部のチェックをつけて再起動し、スリープにしてみました。
    スリープにしてすぐ(1~2分後)に勝手にスリープから復帰しました。スリープ状態の解除元は「不明」となっていました。
    そのままもう一度スリープにしたところ、2時間ほどしか経っていませんが、今のところ、問題の症状は発生していません。

    昨日書き込んだ「このあと、"AMD External Events Utility"を有効(無効なサービスがない状態)にして、確認したいと思います。」ですが、一晩症状は発生していません。



    miercuri, 25 decembrie 2019 13:29
  • AMD ディスプレイ アダプタ ドライバにアタッチしている別の 3rd ベンダー製ドライバがいるか、確認したほうがいいと思います。
    一番手っ取り早いのは、意図的にブルースクリーンを発生させて完全メモリダンプを採取しそれをチェックする方法なんですが、たぶんそーいう方法は嫌がると思うので、とりあえず以下の方法で "DriverView" のドライバ情報をテキスト ファイルに落として、それをまた Googole Drive かどこかのオンラインストレージにアップしてみてください。

    -----------------------------------------------
    <DriverView でのテキスト ファイルの採取方法>

    1. "Company" 表示の確認
    "DriverView" ウィンドウの "Driver Name", "Address", "File Type" 等が表示されているカラムに、"Company" の項目が表示されていることを確認してください。
    カラムに "Company" が表示されていない場合は、マウス カーソルを "Driver Name" 部分にポイントし、右クリックで "Choose Columns" を選択して "Column Settings" ダイアログ ボックスを表示させ、全項目のチェックボックスにチェックを入れ、"OK" ボタンを押下して "Column Settings" ダイアログ ボックスを閉じてください。

    2. "Company" でのソート (並び替え)
    "DriverView" ウィンドウの "Company" カラムをクリックし、表示されているドライバ ファイルを "Company" (会社名) でソートして (並び替えて) 、"Company" 部分が空欄となっているドライバが最上位に表示されるようにしてください。

    3. デジタル署名の確認
    "DriverView" ウィンドウ メニュー バーの "Options" をクリックし、"Read Digital Signatures" にチェック マークを入れてください。
    次に "DriverView" ウィンドウ メニュー バーの "View" をクリックし、一番下の "Refresh" をクリックしてください。

    4. テキスト ファイルへの出力
    "DriverView" ウィンドウ メニュー バーの "Edit" をクリックし、"Select All" をクリックして、画面全体をハイライト状態にしてください。
    その状態から "DriverView" ウィンドウ メニュー バーの "File" をクリックし、"Save Selected Items" を選択して "Select a filename to save" ダイアログ ボックスを表示させ、お好きなフォルダに "DriverView.txt" というファイル名 (ホントはどんな名前でもいい) で保存してください。
    -----------------------------------------------
    joi, 26 decembrie 2019 01:44
  • ご指示のとおりファイルを作成し、アップロードしました。よろしくお願いします。

    https://drive.google.com/open?id=1KBUWNuX13QrpLCy_KwS3Mub0M_h0bLIB

    *昨日の続きですが、引き続きmsconfig ツールですべてのチェックをつけた状態で今朝出勤前にスリープにしましたが、先ほど帰宅してスリープを解除するまで13時間ほど、症状は発生していません。


    joi, 26 decembrie 2019 13:18
  • CyberLink の PowerDVD を使ってますよね?
    これをアンインストールして、"DriverView" に "000.fcl" がリストされない状態で、再度現象を確認してみてください。

    ちなみに PwoerDVD には、下記不具合があるようです。
    -----------------------------------------
    スリープモードに入らない
    https://jp.cyberlink.com/support/faq-content.do?id=11607
    -----------------------------------------
    vineri, 27 decembrie 2019 00:41
  • おっしゃるとおりCyberLink の PowerDVD を使ってます。
    PowerDVDをアンインストールして、"DriverView" に "000.fcl" がリストされない状態を確認しましたので、これから確認してみます。

    確認に時間をいただきたいと思います。

    vineri, 27 decembrie 2019 10:52
  • とりあえず年を越す前に報告です。

    できるだけスリープの時間が長くなるようにしていましたが、今のところ、全く問題の症状は発生していません。

    marți, 31 decembrie 2019 12:51
  • 追加です。

    あれから、全く問題の症状は発生していません。

    miercuri, 8 ianuarie 2020 09:48
  • なら、PowerDVD の問題なのでは?
    joi, 9 ianuarie 2020 02:18
  • 今、なぜかどのブラウザで見ても投稿者がどなたなのかわかりませんが、お馬鹿様でよろしいでしょうか。

    2週間近く症状が発生しておりません。長いことお付き合いいただき、ありがとうございました。

    joi, 9 ianuarie 2020 11:02