Value for this variable when the driver is run on either Windows 2000 Thus, for instance, a driver built in the Windows 2000 buildĮnvironment that dereferences KeNumberProcessors will get the proper They are built will work properly on both Windows 2000 and Windows XP. Reference KeNumberProcessors according to the environment in which Note that regardless of the declaration used, drivers that properly "illegal indirection" error at compile time. As a result of theĬhanged definition of this variable, drivers built in the Windows XPīuild environment must not dereference this variable (for example,ĭrivers that fail to use KeNumberProcessors correctly will get an The Microsoft® Windows® 2000ĭefinition of this variable required that KeNumberProcessors beĭereferenced (for example, *KeNumberProcessors). Ntddk.h and wdm.h, the definition of KeNumberProcessors has beenĬhanged from a pointer to a value. The kernel variable KeNumberProcessors indicates the number of active CPUs in the system Older MSDN documentation is even more verbose:Ĭhange in the Definition of KeNumberProcessors This was meant to be a clever trick - relying on circumstantial knowledge - to accommodate both Windows XP and newer (where the variable is a CCHAR) as well as prior Windows versions, where it's a PCCHAR. Now, while I certainly may not have all the answers that the folks from Sysinternals/Microsoft have by glancing at the Windows source code, my guess is the following. Integer value that indicates the number of processors in the platform. Versions of Windows, KeNumberProcessors is a pointer to an 8-bit That indicates the number of processors in the platform. Starting with Windows XP, KeNumberProcessors is an 8-bit integer value Still exported from the kernel, so drivers built for earlier platforms Releases starting with Windows Vista SP1 however, the variable is KeNumberProcessors does not appear in WDK headers for WDK With Service Pack 1 (SP1), Windows Server 2008, and later versions of The KeNumberProcessors kernel variable is obsolete in Windows Vista Looking at the above linked documentation you will find (relevant excerpts):
That variable used to be a pointer prior to Windows XP. Let's start by stating that the maximum available number of processors for Windows 2000 Server (Datacenter edition) was 32.īased on the declaration for KeNumberProcessors, which is by the way deprecated in favor of KeQueryActiveProcessors: #if (NTDDI_VERSION >= NTDDI_VISTA)Įxtern NTSYSAPI volatile CCHAR KeNumberProcessors Įxtern NTSYSAPI CCHAR KeNumberProcessors This code would seem to lead to an inevitable BSOD. With the information I could dig up, I concur. So my money is on: this is meant to cause a BSOD, knowing full well that this situation could realistically never occur.
sys for DebugView that would deliberately cause a BSOD. And there is no indication of anything like in the. text:00010519 mov eax, ds:_imp_KeNumberProcessors which we fix by removing the * that dereferences KeNumberProcessors, which then gives us a successful compilation and the following code. text:00010537 call ExAllocatePool(x,x)Īnd when targeting Windows XP using the WDK 7600.16385.1 we get an error during compilation: KNPs.cpp(102) : error C2100: illegal indirection When building this for Windows 2000 (free) as target (using WDK 6001.18002), we get for the line assigning nCpus and the subsequent one. PVOID lpBuf = ExAllocatePool(NonPagedPool, nCpus * 7)
You'll write this (some more code was necessary to force this code not to be optimized away): CCHAR nCpus = *KeNumberProcessors Okay, so say you have an old driver targeting pre-XP Windows versions. This is possible whenever the author is careful enough not to use functions unavailable on Windows 2000, but available at compile and link time for the nominal target. However, the driver does run on Windows 2000 Professional (with SP4) as I verified. The likeliest error is: error C2100: illegal indirection.Īccording to the PE header the file was created using WDK 7600.16385.1 (OS version), targeting XP (subsystem version), assuming we can trust best practices having been used to create the driver. The source incompatibility will inevitably force that the developer notices the change of type for KeNumberProcessors from PCCHAR to CCHAR.
It makes perfect sense to assume that this is deliberate once piecing all the puzzle pieces together. I still think this will create a BSOD, what's more I think that this is deliberate.