Windows Server 2008 R2でBSOD（0x0000007E）頻発：hmpalert.sys（HitmanPro/Sophos）原因の切り分けと対処

Windows Server 2008 R2 SP1で、直前まで安定していたのに年末頃からBSOD（ブルースクリーン）が連発し、イベントログにはBugCheck（バグチェック）0x0000007E（SYSTEM_THREAD_EXCEPTION_NOT_HANDLED）。ミニダンプ解析で原因ドライバーを絞り込み、hmpalert.sys（HitmanPro/Sophos）を疑うべきケースと現場での対処手順をまとめます。

まず押さえる：BugCheck 0x0000007E（SYSTEM_THREAD_EXCEPTION_NOT_HANDLED）の特徴

0x0000007Eは、カーネルモード（OSの中枢）で動いている「システムスレッド」が例外（アクセス違反など）を起こし、例外処理で回復できなかったときに発生しやすい停止コードです。環境によっては 0x1000007E と表示されることもありますが、見ている意味合いはほぼ同じです。

体感的には、アプリ不具合というより“ドライバー由来”の比率が高いのがポイントです。特にWindows Server 2008 R2のような世代のOSでは、次のような「常駐型・フィルタ型」のドライバーがトリガーになりやすい傾向があります。

カテゴリ	例	なぜ0x7Eに繋がりやすいか
セキュリティ（AV/EDR/防御系）	挙動監視、Exploit対策、ランサム対策	プロセス/メモリ/通信に割り込むため、互換性・競合の影響が大きい
ファイルシステムフィルタ	暗号化、DLP、バックアップ、監査	ファイルI/Oの経路に入るため、負荷増・競合・例外の影響が出やすい
ストレージ/RAID/HBA	RAIDドライバー、SAS/SATA、iSCSI	I/Oが詰まったときに例外が露見しやすく、連鎖的に落ちることがある
ネットワーク/仮想化	NIC、仮想スイッチ、フィルタ	パケット処理は割り込みが多く、古いドライバーだと不安定要因になりやすい

イベントログで最低限見るべき場所（原因の“時期”を確定させる）

「年末頃から急に」という条件は、とても重要です。発生開始日をできるだけ正確に出すために、イベントビューア（システムログ）で次のイベントを拾い、タイムラインを作ります。

イベント	よく見るID	確認ポイント
BugCheck	1001	停止コード、ダンプ保存先、発生時刻
予期しないシャットダウン	6008	障害の頻度と“本当に落ちている”回数の裏取り
Kernel-Power	41	電源断/強制再起動を含む広い観点の確認（UPS・電源系の切り分け）

結論：ミニダンプで「hmpalert.sys」が出るなら最優先で疑う

ご提示の条件（BugCheck 0x0000007Eでミニダンプ取得済み）で、解析結果の犯人候補として最も疑わしいのが hmpalert.sys です。これはHitmanPro / HitmanPro.Alert系のドライバーとして知られ、Sophos系のセキュリティ製品に同梱されるケースもあります。

サーバーが「直前まで正常だったのに、ある時期から急に頻発」する場合、ハード故障よりも直近で更新された常駐ドライバーが原因になっていることが多く、セキュリティ製品の自動アップデートは最初に疑うべき典型パターンです。

原因を“推測”から“確証寄り”に近づける：ミニダンプ解析の見方

ミニダンプ（.dmp）を開いて「どのモジュールが落ちたのか」を読むことで、原因の当たりを付けられます。深掘りするほど精度は上がりますが、現場ではまず短時間で判断できる観点を押さえるのが有効です。

最初に揃える情報（再発防止まで見据えた最低限）

情報	どこで確認	使いどころ
停止コード（0x0000007E）とパラメータ	イベントビューア / ダンプ解析	例外種別の方向性（アクセス違反等）を掴む
ミニダンプ（C:\Windows\Minidump）とMEMORY.DMP	サーバーのファイル	原因モジュール（IMAGE_NAME / MODULE_NAME）を特定、深掘り解析
直近の変更点	更新履歴、運用記録	「年末から」など時期と一致する変更を洗い出す
インストール済みセキュリティ製品の一覧とバージョン	プログラムと機能、管理コンソール	競合・サポート対象外バージョンを疑う
フィルタドライバーの一覧	fltmc	ファイルI/Oに割り込むドライバーを可視化（競合検討に有効）

更新履歴を素早く棚卸しする（“いつ変わったか”を特定する）

「年末頃から」の裏取りは、復旧後の再発防止で効きます。GUIで追うのが難しいときは、コマンドで一覧化すると早いです。

目的	コマンド例	補足
Windows更新の一覧	wmic qfe list brief /format:table	インストール日で並び替え、発生開始日と突合
インストール済みプログラム確認	wmic product get name,version	時間がかかることがあるため、保守時間に実行推奨
ドライバー一覧	driverquery /v	サードパーティの古いドライバーを見つけやすい

WinDbgで最低限やること（コマンド早見表）

WinDbg（Debugging Tools for Windows）でダンプを開き、まずは!analyze -vの結果を見ます。ここで hmpalert.sys が「IMAGE_NAME」「MODULE_NAME」「Probably caused by」などに登場するなら、優先度は一気に上がります。

コマンド	目的	見るポイント
!analyze -v	原因候補の全体像	IMAGE_NAME / MODULE_NAME / STACK_TEXT
lmvm hmpalert	ドライバー詳細確認	Timestamp、Company、File version（古いほど要注意）
kv	スタックの流れ	落ちる直前にどのドライバーが連鎖しているか
!thread	落ちたスレッドの状況	システムスレッドの文脈や待ち状態

例として、ダンプ解析でよく見る「判断に効く行」のイメージです（環境により表示は異なります）。

BugCheck 7E, { ... }
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
...
IMAGE_NAME:  hmpalert.sys
MODULE_NAME: hmpalert
...
STACK_TEXT:
...

hmpalert.sys（HitmanPro / Sophos系ドライバー）がクラッシュ要因になりやすい理由

hmpalert.sys は、攻撃緩和・挙動監視などの目的でOSの深い部分に介入するタイプのドライバーとして扱われます。こうしたドライバーは「守るために割り込む」設計上、次の条件で不安定化しやすくなります。

• OSが古く、最新の製品側が十分に検証しきれない（Windows Server 2008 R2は既にサポート終了のため、想定外の組み合わせが生まれやすい）
• 別のセキュリティ製品と機能が重複する（複数の防御ドライバーが同じポイントに介入し競合する）
• 月例パッチや製品の自動更新で“急に”表面化する（年末・月末・定期更新のタイミングと一致しやすい）

「年末頃から急に頻発」という条件は、ハード故障よりも更新・設定変更・自動配布と相性が良いサインです。まずは「いつから」「何が変わったか」を更新履歴と照合し、hmpalert.sysのバージョン変化を確認するのが近道です。

最短で復旧したいときの対処（優先順位つき）

サーバーでBSODが頻発している場合、原因究明より先にサービス継続が重要になることがあります。そこで、現場で実行しやすく、効果が出やすい順に並べます。

優先	対処	狙い	注意点
高	hmpalert.sysを提供している製品の更新	互換性バグ修正・競合回避	Windows Server 2008 R2対応状況を確認（サポート外なら更新で悪化する場合も）
高	更新で改善しなければ修復／アンインストール	原因ドライバーを除去して再発を止める	運用ポリシーに従い、代替策（別製品/ネットワーク制御等）を同時に検討
中	セーフモード起動で再現性確認	常駐ドライバー影響の切り分け	セーフモードで落ちない＝サードパーティ常駐が濃厚
中	BIOS/ファームウェア、チップセット、主要ドライバー更新	周辺ドライバーの古さを排除	ストレージ/NICは特に慎重に（保守手順・ロールバック準備）
低	メモリ/ディスクチェック（念のため）	ハード要因の除外	0x7Eでは“最後に”行うことが多いが、障害が長期化するなら実施

アンインストールや更新の前にやっておくと安全な準備

• 作業手順とロールバック手段を用意（スナップショット、バックアップ、インストーラ保管）
• 再起動が必要な前提で保守時間を確保（ドライバー更新はほぼ再起動が絡む）
• 同居しているセキュリティ製品があるなら、機能重複（Exploit対策/ランサム対策/ネットワークフィルタ）の有無を確認

「どの製品がhmpalert.sysを入れているのか」を確認する方法

環境により、HitmanPro.Alert単体の場合もあれば、Sophosなどの製品に同梱されている場合もあります。まずはファイルの実体とサービス登録を確認します。

確認方法	例	分かること
ファイルの場所	C:\Windows\System32\drivers\hmpalert.sys	ドライバーが存在するか、更新日時の目安
署名・プロパティ	ファイルのプロパティ > デジタル署名	発行元、バージョン、署名有無
フィルタ一覧	fltmc	ファイルI/Oに割り込むフィルタが見える（他製品との競合検討に有効）
ドライバー一覧	driverquery /v	ロード済みドライバー名・状態・パス

取得コマンド例（管理者権限で実行します）。

fltmc
driverquery /v /fo table
sc query type= driver

一時切り分けとしての「停止／削除」判断

「更新しても改善しない」「運用上すぐに止めたい」場合は、計画停止の保守時間内で、該当セキュリティ製品の一時停止やアンインストールを検討します。BSODの切り分けは、原因候補を外した状態で再発するかが最も強い証拠になります。

• まずは製品の保護機能の一部を無効化できるか確認（全停止が難しい環境向け）
• 次に製品の修復（Repair）や再インストールでドライバーファイルの整合性を回復
• それでも改善しなければアンインストール（競合やサポート外の可能性を強く疑う）

「hmpalert.sysが出た＝確定」ではない？判断を誤らないための見方

ダンプにhmpalert.sysが出た場合でも、理論上は「別の要因で破壊されたメモリにたまたま触れた被害者」になる可能性はゼロではありません。ただし、現場判断では次の条件が揃うほどhmpalert.sysが加害側である可能性が高くなります。

判断材料	強いサイン	補足
スタックトレース	落ちる直前のフレームにhmpalert.sysが連続している	他のドライバーより“最後の一押し”に近い
複数回のダンプ	毎回hmpalert.sysが出る	再現性が高いほど原因特定が容易
導入/更新タイミング	年末頃の更新と発生開始が一致	更新履歴と突合すると説得力が増す
競合の存在	他のAV/EDR/バックアップ/暗号化製品も常駐している	「防御ドライバーの多重化」は特に危険

併せてやると事故率が下がる“安定化”の基本（2008 R2世代向け）

原因がhmpalert.sysであっても、サーバー全体の土台が不安定だと別の停止コードに派生することがあります。再発防止の観点で、次の基本も一度は棚卸ししておくと安全です。

主要ドライバー／ファームウェアの更新方針を決める

• ストレージ（RAID/HBA）：最優先。BSOD時に巻き込まれやすいので、ベンダー推奨組み合わせを確認
• NIC：次点。チーミングやフィルタが絡むと不安定化しやすい
• BIOS/ファームウェア：マイクロコードや互換性改善が含まれることがある

ハード要因を短時間で除外する（必要なときだけ）

確認項目	目安	例
ディスク/RAID健全性	イベントログにI/Oエラー、再試行がないか	ベンダーツール、RAID管理ツール
ファイルシステム	整合性の破損がないか	chkdsk（計画停止が必要な場合あり）
OSファイル	システムファイルの破損がないか	sfc /scannow
メモリ	長期化・別コード併発時に実施	メモリ診断、交換テスト

ダンプが取れない／情報が足りない場合の設定（再発時に困らないために）

ダンプが取れているのは非常に良い状態ですが、運用中に「容量不足」「ページファイル不足」「設定が変わってミニダンプが消えた」などが起きると原因特定が一気に難しくなります。最低限、次を確認しておくと保険になります。

設定	推奨	理由
ダンプ種類	カーネルメモリダンプ（または自動メモリダンプ）	ミニダンプより情報が多く、解析精度が上がる
ページファイル	OSドライブに十分なサイズを確保	ダンプ書き出しに必要（不足するとダンプ欠落）
保存先	空き容量があるディスク	年末などログ増で逼迫しやすい

サポートへエスカレーションするなら、最初から揃えると早い材料

フォーラムや社内だけでは限界がある場合、ベンダーサポート（OS/セキュリティ製品/ハード）へ依頼した方が早いことがあります。その際、次を最初から添えると往復が減ります。

• ミニダンプ（可能なら複数回分）と、可能であればカーネルメモリダンプ
• イベントログ（System/Application）
• インストール済み更新プログラムと、発生開始日（「いつから」を日付で）
• セキュリティ製品名・バージョン・ポリシー変更履歴
• fltmc、driverquery /vの結果

まとめ：0x0000007Eは“ドライバー例外”が定石、hmpalert.sysは最優先で潰す

Windows Server 2008 R2でBSOD（ブルースクリーン）が頻発し、BugCheck（バグチェック）0x0000007E（SYSTEM_THREAD_EXCEPTION_NOT_HANDLED）が記録され、ミニダンプ解析でhmpalert.sysが指摘される場合、HitmanPro / Sophos系セキュリティ製品のドライバーがクラッシュ要因になっている可能性が高い状況です。まずは製品の更新、改善しなければ修復・アンインストールでの切り分けを最優先に実施し、併せてフィルタドライバー確認や主要ドライバー更新などの安定化策で再発防止まで進めるのが、最短で“止血”しつつ確度も上げられる進め方です。