特定のアプリだけが「応答なし」になって終了しても，Windows全体のフリーズとは限らない。
まず他のアプリ，マウス，タスクマネージャー及び通常の再起動が動くかを確認し，停止範囲を分ける必要がある。
Application Hang又はAppHangB1は，アプリが応答しなかった事実を示すが，それだけで原因となったDLL，セキュリティソフト又はハードウェアを確定する記録ではない。
第１ 結論
特定アプリだけの停止は，①未保存データと外部送信の成否確認，②発生時刻・アプリ版・操作の記録，③ApplicationログとWERの保全，④同じ条件での限定的な再現確認，⑤更新・修復・除外設定の順で調べる。
PC全体の強制終了は最後の手段である。
第２ アプリ停止とPC全体のフリーズを区別する
| 観測 | 暫定評価 |
|---|---|
| 他のアプリが動く | アプリ単位の停止を優先 |
| スタートメニューから正常再起動できる | その時点でWindowsの終了処理が動いていた |
| マウスもCaps Lockも遠隔接続も反応しない | Windows全体の停止（ハードハング）を優先して検討 |
| 再起動後にEvent 41・6008だけがある | 前回の終了が正常でなかった記録であり原因は別途確認 |
同じ日にPC全体の停止とアプリ単位の停止が起きることもある。
二つを一つの原因で説明しようとせず，時刻ごとに別の事象として整理する。
第３ Application Hang及びAppHangB1の読み方
Windows Error Reportingは，アプリ障害，カーネル障害，応答しないアプリ等の問題をMicrosoftへ報告する仕組みである。
アプリがWindowsメッセージへ一定時間応答せず，利用者が操作すると「応答なし」と表示されることがある。
イベント名AppHangB1等は停止の分類に役立つが，障害モジュールの記載があるクラッシュと同じ精度で原因を示すとは限らない。
ハッシュやバケットが同じ事象の反復かを確認する。
第４ 発生直後に残す記録
①発生時刻，アプリ名，版数及び32ビット・64ビット
②直前に行った検索，読込み，保存又は送信
③未保存データと外部処理の成否
④タスクマネージャーでのCPU，メモリ及びディスク使用率
⑤Applicationログ，信頼性履歴及びWERのイベント名・バケット
ログやダンプには文書名，利用者名その他の秘密情報が含まれ得る。
共有前に対象範囲を絞り，原本と加工版を分ける。
第５ セキュリティソフトの関与をどう評価するか
監視DLLが対象プロセスへ読み込まれていた事実だけで，その製品を原因と断定してはならない。
①アプリとセキュリティソフトを最新にする
②同じ操作で再現するかを確認する
③ベンダーが案内する正式な除外又は互換性確認だけを限定的に行う
④保護機能を無期限に停止しない
⑤除外試験の前後でログと再現率を比較する
第６ 再インストールより先に行うこと
①アプリを正常終了し，既存データのバックアップを確認する
②公式の修復機能又は設定初期化の対象範囲を確認する
③同じデータだけで起きるか，新規データでも起きるかを分ける
④プラグイン，常駐監視及びネットワーク共有を一つずつ比較する
再インストールは設定やデータの所在が不明なまま行うと復旧を難しくする。
アプリ固有データのバックアップ方法を確認してから実施する。
第７ 正常再起動の記録
通常のスタートメニュー操作で再起動できた場合，イベントID 1074（ソースはUser32）及び6006等が記録されることがある。
これは少なくともその再起動時点でWindowsが通常の終了処理を開始できたことを示し，強制電源断後のEvent 41・6008とは区別できる。
第８ メーカー又は開発元へ伝える事項
①アプリ版，Windows版，発生時刻及び再現手順
②イベント名，バケットID及びハング署名
③特定データだけで起きるか
④セキュリティソフト名・版と正式な除外試験の結果
⑤PC全体の強制終了を伴ったか否か
原因を断定した表現ではなく，観測事実と推論を分けて伝えると，開発元が同型事象を照合しやすい。
第９ 本記事の限界
ハングダンプ又は開発元の解析がなければ，待機先のスレッド，DLL又はI/Oを確定できない場合がある。
本記事は安全な一次切分けと証拠保全を目的とする。
第１０ 出典・参考資料
Microsoft：Windows Error Reporting