Geoff Chappell, Software Analyst
The MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED bug check shows that one processor differs too much from others.
|Bug Check Code||MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED|
|1st Argument||0x10 for difference in PGE support;
0x40 for difference in MTRR support;
0x80 for difference in CX8 support;
0x0387 for difference in whether numerical coprocessor is present;
0x0400 for difference in PAT support;
0x0800 for difference in FXSR support or value of MXCSR;
0x2000 for difference in SSE support;
0x00040000 for difference in CLFSH support;
0x20000000 for difference in Execute-Disable support
|2nd Argument||expected MXCSR value, if difference is in
value of MXCSR;
|3rd Argument||rejected MXCSR value, if different is in value
Windows has long been documented as being executable on multiple processors only on symmetric multiprocessor (SMP) systems. This is often expressed as meaning that all processors must be identical, or “of the same type and level” (as Microsoft puts it in documentation of this bug check), but this is correct only very roughly. What the kernel requires is not that all the processors be identical but that they can all be used identically. For many processor features, the kernel explicitly tolerates differences by the simple expedient of working to the lowest capability. If such a feature is not supported on all processors, it simply doesn’t get used for any.
For some features, differences among the processors are explicitly rejected. The usual case is that the boot processor’s support for the feature, or lack of support, is already relied on by the time the kernel starts other processors, such that reconfiguring for a difference would be impossible, difficult or too much trouble. These fatal differences between processors are reported as bug check 0x3E. The first such difference that is noticed is indicated by the 1st argument.
The following features must either be supported by all processors or be supported by none:
Similarly, each processor must have its own numeric coprocessor, else none may.
For the following features, if the boot processor supports the feature, then so must all other processors:
If the boot processor supports CLFLUSH, then not only must all processors support the instruction, they must all have the same line size (which CPUID function 1 returns in bits 8 to 15 of ebx).
For FXSR support, the MXCSR register must be consistent across all processors. When inconsistent, the expected and rejected values are given as the 2nd and 3rd arguments.
For MTRR support, the machine-specific register MTRRcap (0xFE) must be consistent across all processors. Inconsistency of the machine-specific register MTRRdefType (0x2FF) is tested but tolerated, albeit with a complaint to the debugger even in the free build:
KiInitializeMTRR: MTRR_MSR_DEFAULT is not consistent between processors.
The preceding description is for version 6.0 from the original Windows Vista. The following table lists the various tests in their order of introduction:
|version 3.51||presence of numerical coprocessor|
|version 4.0||CX8 and PGE support|
|version 5.0||PAT, MTRR, FXSR and SSE support|
|version 5.1||MXCSR consistency|
|version 5.1 from Windows XP SP2;
version 5.2 from Windows Server 2003 SP1;
|version 6.0||CLFSH support and same line size;
Additionally, version 3.51 rejects any multi-processor configuration that includes an 80386. This provision is dropped from later versions, which reject even a lone 80386 (raising the UNSUPPORTED_PROCESSOR bug check).
Versions 4.0 and 5.0 have code to raise this bug check for mis-matched CX8 support even while initialising for the boot processor, i.e., without having yet checked the CX8 support of a second processor. In version 4.0 before Windows NT 4.0 SP4, this allows the occurrence of this bug check even on machines that have only one processor. This curious effect arises because (in these early builds only) the kernel tests for CX8 support in two different ways. A first test, applied only to the boot processor, asks only whether the CX8 bit is set in the CPUID feature flags. A later test, applied to each processor in turn, including the boot processor, recognises the CX8 bit only if the CPUID vendor string is GenuineIntel, AuthenticAMD or CyrixInstead. If a boot processor from anyone other than Intel, AMD or Cyrix has CX8 support, then the two tests for the CX8 bit do not agree, and the processor is rejected for its supposed contribution to an unsupported multiprocessor configuration. In the Knowledge Base article CMPXCHG8B CPUs in Non-Intel/AMD x86 Compatibles Not Supported, Microsoft is at best disingenuous in suggesting that the first test is only a rough guess from the processor’s “type”, which a second test must “verify” by querying for “specific features”: both tests are specifically for the CX8 feature.
The MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED bug check can occur in version 3.51 and higher.
Microsoft’s documentation says that there are no parameters for this bug check.