EC2, Windows 10, half of the virtual processors

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
ACPIGenuineIntel_-Intel64_Family_6_Model_79-_Intel(R)_Xeon(R)CPU_E5-2686_v4@_2.30GHz_1
was configured.

Device
ACPIGenuineIntel_-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                    Windowssystem32winload.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

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

    •   reg query "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management" /v FeatureSettingsOverride 

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

    •   HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management
    •   FeatureSettingsOverride    REG_DWORD    0x2048

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

    •   reg add "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory 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.