What does Windows error code 640 (ERROR_MULTIPLE_FAULT_VIOLATION) mean?

Status / error code:		Category:

Constant name:
Source:		Operating System:
Description: A low-level multiple-fault marker; preserve the first exception and execution context.

Previous	Next
ERROR_INSUFFICIENT_POWER	ERROR_SYSTEM_SHUTDOWN

ERROR_MULTIPLE_FAULT_VIOLATION

ERROR_MULTIPLE_FAULT_VIOLATION is Windows system result 640 (0x00000280). Microsoft defines it as “this result” The value should be captured immediately at the producing boundary because later diagnostics, cleanup, or retry code can overwrite a thread-local last-error value or collapse a richer native status.

How to classify the result

This result represents a low-level fault or exception marker with intentionally sparse public semantics. The correct interpretation depends on the first exception, processor context, or kernel component that translated its internal condition to code 640.

The most important boundary for it is whether the operation reached a documented final state.

Where it can appear

This result can appear in crash or exception reporting after more than one fault condition.
It can appear in a compatibility or kernel boundary that maps a native status to Win32.
It can appear in diagnostic software reading a stored result rather than a normal API return.

When it is found only in a log, preserve the logger, event provider, process, thread, and translation path.

Typical causes

a second fault occurred while handling an earlier fault.
corrupted execution state caused several exception conditions.
a hardware, driver, or runtime component emitted an internal marker.
the original detailed status was lost during translation.
test or verifier instrumentation deliberately exercised a nested-fault path.

These causes are starting points for it, not substitutes for evidence.

Evidence to preserve

Record first exception code and parameters for it.
Record instruction pointer and stack trace for it.
Record process, thread, module, and driver versions for it.
Record WER report or kernel dump identifier for it.
Record hardware error and verifier records preceding code 640 for it.

Also retain decimal 640, hexadecimal 0x00000280, UTC time, machine build, component version, and a correlation identifier.

Recovery and retry

The recovery objective for it is to Recover by correcting the first demonstrated fault or corrupting component; code 640 itself does not specify a standalone remediation.

Blind retry is unsafe when execution state may be corrupted. Restart the affected process or system only after preserving evidence, then test the suspected fix under controlled load.

Difference from related results

It should not be confused with ordinary access violations or floating-point multiple-fault statuses. Preserve the original exception domain whenever available.

Keep the original constant in telemetry rather than replacing it with a nearby result that seems more familiar.

Practical validation scenario

A service crash report contains only code 640 after an exception filter itself faults. The dump reveals the initial invalid pointer and the secondary failure in logging code; fixing the first pointer and hardening the filter removes the marker.

A useful test report for it includes the failing call, exact input, state before the call, raw output, expected state, and observed state after recovery.

Telemetry and support fields

Record multiple_fault_violation_operation for the producing API, callback, wait, driver, packaging phase, or service transition.
Record multiple_fault_violation_target for the stable session, selector, device, pin, content, resource, service, or validation identity.
Record multiple_fault_violation_state_before and multiple_fault_violation_requested_state using explicit units and enum names.
Record multiple_fault_violation_raw_status, the original result domain, and any later HRESULT or Win32 conversion.
Record multiple_fault_violation_attempt, elapsed time, process and thread IDs, server or device instance, and correlation ID.

Alerting for it should reflect the classification above.

Developer and administrator guidance

Applications should never manufacture this value as a generic “multiple errors” code. Incident tooling should prioritize dump collection and retain the native exception chain.

Developers should preserve it at module boundaries and document whether ownership of buffers, handles, mutexes, callbacks, or transition contexts changes on return.

References

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