What does HRESULT 0x801B8007 (WER_E_TOO_HEAVY) mean?

 
Previous Next
WER_E_INSUFFICIENT_CONSENT ERROR_FLT_NO_HANDLER_DEFINED

WER_E_TOO_HEAVY

WER_E_TOO_HEAVY is the failure HRESULT 0x801B8007 (signed decimal -2145681401, unsigned decimal 2149285895). Its severity bit is 1, facility is 27 (FACILITY_WER), and the facility-specific code field is 0x8007.

AllStat records the Windows SDK message as “Report aborted due to performance criteria.”

Meaning and documentation boundary

WER_E_TOO_HEAVY says Windows Error Reporting abandoned the report under performance criteria. The public SDK message does not define a portable byte limit, time limit, or formula. Do not invent one from a single machine. The documented fact is the policy decision; the exact trigger must be inferred from the report composition, process size, collection duration, and related WER telemetry.

Report characteristics to inspect

  • heap dump versus minidump selection and the memory footprint of the target process;
  • number and size of files added explicitly or through registered-data flags;
  • large user documents, generated archives, or memory blocks included in the report;
  • slow storage, antivirus inspection, or remote paths that extend collection time;
  • runtime exception helpers or custom callbacks that perform expensive work during a failure.

Build a cost profile rather than guessing

  • timestamp report creation, each add-file/add-dump operation, submission, and cleanup;
  • record attachment sizes before handing them to WER;
  • capture process commit size and requested dump type;
  • compare successful lightweight reports with the failing configuration;
  • note whether WER produced parameters, a queue entry, or no retained artifact.

Reduce the diagnostic payload safely

Start with stable event parameters and the smallest dump that answers the debugging question. Remove redundant logs, generated caches, and files already available through normal support channels. Microsoft recommends WerReportAddDump for dumps and notes that a minidump is generally the appropriate choice for generic reporting. Add larger data only when it supplies evidence unavailable elsewhere.

Retry and fallback

Retry after materially reducing the report or moving collection to a controlled diagnostic session. An unchanged immediate retry is likely to hit the same performance decision. For production systems, preserve a compact incident identifier and local logs so the event is still diagnosable when WER rejects the heavy package.

Distinguish related outcomes

WER_E_DUMP_THROTTLED specifically suppresses dump generation because of a throttle. WER_E_TOO_HEAVY states that the report was aborted on performance grounds. WER_E_NETWORK_FAILURE occurs later or separately when delivery cannot complete. These results lead to different corrective actions.

What administrators should avoid

Do not globally weaken privacy, retention, or throttling policy simply to make one oversized report pass. First identify which artifact dominates collection cost and whether that artifact belongs in WER at all. Full dumps and sensitive documents require explicit operational justification.

Example

A large server process creates a generic report containing a heap dump, multiple rolling logs, and a copied data directory. A compact minidump plus the relevant configuration and incident ID succeeds. The change improves reliability without claiming a universal WER size threshold.

Official Microsoft references

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