What does HRESULT 0x801B8000 (WER_E_CRASH_FAILURE) mean?

Status / error code:

Category:

Constant name:

Source:

Facility:

Operating System:

Description:

WER could not complete crash-report processing; keep the original fault distinct from the reporting failure.

Previous	Next
HTTP_E_STATUS_VERSION_NOT_SUP	WER_E_CANCELED

WER_E_CRASH_FAILURE

WER_E_CRASH_FAILURE is the failure HRESULT 0x801B8000 (signed decimal -2145681408, unsigned decimal 2149285888). Its severity bit is 1, facility is 27 (FACILITY_WER), and the facility-specific code field is 0x8000.

AllStat records the Windows SDK message as “Crash reporting failed.”

What WER_E_CRASH_FAILURE says about the reporting pipeline

This result reports failure of Windows Error Reporting itself while it was handling a crash report. It does not identify the exception, faulting module, or defect that crashed the application. Treat the original failure and the WER failure as two independent records: one describes the application incident, while this HRESULT describes the attempt to collect, package, queue, or submit diagnostics.

Stages that can fail

creation of an application-specific report with WerReportCreate;
addition of a process dump or exception information through WerReportAddDump;
attachment of files whose paths, access rights, or lifecycle are unsuitable;
packaging into the local report store or queue;
submission through WerReportSubmit after data collection has begun.

Evidence worth preserving

the original exception code, faulting process, thread, module, and event signature;
the first WER API that failed, its HRESULT, and the report handle state at that point;
the value returned through WER_SUBMIT_RESULT, when submission was reached;
paths and sizes of every requested dump or attachment, together with access checks;
WER event-log entries and the presence of matching queue or archive directories.

Diagnostic sequence

reproduce once with the smallest report: stable parameters and a minidump, without optional files;
verify that the target process handle has the rights required by WerReportAddDump;
confirm that added files still exist and remain readable until WER has consumed them;
check free space, report-store permissions, WER policy, and service health;
add optional artifacts back individually to identify the failing collection step.

Retry and recovery

A single retry is reasonable only after correcting a transient environmental problem such as a disappearing file, temporary storage failure, or service interruption. Do not recursively create another WER report from the same crash-reporting error path; nested reporting can hide the original crash and produce repeated secondary failures.

Nearby results that mean something different

WER_E_NETWORK_FAILURE identifies the transport stage, WER_E_INSUFFICIENT_CONSENT identifies authorization to send data, and WER_E_DUMP_THROTTLED says a dump was deliberately not generated. WER_E_CRASH_FAILURE is the broader crash-report-processing failure when no narrower WER result explains the outcome.

Practical example

A service catches a fatal worker-process event and creates a generic report. Its exception metadata is valid, but an attachment points to a rotated log that has already been deleted. The application crash remains the primary incident; the WER HRESULT tells the operator why the expected diagnostic package was not completed.

Official Microsoft references

Looking for a different code? Search another status or error code.