よくお読みください。これは通常の稼働時間に関する質問ではありません。
私はそうしない傾向があるシャットダウンコンピュータ自体をスリープ状態にするのではなく、スリープ状態にします。これにより、起動時間が短縮され、WOL を使用できるようになります。さまざまな「アップタイム」方法 (sysinfo、uptime.exe、タスク マネージャーなど) では、最後の完全起動からの時間が表示されます。つまり、スリープに費やされた時間も考慮されます。真実稼働時間。つまり、PC が最後に起動してから起動していた時間のみです。
答え1
これを実行するソフトウェアはないので、これを実現する唯一の方法は、基本的に毎秒（または毎分）変数に +1 を与えるスクリプトを作成し、変数の値を読み取る方法を用意することです。PC が休止状態/スリープ状態などの場合は、スクリプトは実行されていないため、カウンターは増加しません。
このようなスクリプトがバックグラウンドで継続的に実行されると、システムに影響を与える可能性があります。したがって、問題は、これをどの程度望んでいるかということです。
(スクリプトへの影響の理由) スクリプトの実行時間が長くなるほど、数値は大きくなり、非常に高い値は保存するためにより多くのメモリを必要とすることを意味します。(整数にできない値 (65535) について話していますが、これほど高い値にすると、システムが数日または数週間稼働している必要があると思います。もちろん、日数をカウントして値をリセットするスクリプトを作成して、その問題を排除することもできますが、その場合、スクリプトはサイクル内でより多くのコードを実行することになり、それ自体が、たとえわずかでも、スクリプトに影響を与えることになります。
答え2
Windows は、スリープからの復帰に関するシステム イベントを生成します (イベント ID: 1、ソース: Power-Troubleshooter)。このイベントには、スリープ時間と復帰時間が含まれます。
ソース：ウェイク ソース - イベント ビューアー ログの読み取り - Windows 7 ヘルプ フォーラム
「実際の稼働時間」の値を決定するには、(言及したソースから) 最後の起動時間を決定し、その後のウェイク イベントからスリープに費やされた時間を差し引きます。
注: .NET ライブラリを使用してイベント ログを照会するアプリケーションを作成できます (Super User ではトピック外です)。
答え3
「真の稼働時間」の定義はどの程度柔軟ですか？LPChipの回答 ワークステーション ロックとワークステーション ロック解除によってトリガーされるスケジュールされたタスクを記述し、その後、明らかな計算を実行します。
計算がわかりにくい場合のために、次の式を当てます。
- 「論理的な」起動時間と累積稼働時間という 2 つの値を追跡します。一度に有効なのは、これらのうち 1 つだけです。したがって、どちらが有効かを追跡するためのフラグも必要になりますが、これは実際にはコンテキストによって判断できます。
- システムの起動時に実行されるイベントや、「論理的な」起動時間を実際の起動時間に初期化する他のメカニズムも必要になると思います。
- ワークステーションがロックされている場合、現在の時刻から論理ブート時間を減算し、これを累積稼働時間として保存します。
- ワークステーションのロックが解除されたら、現在の時刻から累積稼働時間を減算し、これを論理起動時間として保存します。
- 要求に応じて、現在の時刻から論理的な起動時間を減算し、これを「実際の」稼働時間として報告します。(これにより、PC がロック解除された合計時間がわかります。)
例えば、
- 午前 9 時にハード ブートを実行すると、論理的なブート時間として午前 9 時が保存されます。
- 正午にマシンをロックすると、累積稼働時間として 3 時間 (正午 - 午前 9 時) が節約されます。
- 午後 1 時にマシンのロックを解除すると、論理的な起動時間として午前 10 時 (午後 1 時 - 3 時間) が節約されます。
- 午後 6 時の稼働時間を要求すると、8 時間
(午後 6 時 - 午前 10 時 = (正午 - 午前 9 時) + (午後 6 時 - 午後 1 時)) が報告されます。
スリープおよびウェイク時にタスクを実行するようにトリガーする方法がわかったら、それを実行すると、まさに求めていた結果が得られます。(ただし、マシンをスリープ状態にするとロック タスクがトリガーされるため、ウェイク後にロック解除を要求するようにシステムが構成されていると想定します。)