What Is AppTermFailureEvent in Windows 11? 40 ARM64 Records Investigated

I checked Windows Error Reporting on a Surface Pro 11 and found 40 AppTermFailureEvent rows. Those rows contained only 6 unique ReportId values, and not one row had an AppName or AppPath field identifying the failed program.

The short answer is that AppTermFailureEvent is an event name used by Windows Error Reporting, not the name of an executable. Seeing 40 Event ID 1001 rows does not prove that 40 independent application failures occurred. In this sample, each ReportId appeared 6 or 7 times.

I chose this question after the exact query apptermfailureevent appeared in Search Console. My earlier event-log and WER audit admitted that I had almost treated the WER event name as an application name, but it stopped there. It did not answer what the rows counted, whether duplicates existed, or whether the responsible application could actually be recovered from them. This run is the focused follow-up.

Test system and input

I collected fresh data on 2026-08-13 JST from a Microsoft Surface Pro, 11th Edition. It has a Snapdragon X Elite X1E80100 with 12 cores and 12 logical processors, plus 33,893,933,056 bytes of memory. The operating system was Windows 11 Pro 25H2, ARM64, build 26200.8875.

The collector ran under ARM64 Python 3.12.10. It invoked Windows PowerShell 5.1.26100.8875, and the powershell.exe file version was 10.0.26100.8875. I also read its PE header: the Machine value was 0xAA64, confirming that this measurement path used the native ARM64 executable rather than an x64 process under emulation.

The input was the newest 300 Event ID 1001 records from provider Windows Error Reporting in the Application log. After 1 warmup query, the script fixed the EventRecordID range at 263315 through 263689. All 5 measured rounds then read only that immutable range, so a newly written event could not slide the input window between runs.

This was the command:

python scripts\appterm_failure_event_probe.py `
  --max-events 300 `
  --warmups 1 `
  --rounds 5 `
  --output .bench\appterm-failure-event-2026-08-13.json

The script reports the minimum, median, maximum, and population standard deviation of wall time. More importantly, it verifies comparability with both the record count and a SHA-256 digest of the normalized snapshot. The normalized form includes timestamps, EventRecordID values, and relevant WER fields. Raw report GUIDs and local paths are not written to the result; they are replaced or represented by digests.

All 5 rounds read the same 300 records

The measured times are below. This was not intended as a PowerShell performance contest. Repetition was a guard against quietly comparing different event windows.

The minimum was 2.577420 seconds, the median was 2.700755 seconds, the maximum was 2.961219 seconds, and the population standard deviation was 0.132831 seconds. Every round produced the SHA-256 value 545eb7a0b97cc0a4746f683af109dd608a2cf7cbf56e7e7d7018c7b104c588a5. Every count was also 300. The later grouping result therefore did not come from a moving "latest records" window.

Across those 300 records, the EventName distribution was LiveKernelEvent 161, BlueScreen 91, AppTermFailureEvent 40, APPCRASH 5, BEX64 1, MoAppCrash 1, and crashpad_log 1. The rest of this investigation concerns only the 40 AppTermFailureEvent rows.

40 rows represented 6 ReportId values

The 40 target rows were written from 05:09:02 through 07:24:26 JST on 2026-08-13. Grouping by ReportId produced 6 groups. Their row counts were 6, 6, 7, 7, 7, 7, or a mean of 6.667 raw rows per report identifier.

There were 0 rows with a missing ReportId. It would still be too strong to relabel those 6 report identifiers as 6 user-visible crashes. One user action may result in more than one report, and some reports may describe failures the user never noticed. The measured statement is narrower: the 40 raw rows collapsed to 6 WER report identifiers.

The duplicates were not byte-for-byte copies. ReportStatus was 2049 on 7 rows and 2051 on 33 rows. Across the 6 unique reports, the attachment references contained 6 .kdmp files, 8 .txt files, 8 .xml files, 2 .csv files, and 1 .log file. That pattern is consistent with multiple WER processing or storage updates for the same identifier, but this test did not prove why Windows emitted each additional Event ID 1001 row.

This distinction matters when scripts alert on event counts. A rule that simply counts AppTermFailureEvent rows would have reported 40. A rule grouping by ReportId would have reported 6. Neither number should be called the number of application crashes without a clearly documented definition and further correlation.

The 40 rows did not identify an application

To look for a responsible executable, the probe converted each event's XML EventData into a dictionary keyed by field name. The result was unusually sparse. Problem-signature fields P1 through P10 were blank on all 40 rows. The AppName field appeared on 0 rows, and AppPath also appeared on 0 rows. Every StorePath belonged to the family Kernel_0_0_00000000_<guid>, which did not expose an executable name either.

Microsoft's application or service crash troubleshooting guidance begins with Application Error Event ID 1000. That event can contain the faulting application name, faulting module, and path. Microsoft's Windows Error Reporting documentation, by contrast, shows Event ID 1001 as report information: Report Id, Bucket ID, Event Name, and the event-specific parameters P1 through P10.

There were 7 Application Error Event ID 1000 rows in the same 05:09:02 through 07:24:26 time window. All 7 had AppName and AppPath. It was tempting to copy one of those names onto an AppTermFailureEvent, especially when timestamps were nearby.

I did not do that. The probe compared IntegratorReportId on the Event ID 1000 side with ReportId on the Event ID 1001 side and found 0 exact matches. Temporal proximity alone is not a safe join key in a busy Application log. Those 7 named failures may be interesting separately, but this run provides no defensible mapping from them to the 6 AppTermFailureEvent report identifiers.

That failed correlation is as useful as the successful grouping. It prevents a plausible-looking but unsupported answer to "what application was it?" In this data, the honest answer is that the executable cannot be identified from the target Event ID 1001 rows.

Direct ReportQueue inspection failed

The StorePath values referred to 6 distinct ReportQueue directories, one for each unique report identifier, and all 6 directories existed. The attachment lists suggested that report data was present: there were .kdmp, .xml, .txt, .csv, and .log references.

I then tried to inspect those directories under normal user privileges. Every one of the 6 attempts returned access denied. I did not rerun the probe as administrator, and I did not open the dumps or parse a Report.wer file. I therefore cannot claim that elevation would reveal an application name, that the dump files are equivalent, or that each dump corresponds to a distinct user-visible incident.

The collector deliberately records the failure instead of silently treating an unreadable directory as empty. It also avoids broad exception handling: a missing path, access denial, and successful listing are counted separately. That behavior is important because "no attachments" and "attachments could not be read" are not the same finding.

Microsoft's Get-WinEvent documentation covers the underlying query mechanism. The new script adds the parts I needed for this question: a fixed record window, repeated snapshot hashing, grouping by report identifier, field-presence checks, and exact ID 1000-to-1001 correlation.

A conditional answer

On this Windows 11 ARM64 machine, AppTermFailureEvent was a WER event name, not an application name. I would not treat 40 rows as 40 crashes. Deduplicating by ReportId reduced them to 6 report identifiers, with each identifier repeated 6 or 7 times.

The second part remains unresolved. None of the 40 rows supplied an application name, application path, or populated problem signature. The 7 Event ID 1000 rows in the same time range had names and paths, but their report identifiers produced 0 exact matches. Direct inspection of all 6 ReportQueue directories failed with access denied.

So the practical sequence is: query Event ID 1001, group repeated rows by ReportId, and then look for an exactly correlated Event ID 1000 or other evidence before naming an executable. Do not infer an application from the word "App" in AppTermFailureEvent, and do not join unrelated records merely because their timestamps are close. At least in this measured sample, there was no application called AppTermFailureEvent and no supported way to name the responsible executable from those 40 rows alone.