同一構成の複数台ワークステーションが毎週金曜だけフリーズする問題をイベントログで突き止める
「特定の曜日だけ、複数台のワークステーションが一斉にフリーズする」という再現性のある障害は、原因不明のまま「とりあえず再起動」で凌いでしまいがちです。この記事では、イベントログを使って原因の当たりをつけるまでの調査プロセスをまとめます。
症状
同一機種・同一構成のワークステーション数台が、決まって週の後半(特に金曜午後)にフリーズし、リモート管理機能(AMT等)経由での強制再起動でしか復旧しない状態が繰り返し発生していました。マウスもキーボードも反応せず、画面も固まったまま応答しません。
調査: イベントログの「空白時間」に注目する
対象機のSystem/Applicationイベントログを確認したところ、フリーズしていたと思われる時間帯は、両方のログに一切イベントが記録されていませんでした。BSOD(ブルースクリーン)を示すBugcheckコードは記録されておらず、再起動時には「異常シャットダウン」を示すイベント(Kernel-Power Event 41、EventLog 6008)のみが残っていました。Event 41は「正常にシャットダウンせず再起動した」ことを示すイベントです。BSODの記録がなく、フリーズ中のログも空白であることから、OSがクラッシュ処理に入る前に無応答になり、強制再起動で復旧したと推測できます(ログの空白だけでは断定できないため、ほかの手がかりと合わせて判断します)。
もう一つの手がかり: GPU側のエラー
再起動直後のログを詳しく見ると、Windowsのハードウェアエラー記録(ソース名: WHEA-Logger)に、GPUが接続されたPCIeの「訂正可能なエラー」が1件残っていることが分かりました。単体では即座にフリーズの直接原因と断定できるものではありませんが、複数台で同じパターンが繰り返されている場合、共通するハードウェア要因(GPU、電源、あるいは特定の負荷パターン)を疑う材料になります。
複数台での比較が有効
1台だけの調査では「たまたま」で片付けられがちですが、同一構成の複数台で全く同じログパターン(空白時間→Kernel-Power 41→GPU訂正可能エラー)が確認できたことで、個体差ではなく構成そのものに起因する問題である可能性が高いと判断できました。曜日や時間帯が偏っている場合は、その時間帯特有の負荷(バッチ処理、リモート接続の集中など)も合わせて確認すると絞り込みが進みます。
まとめ
原因不明のフリーズ調査では、まず「イベントログに空白時間がある」という事実を確認し、OSごと無応答になっていた可能性を考え、直前直後のログから間接的な手がかり(GPUエラー等)を拾い集めることが第一歩です。同一構成の複数台で発生しているなら、個体トラブルではなく構成起因を疑い、発生時間帯の共通パターンも合わせて洗い出しましょう。
■ この記事に関連するテンプレート
同じ構成の端末が複数台あると、機種・BIOS・ドライバーの差分を台帳に残しておくだけで、原因の切り分けが速くなります。端末の受け入れから配布までをNotionで管理するテンプレートを作りました。
まずは無料版で、使い方が合うかを確かめてみてください。
コメント