| Previous | Next |
| ERROR_CARDBUS_NOT_SUPPORTED | ERROR_HIBERNATED |
ERROR_MP_PROCESSOR_MISMATCH
Processors in a multiprocessor system have incompatible revision levels
ERROR_MP_PROCESSOR_MISMATCH corresponds to Win32 error value documented as: The CPUs in this multiprocessor system are not all the same revision level. To use all processors the operating system restricts itself to the features of the least capable processor in the system. Should problems occur with this system, contact the CPU manufacturer to see if this mix of processors is supported. Windows detected CPUs whose revisions or capabilities are not sufficiently consistent for normal symmetric multiprocessing. The system may restrict processor usage to preserve correctness.
Where the result appears in real systems
- Physical servers with mixed CPU steppings.
- Unsupported processor replacement.
- Firmware exposing inconsistent microcode.
- Unusual virtual-machine CPU presentation.
Evidence to collect before changing the system
inventory every logical processor family, model, stepping, microcode revision, and feature set; check firmware event logs and BIOS release notes; compare VM CPU compatibility settings across hosts
Keep the original numeric value, symbolic name, API return path, thread and process identity, and the exact timestamp in one diagnostic record. Those fields prevent later layers from replacing this specific result with a generic failure and make correlation with ETW or Event Viewer practical.
Handling and recovery
Use matched processors, update system firmware and microcode, or configure the hypervisor to expose a uniform CPU model. Do not force-enable processors that Windows excluded for compatibility.
Code that receives this result should classify it according to the operation that produced it: completion information, a recoverable environmental condition, or a programming defect. The result classification should be made at the API boundary where the caller still knows the handle, object, flags, and expected state.
What not to infer from this code
This code is about consistency among processors, whereas generic unsupported-processor errors concern whether a single CPU meets the operating system requirements.
Implementation guidance
Preserve this result through logging and telemetry instead of immediately converting it to free-form text. When it crosses an HRESULT boundary, record both the original Win32 value and the converted HRESULT; when it crosses RPC, JSON, or another protocol, include an explicit error-domain field so the receiver does not convert it twice.
A useful automated test for it should reproduce the relevant state transition, assert the exact returned value, and verify cleanup after both the normal and exceptional path. The test for it should also check that a retry is performed only when the underlying state can genuinely change, because unconditional retries often hide ownership, architecture, power, or resource-negotiation defects.
References
Looking for a different code? Search another status or error code.