What does HRESULT 0x801B8000 (WER_E_CRASH_FAILURE) mean?

 
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.