| Previous | Next |
| WER_E_CRASH_FAILURE | WER_E_NETWORK_FAILURE |
WER_E_CANCELED
WER_E_CANCELED is the failure HRESULT 0x801B8001 (signed decimal -2145681407, unsigned decimal 2149285889). Its severity bit is 1, facility is 27 (FACILITY_WER), and the facility-specific code field is 0x8001.
AllStat records the Windows SDK message as “Report aborted due to user cancelation.”
Cancellation is the outcome, not the crash cause
WER_E_CANCELED means the report workflow was aborted because the user canceled it. The code does not say that the application operation which triggered reporting was canceled, and it does not prove that the report data was invalid. The report may have been created correctly and stopped only when WER presented a consent or reporting interface.
Where cancellation can enter the flow
- an interactive consent prompt shown by
WerReportSubmit; - a WER dialog presented for a critical application event;
- a caller-owned UI that maps an explicit user decision into the WER consent state;
- a submission session that the user closes before collection or upload completes.
Do not confuse the HRESULT with WER_SUBMIT_RESULT
Always record both the function return value and the optional WER_SUBMIT_RESULT. Microsoft defines WerReportCancelled as a submission-result state, while this page covers the failure HRESULT. Depending on the API path, one may be available without the other. Diagnostics that retain only “canceled” lose the distinction between a returned HRESULT, a successful call with a cancellation result, and application-side cancellation.
Questions to answer during diagnosis
- Was the process interactive, headless, or running as a service?
- Which
WER_CONSENTvalue was supplied? - Were queue, no-queue, or out-of-process submission flags used?
- Did policy suppress UI while the application expected a prompt?
- Was cancellation repeatable for one user or common to all identities on the machine?
Safe application behavior
Treat cancellation as a deliberate terminal result for that attempt. Preserve local application logs and any independently configured dump, release the report handle, and return control without repeatedly prompting. A background service should not impersonate user approval or loop until a report is accepted.
When another attempt is appropriate
Retry only after a new explicit user action, a later queued-report policy decision, or a change from an interactive to an approved enterprise collection path. An immediate automatic retry usually recreates the same prompt and undermines the user choice that produced the HRESULT.
Difference from consent and transport failures
WER_E_INSUFFICIENT_CONSENT says the required authorization was not available; it can occur without the user actively pressing Cancel. WER_E_NETWORK_FAILURE means reporting proceeded far enough to encounter transport failure. The cancellation code specifically records a user-driven stop.
Example
A desktop application submits a non-fatal diagnostic report with WerConsentNotAsked. WER displays the consent UI and the user declines to continue. The application should keep its own incident identifier, close the WER handle, and mark remote reporting as canceled rather than failed by the network.
Official Microsoft references
- Microsoft: WerReportSubmit
- Microsoft: WER_CONSENT
- Microsoft: WER_SUBMIT_RESULT
- Microsoft: using Windows Error Reporting
- Microsoft: WerReportCloseHandle
Looking for a different code? Search another status or error code.