A Benign Fail-Fast Crash on Windows: What the EDR Sensor and the Windows Fault Record Captured
What a leading commercial EDR platform and the host's own Windows logs recorded when a benign lab PowerShell process was made to fail-fast once on one Windows lab host, in the 1:25:38 AM PT run.
A plain-English, vendor-neutral account of what a leading commercial endpoint detection and response (EDR) platform, and the host's own Windows logs, recorded on one Windows lab host when a harmless lab-written PowerShell process was made to crash once on purpose. EDR is security software that watches each computer and records what programs do. The product is not named.
The claim
"On one Windows lab host at 1:25 AM PT on 2026-10-21, a lab-authored benign PowerShell process was made to fail-fast once. It exited with fault code 0x80131623. A leading commercial EDR platform recorded the process starting and ending, with that exit code. The host's Application log recorded an Application Error event (Event ID 1000) for the same process ID and fault code. During the crash, the operating system started its error-reporting service on demand, and the service had stopped again about two minutes later; no operator started or stopped it. A check for alerts on this host, made at 1:56 AM PT (about 31 minutes after the test), returned none. The host's process-creation log recorded the process starting, but its command-line field was empty. No .NET Runtime 1026 event was written."
Antivirus disclosure
The operating system's built-in antivirus was disabled at the host baseline for this run, with the EDR sensor under test unchanged. The fully-disabled state was confirmed by an in-run state check recorded in the baseline frame.
Disclosures
- The operating system's built-in antivirus was disabled at the host baseline for this run, with the EDR sensor under test unchanged. The fully-disabled state was confirmed by an in-run state check recorded in the baseline frame.
- At the baseline, the operating system's error-reporting service was stopped and set to start manually. During the crash, the operating system started it on demand, and it had stopped again about two minutes later; no operator started or stopped it. Because the service was running when the fault record was written, this run cannot show whether that record is also written while the service stays stopped. That question was set out before the run, and its answer for this run is undetermined.
- Process-creation auditing was turned on, and the host's process-creation log (Windows Security event 4688) recorded the process starting, but its command-line field was empty on every sampled event. That log therefore backs up the process start and the parent-child links, not the command that was run.
- The evidence check looked for both the Application Error event (Event ID 1000) and the .NET Runtime event (Event ID 1026). Only the Application Error event was present; no .NET Runtime 1026 event was written.
- Process-termination auditing (Windows Security event 4689) was not turned on, and Sysmon was not available, so neither could serve as a further record of the process exit.
- An additional PowerShell child process was recorded by the host log; its purpose is unknown.
- Restore removed the lab folder, and a separate read-only check confirmed the folder was gone and the security services were unchanged. The crash also produced operating-system crash-report data outside the lab folder; a read-only check about seven hours later found none remaining. It was not removed by the test operator. The later crash-report check did not list hidden or system files and did not look inside subfolders. When the data disappeared, and what removed it, is not known.
Environment
One Windows lab host with a leading commercial EDR platform's sensor under test. Identifiers that could create exposure are not shown. Methods line: tested against a leading commercial EDR platform; vendor not named.
Method and commands
In the 1:25:38 AM PT run, a host script first recorded a read-only baseline. It confirmed that the EDR sensor's service was running and set to start automatically, that the built-in antivirus was fully disabled, and that the operating system's error-reporting service was stopped. It also recorded that process-creation auditing was on and process-termination auditing was off.
The host script then launched a separate lab-written PowerShell script once, as a child process. That script used a "fail-fast" call, which ends a process at once with a fault code instead of letting it shut down normally. The action window ran from 1:25:40 to 1:25:43 AM PT. The script then read back the host's Application and Security logs.
Afterwards, the lab folder was removed, and a separate read-only check followed about ten seconds later. No service was started, stopped or changed by hand, and the EDR sensor was never stopped, disabled or reconfigured. No exploit code was used.
What was recorded (the 1:25:38 AM PT run)
Observed
- The child process exited with fault code 0x80131623.
- A leading commercial EDR platform recorded the process starting and ending, with that exit code. The operating system's built-in antivirus was disabled at the host baseline for this run, with the EDR sensor under test unchanged. The fully-disabled state was confirmed by an in-run state check recorded in the baseline frame.
- The host's Application log recorded an Application Error event (Event ID 1000) at 1:25:41 AM PT for the same process ID (0xd84) and the same fault code. The excerpt below is quoted from the action frame; its event time is shown in UTC.
- During the crash, the operating system started its error-reporting service on demand, and the service had stopped again about two minutes later; no operator started or stopped it.
- The host's process-creation log recorded the process starting, but its command-line field was empty.
- No .NET Runtime 1026 event was written.
- A check for alerts on this host, made at 1:56 AM PT (about 31 minutes after the test), returned none. The operating system's built-in antivirus was disabled at the host baseline for this run, with the EDR sensor under test unchanged. The fully-disabled state was confirmed by an in-run state check recorded in the baseline frame.
What this does and does not show
For this one crash, two independent records agree: the EDR sensor's process records and the host's own Application Error event name the same process and the same fault code. The claim goes no further than that.
The run does not show whether the Windows fault record is written while the error-reporting service stays stopped, because the operating system started that service during the crash. The sensor's exit record was seen in one run only, so it says nothing about other runs. Restore was checked for the lab folder and the security services only; other host state was not compared. The page makes no detection, prevention or coverage claim.
Host evidence: rendered terminal output
These frames are rendered from the host transcripts, not live screenshots. Labelled masks in square brackets stand in for identifiers. Bracketed tokens are redactions. The frames are excerpts of the transcripts, and one status label was renamed for clarity; the recorded values are as captured. Times in the frames are in UTC (08:25 UTC is 1:25 AM PT). The operating system's built-in antivirus was disabled at the host baseline for this run, with the EDR sensor under test unchanged. The fully-disabled state was confirmed by an in-run state check recorded in the baseline frame.
Baseline
Rendered terminal output
Host label: [HOST-LABEL]
---
FRAME: BASELINE
=== BASELINE (steady state) ===
2026-10-21T08:25:38.1730587+00:00
Name : [EDR-SENSOR-SERVICE]
Status : Running
StartType : Automatic
Name : [EDR-SENSOR-SERVICE]
Status : Running
StartType : Automatic
AMRunningMode : Not running
AntivirusEnabled : False
RealTimeProtectionEnabled : False
AMServiceEnabled : False
AntispywareEnabled : False
Name : [OS-ERROR-REPORTING-SERVICE]
State : Stopped
StartMode : Manual
ProcessId : 0
=== BASELINE read-only fallback-availability checks (enable nothing) ===
System audit policy
Category/Subcategory Setting
Detailed Tracking
Process Termination No Auditing
System audit policy
Category/Subcategory Setting
Detailed Tracking
Process Creation Success
=== BASELINE error-reporting report-queue inventory (READ-ONLY, pre-run) — C3 ===
=== BASELINE LocalDumps / crash-dump setting presence (READ-ONLY; do not change) ===
LocalDumpsKeyExists=False
Action and observation
Rendered terminal output
Host label: [HOST-LABEL]
---
FRAME: ACTION + OBSERVE
=== ACTION: benign FAIL-FAST crash (fires from baseline; operator starts NO service) ===
2026-10-21T08:25:40.0458682+00:00
ACTION_WINDOW_START_UTC=2026-10-21T08:25:40.0545950Z
FAIL-FAST child PID=3460 PID_HEX=0xd84 ExitCode=-2146232797 (expect nonzero; predicted -2146232797 / 0x80131623; any other nonzero = observed)
EXIT: NONZERO_OBSERVED ExitCode=-2146232797
=== IMMEDIATELY POST-CRASH: [OS-ERROR-REPORTING-SERVICE] state + PID (READ-ONLY) ===
Name : [OS-ERROR-REPORTING-SERVICE]
State : Running
StartMode : Manual
ProcessId : 3376
=== OBSERVE WITNESS 1 (EDR sensor telemetry) -- ALWAYS Witness 1, never Witness 2 ===
=== OBSERVE WITNESS 2 (NATIVE Windows log -- must be a native log, never the EDR) ===
ACTION_WINDOW_END_UTC=2026-10-21T08:25:43.8401658Z
TimeCreated : 10/21/2026 8:25:41 AM
Id : 1000
ProviderName : Application Error
ProcessId : 0
FullMsg : Faulting application name: powershell.exe, version: 10.0.20348.2849, time stamp: 0xfcfdfb0c
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0x80131623
Fault offset: 0x00007ffef9cc02cf
Faulting process id: 0xd84
Faulting application start time: 0x01dd6135c1d0a341
Faulting application path: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Faulting module path: unknown
Faulting package full name:
Faulting package-relative application ID:
TimeCreated : 10/21/2026 8:25:41 AM
Id : 4688
FullMsg : A new process has been created.
Creator Subject:
Security ID: S-1-5-18
Account Name: [MACHINE-ACCOUNT]
Account Domain: WORKGROUP
Logon ID: 0x3E7
Target Subject:
Security ID: S-1-0-0
Account Name: -
Account Domain: -
Logon ID: 0x0
Process Information:
New Process ID: 0xbbc
New Process Name: C:\Windows\System32\[OS-ERROR-REPORTING-FAULT-EXE]
Token Elevation Type: TokenElevationTypeDefault (1)
Mandatory Label: S-1-16-16384
Creator Process ID: 0xd84
Creator Process Name: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Process Command Line:
Token Elevation Type indicates the type of token that was assigned to the new process in accordance with
User Account Control policy.
Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User
Account Control is disabled or if the user is the built-in Administrator account or a service account.
Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used
when User Account Control is enabled and the user chooses to start the program using Run as
administrator. An elevated token is also used when an application is configured to always require
administrative privilege or to always require maximum privilege, and the user is a member of the
Administrators group.
Type 3 is a limited token with administrative privileges removed and administrative groups disabled.
The limited token is used when User Account Control is enabled, the application does not require
administrative privilege, and the user does not choose to start the program using Run as administrator.
TimeCreated : 10/21/2026 8:25:41 AM
Id : 4688
FullMsg : A new process has been created.
Creator Subject:
Security ID: S-1-5-18
Account Name: [MACHINE-ACCOUNT]
Account Domain: WORKGROUP
Logon ID: 0x3E7
Target Subject:
Security ID: S-1-0-0
Account Name: -
Account Domain: -
Logon ID: 0x0
Process Information:
New Process ID: 0x608
New Process Name: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Token Elevation Type: TokenElevationTypeDefault (1)
Mandatory Label: S-1-16-16384
Creator Process ID: 0xd84
Creator Process Name: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Process Command Line:
Token Elevation Type indicates the type of token that was assigned to the new process in accordance with
User Account Control policy.
Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User
Account Control is disabled or if the user is the built-in Administrator account or a service account.
Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used
when User Account Control is enabled and the user chooses to start the program using Run as
administrator. An elevated token is also used when an application is configured to always require
administrative privilege or to always require maximum privilege, and the user is a member of the
Administrators group.
Type 3 is a limited token with administrative privileges removed and administrative groups disabled.
The limited token is used when User Account Control is enabled, the application does not require
administrative privilege, and the user does not choose to start the program using Run as administrator.
TimeCreated : 10/21/2026 8:25:40 AM
Id : 4688
FullMsg : A new process has been created.
Creator Subject:
Security ID: S-1-5-18
Account Name: [MACHINE-ACCOUNT]
Account Domain: WORKGROUP
Logon ID: 0x3E7
Target Subject:
Security ID: S-1-0-0
Account Name: -
Account Domain: -
Logon ID: 0x0
Process Information:
New Process ID: 0x1310
New Process Name: C:\Windows\System32\conhost.exe
Token Elevation Type: TokenElevationTypeDefault (1)
Mandatory Label: S-1-16-16384
Creator Process ID: 0xd84
Creator Process Name: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Process Command Line:
Token Elevation Type indicates the type of token that was assigned to the new process in accordance with
User Account Control policy.
Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User
Account Control is disabled or if the user is the built-in Administrator account or a service account.
Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used
when User Account Control is enabled and the user chooses to start the program using Run as
administrator. An elevated token is also used when an application is configured to always require
administrative privilege or to always require maximum privilege, and the user is a member of the
Administrators group.
Type 3 is a limited token with administrative privileges removed and administrative groups disabled.
The limited token is used when User Account Control is enabled, the application does not require
administrative privilege, and the user does not choose to start the program using Run as administrator.
TimeCreated : 10/21/2026 8:25:40 AM
Id : 4688
FullMsg : A new process has been created.
Creator Subject:
Security ID: S-1-5-18
Account Name: [MACHINE-ACCOUNT]
Account Domain: WORKGROUP
Logon ID: 0x3E7
Target Subject:
Security ID: S-1-0-0
Account Name: -
Account Domain: -
Logon ID: 0x0
Process Information:
New Process ID: 0xd84
New Process Name: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Token Elevation Type: TokenElevationTypeDefault (1)
Mandatory Label: S-1-16-16384
Creator Process ID: 0xa18
Creator Process Name: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Process Command Line:
Token Elevation Type indicates the type of token that was assigned to the new process in accordance with
User Account Control policy.
Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User
Account Control is disabled or if the user is the built-in Administrator account or a service account.
Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used
when User Account Control is enabled and the user chooses to start the program using Run as
administrator. An elevated token is also used when an application is configured to always require
administrative privilege or to always require maximum privilege, and the user is a member of the
Administrators group.
Type 3 is a limited token with administrative privileges removed and administrative groups disabled.
The limited token is used when User Account Control is enabled, the application does not require
administrative privilege, and the user does not choose to start the program using Run as administrator.
=== C6: System-log [OS-ERROR-REPORTING-SERVICE] start/stop inside action window (READ-ONLY) ===
=== POST-RUN error-reporting report-queue inventory (READ-ONLY) — C3 ===
=== POST-RUN LocalDumps presence re-check (READ-ONLY; do not change) ===
LocalDumpsKeyExists=False
OBSERVE END UTC=2026-10-21T08:25:44.6225841Z
Restore
Rendered terminal output
Host label: [HOST-LABEL]
---
FRAME: RESTORE + RESTORE-VERIFY
=== RESTORE (runs only AFTER the evidence seal is confirmed) ===
2026-10-21T08:27:34.1643491+00:00
RESTORE_VERIFY_PATH_GONE=True
Name : [OS-ERROR-REPORTING-SERVICE]
State : Running
StartMode : Manual
ProcessId : 3376
Name : [EDR-SENSOR-SERVICE]
Status : Running
StartType : Automatic
Name : [EDR-SENSOR-SERVICE]
Status : Running
StartType : Automatic
RUN END UTC=2026-10-21T08:27:34.9178633Z
RESTORE-VERIFY (READ-ONLY) UTC=2026-10-21T08:27:44.0351025Z
[HOST-LABEL]
LAB_FOLDER_GONE=True
=== [OS-ERROR-REPORTING-SERVICE] state (read-only; expect Stopped/Manual unless OS demand-started) ===
Name : [OS-ERROR-REPORTING-SERVICE]
State : Stopped
StartMode : Manual
ProcessId : 0
=== EDR + OS-security services unchanged (read-only) ===
Name : [HOST-MGMT-AGENT]
Status : Running
StartType : Automatic
Name : [EDR-SENSOR-SERVICE]
Status : Running
StartType : Automatic
Name : [EDR-SENSOR-SERVICE]
Status : Running
StartType : Automatic
Name : [OS-SECURITY-SERVICE]
Status : Stopped
StartType : Manual
Name : [OS-BUILT-IN-AV-SERVICE]
Status : Stopped
StartType : Manual
=== WER report-queue delta accounting (read-only) ===
RESTORE-VERIFY END UTC=2026-10-21T08:27:44.8986086Z
Restore removed the lab folder, and a separate read-only check confirmed the folder was gone and the security services were unchanged. The crash also produced operating-system crash-report data outside the lab folder; a read-only check about seven hours later found none remaining. It was not removed by the test operator.
Key to the masks
[HOST-LABEL]: the lab host's name[MACHINE-ACCOUNT]: the host's machine account[EDR-SENSOR-SERVICE]: the service of the EDR sensor under test[OS-ERROR-REPORTING-SERVICE]: the operating system's error-reporting service[OS-ERROR-REPORTING-FAULT-EXE]: the operating system's error-reporting fault-handler program[OS-BUILT-IN-AV-SERVICE]: the built-in antivirus service[OS-SECURITY-SERVICE]: a built-in operating-system security service[HOST-MGMT-AGENT]: the lab's host-management agent
Limitations
- This is one Windows lab host, one run and one date (2026-10-21); it is not a statement about any other host, operating system or customer environment.
- The operating system's built-in antivirus was disabled at the host baseline for this run, with the EDR sensor under test unchanged. The fully-disabled state was confirmed by an in-run state check recorded in the baseline frame.
- The alert check was a single check, made at 1:56 AM PT, about 31 minutes after the test; it says nothing about alerting at other times or for other activity.
- The EDR sensor's record of the process exit and its exit code comes from this one run only; it says nothing about how the sensor behaves in other runs or on other hosts.
- Whether the Windows fault record is written while the error-reporting service stays stopped is undetermined for this run, because the operating system started that service on demand during the crash.
- No .NET Runtime 1026 event was written; of the two Windows fault records checked, only the Application Error event (Event ID 1000) was present.
- The command-line field of the host's process-creation log (Security event 4688) was empty, so that log does not record the command.
- Process-termination auditing (Windows Security event 4689) was not turned on, and Sysmon was not available, so neither could serve as a further record of the process exit.
- An additional PowerShell child process was recorded by the host log; its purpose is unknown.
- The run's own before-and-after checks of the error-reporting folders did not cover the folder where the crash-report data was written. The later crash-report check did not list hidden or system files and did not look inside subfolders. When the data disappeared, and what removed it, is not known.
- The sensor's clock and the host's clock differed by about one to two seconds in this run, so times from the two sources cannot settle the exact order of events within a second or two.
- This page makes no detection, prevention, coverage, customer, product-comparison or scoring claim.
References
- SSS Research Validation final grade for this test, with its addendum on the crash-report check (2026-10-21)
- SSS Experiment & Lab evidence report for this test, public-safe summary (2026-10-21)
- SSS case record for this test
Want to know if your endpoint defenses still work?
We test them in your environment and give you a plain written answer.