Nach mehreren Stunden suchen, ausprobieren und unzähligen Windows 11-Neustarts habe ich endlich eine funktionierende Lösung für mein Problem gefunden:
Microsoft „Device Guard and Credential Guard hardware readiness tool“
Egal was ich bisher ausprobierte, diese zwei „VMware Workstation 17 Pro“-Optionen unter VM-> Settings -> Tab Hardware -> Processors:
und
Virtualize CPU performance counters
führten immer dazu, dass ich meine neue virtuelle Maschine nicht mehr starten konnte.
Ich habe kontrolliert ob im Mainboard-BIOS die UEFI-Settings für VT-d und Intel VMX aktiviert/enabled sind, ich habe in meinem Gast-Betriebssystem „Windows 11 Pro“ sämtliche optionalen Features zu „Hyper-V“, „Virtual Machine Platform“, „Windows-Hypervisor-Platform“ und „Windows Subsystem für Linux“ deaktiviert und ich habe verschiedene Registry-Settings erfolglos ausprobiert.
Endlich habe ich dann auf Reddit den funktionierenden Hinweis gefunden. Es gibt ein offizielles Tool von Microsoft namens „Device Guard and Credential Guard hardware readiness tool”. Wenn man danach googelt, kommt man schnell auf diese Download-Seite:
https://www.microsoft.com/en-us/download/details.aspx?id=53337
Von dort kann man sich die notwendige Powershell-Script-ZIP-Datei herunterladen und lokal extrahieren.
In einer Powershell-Konsole mit Administrator-Rechten kann man das Script** so aufrufen:.\DG_Readiness_Tool_v3.6.ps1
Ohne weitere Parameter aufgerufen wird einem erklärt, was man damit alles für Ein-/Ausschalt- und Anzeigemöglichkeit hat. Eine Variante ist z.B. .\DG_Readiness_Tool_v3.6.ps1 -Ready
damit bekommt man in grüner Farbe angezeigt, ob z.B. «HVCI is enabled and running».
Das ist die Ursache, wieso die zwei Virtualisierungs-Optionen in VMWare Workstation den Start der virtuellen Maschine verhindern.
(Die obige grüne Zeile «Config-CI is enabled and running…» kann man so belassen, die stört in unserem Fall nicht.)
Um aber ein laufendes HVCI (steht für HyperVisor-Protected Code Integrity) und auch den „Device Guard (DG) und Credential Guard (CG)“ auszuschalten, verwendet man.\DG_Readiness_Tool_v3.6.ps1 -Disable
Das gab zwar bei mir ein paar rote Fehlermeldungen** von wegen Dateien die nicht gefunden wurden und Registry-Einträge die nicht vorhanden waren. Die habe ich ignoriert.
Die Deaktivierung wird erst nach einem Geräte-Neustart aktiv!
Ein erneuter Script-Aufruf nach dem Neustart mit -Ready zeigt:
Mit dieser Einstellung kam auch endlich das Aha-Erlebnis:
Meine virtuelle Maschine startet jetzt auch mit obigen zwei „Virtualization engine“-Einstellungen.
Das Ganze ist deshalb nötig, weil ich in meiner virtuellen Maschine „Docker Desktop on Windows“ installiert hatte, aber dieses ebenfalls nicht startete, weil die virtuelle Maschine ja bisher keine Virtualisierungs-Einstellungen akzeptierte. Durch die 2 nun funktionierenden Optionen startet „Docker Desktop on Windows“ in meiner virtuellen Maschine fehlerfrei und ich kann damit alles ausprobieren ohne meine eigentliche Windows-Umgebung zu verändern.
Warum einem Microsoft das dermassen schwierig machen muss, bleibt offen.
Wer an den eigentlichen Einstellungen interessiert ist, kann im erwähnten PowerShell-Script ab der Zeile #1178 unter if($Disable) nachlesen, was alles an Registry-Einträgen oder Dateien wie der SIPolicy.p7b gelöscht wird oder gar an DISM.exe-Befehlen ausgeführt wird.
** Nachtrag:
Da das PowerShell-Script nur in englischer Variante von Microsoft zur Verfügung gestellt wird, muss man die Zeilen #758 und #762 für die Ausführung in einem deutschen Windows selber korrigieren, indem man entweder das kleingeschriebene Wort bit jeweils in Bit abändert:
oder gleich eine flexiblere Variante für beide Schreibweisen wieif($OSArch.ToLower().Contains("64-bit"))
verwendet. Die Ausgabe des vorangehenden PowerShell-Befehls auf Zeile #756(gwmi win32_operatingsystem).OSArchitecture
gibt in einem deutschen Windows z.B. 64-Bit aus, in einem englischen Windows z.B. 64-bit.
Da die .NET-Zeichenfolgenmethode .Contains() zwischen Gross- und Kleinschreibung unterscheidet, bedeutet in obigem Beispiel „64-Bit“ ist NICHT gleich „64-bit“. Die Variable $OSArch beinhaltet in einem deutschen Windows NICHT die Zeichenfolge „64-bit“.