EC2, Windows 10, half of the virtual processors

Question

We run t3.large and m5.large instances, which have 2 vCPUs (as displayed in the EC2 management console). I'm trying to understand why the Windows 2019 (AMI provided by my IT) can only see half the number of logical CPUs.

Half the number is reported in Task Manager, in msinfo32, in Coreinfo. We also see half the number for larger instances (xlarge: 2 instead of 4).
If I run while($true){} in PowerShell, Task Manager will report 100% usage, but the Cloudwatch will report 50%.
In msconfig, I can only choose 1 CPU (for large instances).
When I created my instance in EC2 wizard, I used the default number of vCPUS.
If I use a Windows 2019 AMI from the marketplace, I get the correct number of Logical Processors. In both cases, it's the same version/build (Windows Server 2019 Datacenter).

Would you know any configuration in Windows 10 that could impact the number of detected Logical Processors? Or if I can activate any log to see how the CPUs are detected (like dmesg in linux). My IT colleague told me that they did not change anything about number of CPUs or hyperthreading, but it looks like there is something special with their AMI.

Update: In the Event Viewer, in "Microsoft / Windows / Kernel-PnP", I can see:

Device ACPI\GenuineIntel_-Intel64_Family_6_Model_79-_Intel(R)_Xeon(R)CPU_E5-2686_v4@_2.30GHz_1 was configured.

Device ACPI\GenuineIntel_-Intel64_Family_6_Model_79-_Intel(R)_Xeon(R)CPU_E5-2686_v4@_2.30GHz_0 was configured.

I don't know if there is any other log anywhere that would say when any CPU/core/thread is initialized as a Logical Processor.

Update 2: I compared the content of bcdedit /enum All and bdcedit /v for both problematic and working machines and it's the same (excepted an UUID). I tried to explicitly set bcdedit /set NUMPROC 2 and reboot, without result. bcdedit /v:

Windows Boot Manager
--------------------
identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device                  partition=C:
description             Windows Boot Manager
locale                  en-US
inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
bootshutdowndisabled    Yes
default                 {61a8a653-e7da-11e8-a960-0e221fdbf186}
resumeobject            {61a8a652-e7da-11e8-a960-0e221fdbf186}
displayorder            {61a8a653-e7da-11e8-a960-0e221fdbf186}
toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout                 30

Windows Boot Loader
-------------------
identifier              {61a8a653-e7da-11e8-a960-0e221fdbf186}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows Server
locale                  en-US
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
recoverysequence        {74e13b1d-b199-11ea-827a-0af4c9a8ea6d}
displaymessageoverride  Recovery
recoveryenabled         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {61a8a652-e7da-11e8-a960-0e221fdbf186}
nx                      OptOut
bootstatuspolicy        IgnoreAllFailures

What is the text output of bcdedit? – Greg Askew Jul 23 '20 at 15:46 — Greg Askew, Jul 23 '20 at 15:46
Thanks: it's the same in both cases (I added it above). – fskexp Jul 27 '20 at 08:12 — fskexp, Jul 27 '20 at 08:12

score 2 · Accepted Answer · answered Nov 26 '20 at 22:18

This issue happens when Hyper-Threading is disabled at OS level. This may have been done based on Microsoft recommendation for protecting against a known vulnerability known as speculative execution side-channel [1].

Based on "Windows guidance to protect against speculative execution side-channel vulnerabilities"[2] that Customers who have Windows Update enabled and have applied the security updates released on July 9, 2019 are protected automatically. There is no further configuration necessary.

To resolve this issue, I suggested enabling Hyper-Threading using the below steps:

1. Confirm that Hyper-Threading is disabled by querying the registry using below command:

    •   reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride 

    The Hyper-Threading will be disabled if the output is:

    •   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
    •   FeatureSettingsOverride    REG_DWORD    0x2048

2. Once confirmed, proceed with enabling the Hyper-Threading using the below command:

    •   reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f

3. Restart the instance and check the number of vCPU reported in the OS, which should show the correct number.

Reference:

[1] Microsoft Speculative Execution Side-Channel Vulnerability: https://support.microsoft.com/en-us/help/4457951/windows-guidance-to-protect-against-speculative-execution-side-channel
[2] Microsoft Mitigation Steps: https://support.microsoft.com/en-us/help/4072698/windows-server-speculative-execution-side-channel-vulnerabilities

Thank you a lot for the solution, it works. I will check if the change is acceptable according to the useful references you mentioned. — fskexp, Nov 30 '20 at 08:21

EC2, Windows 10, half of the virtual processors

1 Answers1