[ad_1]
Funny story: I was trying to test out some Windows 11 upgrade scenarios and had configured a VM with 4GB of RAM since that’s the minimum required to support Windows 11. With that configuration, Microsoft’s Hardware Compatibility script (or a Tanium equivalent of that added as a sensor, which I showed in today’s Go-Tanium Endpoint Explorers stream) reported that the machine was compatible, and the upgrade process worked fine too. But a separate check where I was checking for “greater than or equal to 4GB” wasn’t working, saying the device didn’t have the needed RAM.
OK, so what gives? When looking at the VM, it reported that it had 4,193,180KB of RAM. If you do that calculation, you’ll see that is 3.9989GB, which isn’t quite 4GB. 4GB would be 4,194,304KB. So what happened to the other 1,124KB of RAM? Apparently that was reserved by the hardware (VM in this case, but the same thing can happen on physical machines too) and not available to the OS.
So, how did the Microsoft Hardware Compatibility script succeed? It calculates the RAM using PowerShell, something like this:
$gbRAM = ($bytes / 1GB -as [int])
The “-as [int]” type conversion actually rounds the result, up or down depending on whether it is above or below the .5 mark. So, the script reports 4GB as long as the machine has at least 3.5GB.
Alright, but what about SETUP.EXE? Based on some testing that Keith Garner did, it appears that SETUP.EXE uses a 10% “fudge factor” in its calculations. So instead of checking for 4GB, it checks for at least 3,686MB, which is 10% less than the stated 4GB number. A convenient way to handle this “not quite 4GB” issue. (That does put the script and SETUP.EXE off by 410MB, but who’s counting…)
Lesson learned, don’t use exact numbers when checking memory requirements.
[ad_2]
Source link
