AppTermFailureEvent は何のアプリ？ Windows 11 ARM64で40件を追った
この記事の見出し
Surface Pro 11 の Windows Error Reporting を実際に調べると、AppTermFailureEvent は40行あった。しかし、ユニークな ReportId は6個だけで、落ちたアプリ名を示す AppName と AppPath は1行にも無かった。
先に結論を書くと、AppTermFailureEvent は実行ファイル名ではなく、WER が記録したイベント名だ。イベント ID 1001 の検索結果に40行見えたからといって、40個のアプリ障害が起きたとは数えられない。今回の範囲では同じ ReportId が6回または7回ずつ繰り返される形だった。
この疑問を選んだきっかけは、Search Console に apptermfailureevent という検索語が出ていたことである。以前のイベントログとWERを調べた記事では、この文字列をアプリ名のように読みかけて間違った、と記録している。では何を数えていて、どこまでアプリを特定できるのか。そこが未回答のままだった。
測定した環境
2026-08-13 JST に、手元の Surface Pro, 11th Edition で新しく取得した。CPU は Snapdragon X Elite X1E80100、12コア・12論理プロセッサ、メモリは33,893,933,056バイト。OS は Windows 11 Pro 25H2、ビルド26200.8875のARM64環境だった。
収集スクリプトはARM64版Python 3.12.10から起動した。内部で呼ぶWindows PowerShellは5.1.26100.8875、powershell.exeのファイルバージョンは10.0.26100.8875である。PEヘッダーも確認し、Machineは0xAA64だったため、測定経路がARM64ネイティブであることも記録した。
入力はApplicationログにあるProvider Windows Error Reporting、イベントID 1001の新しい順300件。最初の1回をwarmupにして、その時点のEventRecordID 263315〜263689を固定した。以後の5 roundsは同じ窓だけを読み、途中で新しいイベントが増えても比較対象がずれないようにしている。
実行コマンドは次の通り。
python scripts\appterm_failure_event_probe.py `
--max-events 300 `
--warmups 1 `
--rounds 5 `
--output .bench\appterm-failure-event-2026-08-13.json
集計は実行時間のminimum、median、maximum、population standard deviationを使った。比較成立性は、各roundのレコード件数と、時刻・EventRecordID・WERフィールドを正規化したsnapshotのSHA-256で確認している。個別のReportIdとローカルパスは、そのままJSONへ残さずダイジェストまたは置換済みの形にした。
5回とも同じ300件を読めた
5 roundsを手元で測った結果は次のようになった。処理時間の速さを競う測定ではなく、同じ入力を再現できているかを確かめるための繰り返しだ。
| round | wall time | record count | snapshot |
|---|---|---|---|
| 1 | 2.961219秒 | 300件 | 同一 |
| 2 | 2.703302秒 | 300件 | 同一 |
| 3 | 2.623660秒 | 300件 | 同一 |
| 4 | 2.577420秒 | 300件 | 同一 |
| 5 | 2.700755秒 | 300件 | 同一 |
minimumは2.577420秒、medianは2.700755秒、maximumは2.961219秒、population standard deviationは0.132831秒だった。全roundのsnapshot SHA-256は545eb7a0b97cc0a4746f683af109dd608a2cf7cbf56e7e7d7018c7b104c588a5で一致した。件数も毎回300件なので、これ以降の差は取得中にログ窓が動いたせいではない。
300件をEventName別に数えると、LiveKernelEvent 161件、BlueScreen 91件、AppTermFailureEvent 40件、APPCRASH 5件、BEX64 1件、MoAppCrash 1件、crashpad_log 1件だった。今回見るのは、このうち40件だけである。
40行は6個のReportIdだった
AppTermFailureEvent 40行の記録時刻は、2026-08-13 JSTの05:09:02から07:24:26まで。ReportIdで分類すると6グループになり、各グループの行数は6, 6, 7, 7, 7, 7だった。生の行数をユニークなレポート数で割ると、平均6.667行である。
| 見方 | 数 |
|---|---|
| Event ID 1001の生レコード | 40件 |
| ユニークなReportId | 6個 |
| 1つのReportIdに属する行 | 6件または7件 |
| 生レコード / ReportId | 平均6.667行 |
ReportIdの欠落行は0件だった。ここで「6回クラッシュした」と言い換えるのも早い。分かったのは、40行が6個のWERレポート識別子にまとまることまでだ。1つのユーザー操作が複数レポートを作る可能性や、逆にユーザーが気づかなかった失敗もあるため、ReportId数を体感上の障害回数とは断定していない。
重複行は完全なコピーでもなかった。ReportStatusは2049が7行、2051が33行に分かれている。添付ファイル欄をユニークなReportId単位で集めると、.kdmp 6個、.txt 8個、.xml 8個、.csv 2個、.log 1個が参照されていた。WERの受付や保存段階が更新されるたび、同じReportIdについて別の1001行が積み重なったように見えるが、この動作理由までは今回証明していない。
何のアプリかは、この40行から分からなかった
アプリを探すため、各行のEventDataをXMLから名前つきの辞書へ戻した。結果は厳しい。問題シグネチャのP1〜P10は40行すべて空、AppNameフィールドは0件、AppPathフィールドも0件だった。StorePathも40行すべてKernel_0_0_00000000_<guid>という系統で、ファイル名らしい手がかりは無い。
Microsoftのアプリケーションまたはサービスのクラッシュを調べる手順では、実行ファイル名、障害モジュール、パスを持つApplication ErrorのイベントID 1000を先に見る構成になっている。一方、Windows Error Reportingの説明にある1001の例は、Report Id、Bucket ID、Event Name、P1〜P10などのレポート情報が中心だ。
同じ05:09:02〜07:24:26の時間窓には、Application ErrorのイベントID 1000が7件あり、7件ともAppNameとAppPathを持つ。ここだけ見ると名前を移せそうに思えた。ところが、1000側のIntegratorReportIdと1001側のReportIdを完全一致で照合した結果は0件である。時刻が近いだけの別イベントを結びつけるのは危険なので、この7件の実行ファイル名を6個のAppTermFailureEventへ割り当てなかった。
ReportQueueを直接読む試みも失敗した
6個のユニークなReportIdが指すReportQueueディレクトリは、6個とも存在した。そこには.kdmpや.xmlへの参照もある。ならば中のReport.werを開けば分かるかもしれない、と試したが、通常権限では6個すべてaccess deniedになった。
この失敗を管理者権限でやり直してはいない。ダンプ解析もしておらず、.kdmpの内容が同じか、どのプロセスを含むかも未測定だ。権限を上げれば必ずアプリ名が得られる、という主張もできない。
Get-WinEvent自体の再実行方法は公式のGet-WinEventドキュメントで確認できる。今回追加したスクリプトは、行数だけでなくReportIdの重複、フィールドの有無、1000との完全一致まで一度に出す。AppTermFailureEventを見つけたとき、まず「何行あるか」から「何個のReportIdか」へ視点を変えるための道具にした。
条件つきの答え
AppTermFailureEventとは何か、と聞かれたら、手元の結果では「Windows Error Reportingが使うイベント名であり、アプリ名ではない」が答えになる。40行を40回のクラッシュとして数えるのも避けたほうがよい。まずReportIdで重複を除くと、今回は6個まで減った。
ただし、その6個がどのアプリだったかは未解決だ。ID 1001の40行には名前もパスも問題シグネチャも無く、同じ時間帯のID 1000ともReportIdの一致は得られていない。通常権限でReportQueueを読もうとした試みも失敗に終わっている。
確認できた範囲と、確認できなかった範囲を区別できる結果になった。イベントビューアーでこの語を見たときは、名前からアプリを推測せず、ReportIdの重複を除き、完全に対応するID 1000や追加資料があるかを別途探す。少なくとも「AppTermFailureEventというアプリが落ちた」ではなかった。