Windows サービスのウォッチドッグ タイマーに関する別の質問への回答に非常に興味があります (こちらを参照)。その答えは次のように述べています。
別のスレッドで実行されている内部ウォッチドッグ システムも使用しました。そのスレッドは、ログ出力やトグル イベントなどのアクティビティについてメイン スレッドを調べます。アクティビティが見られない場合、サービスはハングしていると見なされ、サービスをシャットダウンします。
この場合、停止したサービスを自動再起動するように Windows を構成すると、問題が解決する可能性があります (内部ロジックのバグでない限り)。
また、私が使用しているサービスには、ログに書き込まれるテキスト ログがあります。さらに、「少しだけスリープ」しようとしているサービスについては、次のウェイクアップの時間を記録します。MTAIL を使用してログの出力を監視しています。」
別のスレッドで実行されている内部ウォッチドッグを使用する方法のサンプルコードを誰か教えてください.
本当にありがとうございました。
私は、監視しているプロセスのスレッドとしてウォッチドッグを実行するのが好きではありません。つまり、何らかの理由でプロセス全体がハングした場合、ウォッチドッグは機能しません。
ウォッチドッグはハードウェアの世界から持ち出されたアイデアであり、彼らはそれを正しかった. 可能な限り単純な外部回路を使用してください (したがって、正しいことが証明できます)。典型的なウォッチドッグは単純にタイマーを実行し、タイマーが切れる前にプロセスが何かを実行しなかった場合 (ウォッチドッグが監視していたメモリ位置へのアクセスなど)、すべてがリセットされました。ウォッチドッグが「キック」されると、タイマーが再起動します。
ウォッチドッグをキックするプロセスの行為は、そのプロセスを即時終了から保護しました。
私のアドバイスは、イベント (ファイル更新時間の変更など) を監視するだけの非常に単純なスタンドアロン プログラムを作成することです。そのイベントが必要な時間内に発生しなかった場合は、監視されているプロセスを強制終了します (そして、Windows に再起動させます)。
次に、監視対象のプログラムにそのファイルを定期的に書き換えさせます。
ファイルの lastwritetime を定期的に変更する以外に考慮すべき他の方法は、適切なパフォーマンス カウンターまたは WMI オブジェクトを作成することです。ビルドインフラストラクチャの後半で行います。「トリック」は、監視されているサービスで意味のある作業ユニットを見つけ、ユニットが終了するたびに「ハートビート」をパルスすることです。
ファイル アプローチに対する WMI やパフォーマンス カウンターの利点は、多数の専門的な MIS/管理ツールから見えるようになることです。これにより、多くの価値を追加できます。
障害が発生した場合にサービスのプロパティから自己再起動するように構成できます
Services -> right-click your service -> Properties -> First failure : restart the service -> Second failure : restart the service -> Subsequent failure : restart