| Previous | Next |
| WER_E_NOT_INITIALIZED | WER_E_DUMP_THROTTLED |
WER_E_ALREADY_REPORTING
WER_E_ALREADY_REPORTING is the failure HRESULT 0x801B8004 (signed decimal -2145681404, unsigned decimal 2149285892). Its severity bit is 1, facility is 27 (FACILITY_WER), and the facility-specific code field is 0x8004.
AllStat records the Windows SDK message as “Reporting is already in progress for the specified process.”
The process already has an active report
Windows Error Reporting rejected a second reporting attempt because reporting is already in progress for the specified process. The result is about overlap and reentrancy, not duplicate crash signatures stored on the server. A process can reach this state when multiple components independently react to the same fault or when a reporting callback starts another report before the first one finishes.
Typical concurrency patterns
- two crash observers submit for one process at nearly the same time;
- a watchdog and the application both report the same hang;
- a runtime exception helper invokes application code that re-enters WER;
- an asynchronous submission remains active while shutdown logic starts another report;
- a retry timer fires before the previous out-of-process submission has completed.
How to locate the owner of the first report
- log process ID, reporting component, thread ID, report type, and incident key at report start;
- emit an explicit completion record only after submit and handle cleanup;
- track whether submission used synchronous or asynchronous out-of-process flags;
- correlate the second HRESULT with the start time of the first report;
- ensure every exceptional exit releases the application-side reporting lock.
Serialization design
Use one process-wide coordinator that accepts incident metadata and decides whether to submit, coalesce, or defer. Keep the coordinator independent of the crashing subsystem so it cannot be entered recursively through the same logger, allocator, or exception path. A second component should append safe metadata to its own logs rather than opening a competing WER transaction.
Retry conditions
A bounded retry can be scheduled after the current reporting operation is known to have completed. Be cautious with WER_SUBMIT_OUTOFPROCESS_ASYNC: Microsoft notes that the immediate result does not provide a way to query completion status. Time-based guessing can therefore reproduce the overlap; prefer a design that avoids the second report entirely.
What the result does not mean
It does not say that WER globally refuses reports, that a matching bucket already exists, or that throttling has been applied. It only identifies an active report associated with the specified process.
Comparison with WER_E_NOT_INITIALIZED
WER_E_NOT_INITIALIZED points to missing setup. Here setup has progressed far enough that WER recognizes an existing reporting operation. The corrective action is serialization and ownership, not rebuilding every report object indiscriminately.
Example
A service host crashes one plug-in. The host exception handler submits a report while a monitoring agent simultaneously requests a report for the same process. The agent receives this HRESULT and should retain its own telemetry without launching repeated submissions.
Official Microsoft references
- Microsoft: using Windows Error Reporting
- Microsoft: WerReportSubmit
- Microsoft: WER_SUBMIT_RESULT
- Microsoft: Windows Error Reporting overview
- Microsoft: WerReportCloseHandle
Looking for a different code? Search another status or error code.