What does HRESULT 0x801B8002 (WER_E_NETWORK_FAILURE) mean?

 
Previous Next
WER_E_CANCELED WER_E_NOT_INITIALIZED

WER_E_NETWORK_FAILURE

WER_E_NETWORK_FAILURE is the failure HRESULT 0x801B8002 (signed decimal -2145681406, unsigned decimal 2149285890). Its severity bit is 1, facility is 27 (FACILITY_WER), and the facility-specific code field is 0x8002.

AllStat records the Windows SDK message as “Report aborted due to network failure.”

Transport-specific meaning

This HRESULT narrows the failure to network delivery of a Windows Error Reporting report. It does not establish that report creation, dump capture, or event-signature generation failed. Depending on submission flags and policy, the report might remain queued for later delivery or it might be discarded when immediate transmission is impossible.

First determine whether queuing was allowed

WerReportSubmit supports queueing and a WER_SUBMIT_NO_QUEUE mode. Microsoft documents that a no-queue submission can be discarded when the computer is offline. Therefore the same connectivity outage can produce different operational consequences: a durable queued report, a failed immediate upload, or no retained report at all.

Network paths to examine

  • Internet reporting to the configured Microsoft endpoint;
  • an enterprise corporate reporting file share or upload path;
  • proxy, firewall, DNS, TLS inspection, and egress policy applied to the reporting identity;
  • connectivity available to the service account rather than only to an interactive administrator;
  • temporary loss of network during a long dump or cabinet upload.

Telemetry that separates transport from collection

  • submission flags and consent state;
  • the returned WER_SUBMIT_RESULT and whether the report key appears in the WER store;
  • report size, attachment count, start time, and time of the network failure;
  • destination mode—Internet or corporate—and any configured upload/archive path;
  • proxy and name-resolution results obtained in the same security context.

Recovery strategy

Prefer the WER queue or report store for transient outages instead of implementing a tight application retry loop. After connectivity returns, upload the stored report through supported WER mechanisms. If policy deliberately forbids the destination, retries will not help; correct the enterprise configuration or select the approved corporate reporting path.

What not to conclude

The code does not imply that the application had Internet access generally, nor that the crash dump was absent. Browsers and interactive tools may work through user-specific proxy credentials while WER runs under a different identity or policy. Inspect the actual WER submission context.

Contrast with neighboring WER codes

WER_E_CRASH_FAILURE is broader, WER_E_CANCELED records a user stop, and WER_E_INSUFFICIENT_CONSENT prevents transmission for privacy authorization reasons. This code should lead diagnostics toward the delivery path and queue disposition.

Operational scenario

A server submits reports with no-queue semantics during a temporary egress outage. The report is successfully assembled, but WER cannot upload it and no queued copy remains. Changing the workflow to permit managed queueing is more reliable than retrying from the faulting process.

Official Microsoft references

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