Windows 11 24H2: VMware Workstation Pro 17.x extrem langsam

Windows[English]Mir liegt eine Benutzermeldung über Probleme mit der Virtualisierung mittels VMware Workstation Pro 17.x auf Windows 11 24H2-Clients vor. Ein Benutzer beklagt sich, dass die Gast-Betriebssysteme extrem zäh laufen. Mir wenn VMware Workstation als spezieller Administrator gestartet wird, funktioniert die Virtualisierung erwartungsgemäß.


Anzeige

Problembeschreibung eines Nutzers

Die Tage erreichte mich unter dem Betreff "VMware Workstation Pro 17 extrem langsam" eine E-Mail von Kai, in der er ein "komisches Verhalten" von VMware beklagt. Er verwendet VMware Workstation Pro 17 auf einem Client mit Windows 11 24H2. Seiner E-Mail nach gibt er an, den Client mit dieser Windows-Version neu aufgesetzt zu haben.

Wie immer hat er sich vorher mit dem VM-Converter ein Abbild erstellt, um anschließend alle Daten von seinem "alten PC" auf den neu aufgesetzten PC zu übertragen. Das soll über VMware Workstation passieren, sprich: Der alte PC wurde per VM-Converter in eine virtuelle Maschine (VM) überführt.

Die Vorgehensweise war als: Alten PC in VM konvertieren, dann das neuste Windows 11 24H2 auf den PC installieren und im Anschluss VMware Workstation 17.x hinzufügen. Idee war, die vorher erstellte virtuelle Maschine (VM) zu starten und mit dem Datentransfer auf den Windows 11 Host zu beginnen.

Was er aber bekam, war eine extrem zähe Geschichte. Der Versuch, eine VM zu startet, bedeutet ewig warten. Unter 20 % der Programme lassen sich in der VM überhaupt öffnen. Den Windows Explorer zu öffnen dauere ewig, schrieb der Leser.


Anzeige

Er hat die Auslastung für CPU, Netzwerk, Arbeitsspeicher geprüft und fand, dass alles im grünen Bereich sei. Er hat dann drei Tage erfolglos getestet, die VMs geclont – kam aber nicht weiter. Er merkte an, dass die Virtualisierung mit VMware Workstation 17.x unter Windows 10 immer gut funktionierte.

Da war doch was mit VBS

Mir fiel sofort mein Blog-Beitrag Windows 11: Virtualbox kollidiert mit Hyper-V? vom Januar 2025 ein. Dort hatte ich über langsame VMs unter Virtualbox berichtet. Die Ursache sind die Virtualisierungsfunktionen (Virtual Based Security, VBS, etc.), die in Windows 11 24H2 exzessiv eingesetzt werden und mit bestimmten Virtualbox-Versionen kollidieren.

In den Kommentaren zum Blog-Beitrag hat sich Wolf gemeldet und schrieb, das die ganze VBS ist auch unter VMWare ein Problem sei (möglicherweise nicht so ausgeprägt, wie bei Virtualbox). Wenn Hyper-V (auch VBS, sieht man in msinfo32 unter "Virtualisierungsbasierte Sicherheit") aktiviert ist, könne es auch auf dieser Plattform zu Performanceproblemen kommen, hieß es.

Der Leser schrieb, dass er auf seinen Maschinen, auf denen ein VM laufen muss, VBS komplett abgeschaltet werde. Dies sei manchmal gar nicht so einfach – er verlinkte auf den GitHub-Beitrag disabledevicegard.ps1 (ein PowerShell-Script zum Abschalten des Device Gard sowie der Virtual Based Security, VBS.

Mit komplett abgeschaltetem VBS und Hyper-V funktionieren VMWare Workstation und Virtualbox unter Windows 11 24H2 in der Umgebung des Lesers ohne Probleme und ohne die Virtualbox "green Turtle"-Meldung.

VMware als Administrator ausführen hilft

Blog-Leser Kay schrieb mir in seine E-Mail, dass er nach viel testen den "Fehler" gefunden  habe Sobald er VMware Workstation über das Benutzerkonto Administrator  öffnet (der Benutzer Admin funktionierte nicht), läuft alles flüssig in der VM. Er fragte, ob ich schon mal von dem Problem gehört habe, oder ob es noch eine andere Einstellung gebe, um die VM unter Windows 11 24H2 wieder normal starten zu können?

Ich habe ja oben die vermutliche Ursache unter Windows 11 24H2 skizziert. Gehe ich im Internet auf die Suche, werden auf reddit.com Einträge wie Performance Issue – Workstation 17.x – Win11 Pro, und Slow virtualization on Windows 11 [VMware Workstation Pro] ausgeworfen.

Im letztgenannten reddit.com-Beitrag schreibt jemand, dass das Effizienzproblem unter Windows 11 von den Intel-Prozessoren kommt. Das Problem rührt von der Art und Weise her, wie Windows 11 die Aufgaben den P- und E-Kernen auf 12/13/14th Gen Intel CPUs zuweist. In der Standardkonfiguration von VMWare wird alles den Effizienzkernen zugewiesen, weshalb es so langsam ist. Ich hatte dieses Thema bereits im Beitrag Windows 11: (P-Core-)Probleme mit Intel Hybrid-CPUs und Netzwerktreibern in anderem Zusammenhang erwähnt.

Es deutet sich an, dass weder Microsoft noch VMWare sich seit zwei Jahren des Problems  bewusst sind oder ein Lösung effektiv kommunizieren. Die Lösung sei aber recht einfach, heißt es: "Starten Sie VMWare als Administrator. Sie können auch den Energiemodus auf „Beste Leistung" umstellen, was einen zusätzlichen Geschwindigkeitsschub von 10-15% bringt." Also genau das, was der Blog-Leser auch herausgefunden hat.

Im reddit.com-Thread heißt es noch, dass es einige andere Lösungen gibt, wie z. B. das Deaktivieren der E-Cores im BIOS, oder in der vmx-Konfigurationsdatei, oder das Einstellen der Prozesspriorität auf hoch (wenn die VM im Fokus ist) in den VM-Einstellungen. Aber nichts davon sei notwendig, wenn die VMWare als Administrator  ausgeführt wird.


Anzeige

Dieser Beitrag wurde unter Problem, Virtualisierung, Windows abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

12 Antworten zu Windows 11 24H2: VMware Workstation Pro 17.x extrem langsam

  1. Thomas E. sagt:

    Ich hatte ein ähnliches Problem diese Woche – allerdings noch unter Win11 23H2.
    Bei mir hat ein Upgrade auf die neuste Version 17.6.2 geholfen.

    new version provides significant performance increase:
    old version CPU Mark – 8197 (Version 17.5.1)
    new version CPU Mark – 26907 (Version 17.6.2)

  2. Blubmann sagt:

    Habe ähnlich Phänomen mit einer Win XP-VM unter 24H2 und VMware 17.6.2. Scrollen in bestimmten Anwendungen innerhalb der VM lasten die vCores zu 100% aus. Weise ich mehr vCores zu werden auch diese zu 100% ausgelastet. Das Problem ist reproduzierbar und unter 23H2 nicht vorhanden. Auch unter Virtual Box lässt sich das Problem nicht nachvollziehen. Habe eigentlich schon alles was oben beschrieben ist getestet – ohne Erfolg. Werde wohl auf VirtualBix umsteigen müssen

  3. Anonym sagt:

    Kann es bestätigen,
    bis einschließlich V17.6.1 hatte workstation ein Problem mit den P- und E-Kernen auf 12/13/14th Gen Intel CPUs.
    da musste man chon in der .vmx bestimmte Cores deaktivieren.

    Nach dem Update auf v17.6.2 läuft alles wieder super, man muss nicht manuell eingreifen

  4. GeneralFailure sagt:

    Hatte nur Probleme mit VMWare Workstation unter Windows 11 24H2. Jetzt nutze ich VirtualBox und habe keine Probleme mehr.

  5. Morku sagt:

    Statt irgend ein random ps1 Skript auszuführen, würde ich den offiziellen Weg über gpedit gehen: Computerkonfiguration\Administrative Vorlagen\System\Device Guard\Virtualisierungsbasierte Sicherheit aktivieren -> Deaktivieren.

    Das setzt folgende Registry Einträge:
    reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard" /f /t REG_DWORD /v "EnableVirtualizationBasedSecurity" /d 0
    reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa" /f /t REG_DWORD /v "LsaCfgFlags" /d 0

    Das ist auch der Weg, den VMware in einem KB Artikel empfiehlt, um VBS zu deaktivieren.

    • Wolf sagt:

      Schon mal selbst versucht? Mit einem frischen 24H2 vom Stick installiert (also nicht von 23H2 upgedated)? Das ging nur bis 23H2. Jetzt (24H2) kannst du das gerne deaktivieren, wie du es beschreibst, aber die VBS (Virtual Based Security) läuft weiter und die Performance ist grottig bei Virtualbox und auch VmWare meldet bei der Installation, dass die "VM-Plattform" mit aktiviert werden muss und das Site-Mitigation deaktiviert wird.

      Das Script kannst du ja im Editor ansehen. Da siehst du genau, was gemacht wird. Hat nichts mit random oder dubios zu tun.

      Nach dem Sript ist die VBS jedenfalls aus, nach deinen Maßnahmen definitiv nicht. Wohlgemert, wenn 24H2 frisch installiert wird und nicht upgedated wird. Nach dem Update ist es nämlich auch auf "aus".

      Soweit wie du mit den Registry-Einträgen oder den Gruppenrichtlinien war ich vorher auch schon.

      Ein Weg bei einer Neuinstallation von 24H2 geht auch noch: im BIOS die Funktion für die Virtualisierung abschalten, danach fertig installieren und erst am Schluss wieder im BIOS die Funktion aktivieren, dann installiert Windows ohne VBS.

      • Morku sagt:

        Ja, habe ich. Sonst würde ich es nicht empfehlen. Bis 23H2 hat es ausgereicht in der Windows-Sicherheit die Speicher-Integrität zu deaktivieren, um die Virtualisierungsbasierte-Sicher zu deaktivieren.
        Seit 24H2 reicht das nicht mehr aus und ich war auf der Suche.
        Die Lösung stellt Broadcom bereit und scheint nichts neues zu sein.
        https://knowledge.broadcom.com/external/article/315385
        Nach Umsetzung steht Virtualisierungsbasierte Sicherheit auf "Nicht aktiviert" und auch Workstation meckert nicht mehr rum.
        Ich will aber niemand davon abhalten in seiner Registry rumzulöschen.

      • Anonym sagt:

        Mir war auch aufgefallen das bei einer Neuinstallation mit 24H2 VBS nicht mehr komplett deaktiviert wird wenn man die Speicher-Integrität deaktiviert wird.

        Ich habe dafür folgende Lösung für mich gefunden:

        In der Registry unter Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard

        lösche ich die drei Einträge:
        EnableVirtualizationBasedSecurity
        WasEnabledBy
        HyperVVirtualizationBasedSecurityOptOut

        Damit sieht der entsprechende Registry Pfad dann auch aus wie auf einem System das mit deaktiviertem VBS von 23H2 auf 24H2 aktualsieirt wurde. Nach einem Neustart ist VBS dann laut Systeminformationen komplett aus.

  6. Anonym sagt:

    Ist das nicht eine alte Kamelle?

    Der Fix wurde im September 2024 rum eingespielt, mit der 17.6.0 und ab dann ging das nachweislich auch ohne Admin Rechte.
    Dann kam im Oktober 2024 17.6.1 wegen dem Problem mit dem "Betriebssystem muss englisch sein" Installationsproblem.
    17.6.2 ist eher kosmetischer Natur wegen dem Lizenzierungssthema.

  7. Gast sagt:

    Ich experimentiere hier mit Hyper-V, VMware und Virtualbox als Hosts für verschiedene Windows- und Linux-Installationen.
    Die eierlegende Wollmilchsau habe ich noch nicht gefunden, irgendwas klemmt immer.

    Bei VMWare habe ich 3 Linux-Varianten installiert, mit Netzwerk auf NAT, null Problemo, bis zum Neustart nach der Installation, dann haben die Ethernetadapter gestreikt, die Performance unter Mint war akzeptabel, Tuxedo naja und OpenSuse für die Tonne. Mustte dann die physikalische Netzwerkkarte des Host brücken, dann ging es.

    Im Netz gab es einige Hinweise, dass es mit der Version 17.X nicht mehr so gut läuft.

    Ich lade gerade die neue W-11-ISO runter und probiere es mal.

    • Gast sagt:

      Nachdem ich die 3-D-Beschleunigung der Grafik deaktiviert habe, läuft Linux gefühlt besser.
      Die aktuelle W-11-Installation stottert nicht bisher, installiert aber nich Updates, mal sehen, was nach dem Neustart passiert.

      Host: W11Pro 24H2, 32 GB RAM, m.2-SSDs, Prozessor Ryzen 7 5700G
      VMware: 17.6.2 build-24409262

      Das Einzige was nervt, ist, dass die Gastsitzungen gerne mal einfrieren, zumindest die Anzeige, ich muss dann immer die Fenstergröße ändern, um es wiederzubeleben.

  8. Old-School sagt:

    Hallo zusammen,

    Betriebssystem -> Windows 24H2 (26100.3194)
    Treiber (nicht Installation Standard) -> Nvidia GeForce 572.16 Studio
    Hardware -> Acer Predator PT516-51s-713V (64GB RAM, SSD 990 Pro 1TB x2)
    Firmware -> alle Komponenten aktuell

    Virtualisierung -> VMware Workstation 17.6.2
    Memory -> Fit all virtual machine memory into reserved host RAM
    Enabling side channel mitigations may cause performance degradation -> nicht aktiviert
    Modus -> Benutzer
    V-Machinen -> Windows 10, Windows 11 23H2, Windows 11 24H2, Linux Mint 22.1

    Probleme -> keine, läuft genau so perfekt wie unter Windows 10

    Aber…, ist WLAN aktiviert (Host), also keine Verbindung über Netzwerkkabel,
    ist der Zugriff der VMware Gäste auf ein freigegebenes Netzwerklauf auf dem Host
    quälend langsam. Das kopieren einer 1MB Datei dauert Minuten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.