Obacht bei Windows 10 2019 (Enterprise LTSC), wenn es um "Virtualization Based Security" (VBS) und Fremd-Virtualisierer wie VMware Workstation geht. Die Tage bin ich in das Problem gelaufen, dass VMware Workstation die Arbeite mit virtuellen Maschinen verweigerte und Virtualbox Bluescreens auslöst. Ich hatte erst ein Update in Verdacht, aber es war eine VBS-Einstellung.
VMware Workstation 17 streikt plötzlich bei VMs
Ich habe mir durch eine unbedachte (blöde) Konfigurierungsänderung an Windows 10 ziemlichen Ärger eingehandelt. Hintergrund ist, dass ich hier ein Windows 10 2019 Enterprise LTSC als Arbeitspferd einsetze. Zur Virtualisierung verwendet ich statt Hyper-V lieber VMware Workstation 17 und Virtualbox 7.1.16.
Und dann stand ich vor der Situation, dass VMware Workstation plötzlich keine VMs mehr starten wollte. Ich bekam beim Versuch, eine VM zu starten, das nachfolgende Dialogfeld zu sehen.
VMware Workstation bemängelte, dass meine Maschine nicht die minimalen Anforderungen als Host erfülle, da Hyper-V oder der Device/Credential Guard aktiviert sei.
Ich wurde auf den VMware-Supportbeitrag KB76918: Error : Your host does not meet minimum requirements to run VMware workstation with hyper-v or device/credential guard enabled verwiesen. Dieser Support-Beitrag ist bereits aus 2024 und besagt folgendes:
Wenn VMware Workstation 15.5.5 oder neuer auf einem Windows-Host ausgeführt wird, auf dem Hyper-V und/oder VBS aktiviert sind, werden VMs mithilfe der Windows Hypervisor Platform-Technologie gestartet. VMs können nicht gestartet werden, wenn die Release-Version dieser Technologie nicht einem bestimmten Stand entspricht oder wenn die Windows-Host-Hardware bestimmte Mindestanforderungen nicht erfüllt. Diese Mindestanforderungen sind im Abschnitt "Ursache" weiter unten beschrieben.
Hieß für mich im ersten Augenblick, dass ich ein Upgrade auf Windows 10 21H2 durchzuführen müsste. Oder ich müsste auf Hyper-V und "Virtualization Based Security" (VBS) verzichten. Der Umstieg auf Windows 10 21H2 IoT Enterprise LTSC wollte ich eigentlich nicht angehen.
Hätte ja gesagt, ich verzichte auf VMware Workstation und verwendet Virtualbox zur Virtualisierung. Aber ich habe seit dem letzten Patchday das Problem, dass der Windows 10-Host mit einem BlueScreen (Hypervisor-Error) abstürzt, sobald ich mit Virtualbox einen Gast ausführe.
Wo liegt der Hund begraben?
So vage hatte ich das Januar 2026 Sicherheitsupdate in Verdacht, dass mir dieses die obigen Probleme bereitet. Im ersten Schritt wollte ich aber noch den Hinweisen aus obigem KB-Artikel nachgehen und sicherstellen, dass keine Virtualisierung durch Windows 10 aktiviert ist.
Kein Hyper-V aktiviert
Also auf Hyper-V und "Virtualization Based Security" (VBS) verzichten? Leichter gesagt als getan. Ich war mir eigentlich ziemlich sicher, Hyper-V vor langer Zeit abgeschaltet zu haben. Eine schnelle Kontrolle in der Systemsteuerung unter Features und Funktionen bestätigte, dass kein Hyper-V als Feature aktiv war.
Keine Kernisolierung aktiviert
Dass ist irgendwie den Credential Guard aktiviert hätte, war mich auch nicht bewusst. Eine schnelle Kontrolle der Optionen für Kernisolierung unter Windows Sicherheit ergab ein differenziertes Bild.
Unter Gerätesicherheit wurde mir in Windows Sicherheit mitgeteilt, dass die virtualisierungsbasierte Sicherheit aktiviert sei. Der Hyperlink Details zur Kernisolierung zeigte mit die nachfolgende Darstellung.
Die Speicher-Integrität war ebenfalls abgeschaltet. Ich habe dann die Systeminformationen aufgerufen und in der Systemübersicht nach dem Eintrag Virtualisierungsbasierte Sicherheit geschaut. Und dort wurde mir mitgeteilt, dass dieses Feature aktiviert sei.
Als ich die Optionen dann so durchging, dämmerte mir was. Vor Wochen war ich in diesem Dialogfeld und hatte die Optionen Containers und Container Image Manager mal "auf Verdacht" aktiviert, weil ich mich eventuell mit Containern unter Windows auseinander setzen wollte. Aber es kam was dazwischen und die Konfigurationsänderung geriet in Vergessenheit.
Also schnell diese Optionen deaktiviert, das Dialogfeld über die OK-Schaltfläche verlassen und dann Windows 10 neue gestartet. Ein schneller Test bestätigte, VMware Workstation konnte wieder virtuelle Maschinen booten – das Problem war gelöst. Nun muss ich bei Gelegenheit eruieren, ob das BlueScreen-Problem mit dem Hypervisor von Virtualbox auch weg ist. Klassischer Fall von "selbst in den Fuß geschossen".
MVP: 2013 – 2016
Ja, über diese "virtualisierungsbasierte Sicherheit" habe ich mich schon vor Jahren geärgert.
Aufgefallen ist es mir beim Monitoring der Client-PCs. Da gab es einige, die hatten plötzlich mehr als ein aktives Netzwerkinterface – teilweise mit Adressen, die sich ungesund mit dem in der Firma genutzten RFC1918-Bereichen überschneiden. Verbunden waren die mit einem Hyper-V-Netzwerkadapter.
Gut, wir haben einige Entwickler, die auch etwas höhere Rechte auf ihrem PC haben und das tatsächlich hätten so einrichten können, gewundert hat es mich trotzdem, da wir eigentlich offiziell VirtualBox für solche Anwendungen einsetzen.
Beim genaueren Hinschauen wurden es immer mehr und vor allem auch auf PCs z.B. in der Verwaltung, deren Nutzer weder das Recht noch das nötige Wissen haben, um sich eine solche Konfiguration zu bauen.
Langer Rede kurzer Sinn: es war die virtualisierungsbasierte Sicherheit, die mit einem Windows-Update gekommen war und sich auf einer Anzahl Rechnern aktiviert hatte. Dabei wird der ganze PC und die Oberfläche, die der Benutzer sieht in eine virtuelle Maschine verschoben, die auf einem schmalen Headless-Hypervisor läuft. Damals nannte sich das Feature "Sandbox".
Schaltet man die ab, ist der Spuk verschwunden.
Man kann allerdings Pech haben, wenn die Geräte per UEFI den ganzen Krempel enforcen. Dann kann es nämlich passieren, dass der Kram auf einmal von selbst wieder an ist. Haben wir bei einigen Geräten gehabt, selbst nachdem wir das Skript von Microsoft zur Abschaltung benutzt haben.
Danke für diese Info. Enforcment über UEFI – das war mir noch nicht bekannt.
Das Ganze nennt sich "UEFI-Lock". Microsoft hat eine Anleitung, wie man Device Guard/Credential Guard abschalten kann in den verschiedensten Varianten. Findest du hier: https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/configure?tabs=intune
Da ist auch der Hinweis auf den UEFI-Lock, aber wie gesagt, ich habe schon Geräte gehabt, wo es sich trotzdem automatisch wieder eingeschaltet hatte, vermutlich nach einem Update.
" Virtualbox 1.1.16 "
Nicht wirklich, ODER?!?
Aktuell ist 7.2.6
> Zur Virtualisierung verwendet ich statt Hyper-V lieber VMware Workstation 17 und Virtualbox 1.1.16.
Man sollte *NICHT* zwei Virtualisierer parallel installieren! Das kann zu Problemen führen. Das war auch schon zu Windows 7 Zeiten so.
Das höre ich das erste Mal, Sorry. Seit Jahren habe ich hier VB und VM WS nebeneinander installiert. Keine Probleme, welche sich die Programme untereinander machen. Auf mehreren Maschinen so. Ok, beide laufen nicht parallel gleichzeitig, da vielleicht ein Problem? Aber entweder eine Maschine in VM ODER eine andere in VB starten, ist so etwas von problemlos.
Wo hast du das denn her? Oder ist es abgeleitet von "man sollte nicht mehrere Virenscanner nebeneinander installieren"?
Erfahrungswerte. Spätestens wenn einem die Netzwerkinterface unspezifisch den Dienst versagen kommt man an den Punkt.
Sorry das gehört zum Grundwissen von Virtualisierung dazu.
– Nur ein Hypervisor kann Ring-1 kontrollieren
– Konkurrenz um CPU-Zeit → ineffiziente Kontextwechsel
– Doppeltes Paging (EPT/NPT) → massiver Overhead
– IOMMU / Passthrough Geräte können nicht sauber zugeordnet werden
– und noch vieles mehr.
Kann ich bestätigen. Als ich mal neben dem VMware-Player zum Vergleich noch die VirtualBox installiert hatte, kam keiner der VMware-Guests mehr ins Internet. Selbstredend hatte ich die VirtualBox dabei nicht laufen. Aber solange sie nicht wieder komplett deinstalliert war, funktionierte es in VMware nicht.
Credential-Guard ist eine Art sehr spezielle virtuelle Maschine, in der Benutzeraccounts gespeichert sind. Damit soll verhindert werden, dass der altbekannte Mimikatz-Angriffsvektor einfach diese Zugangsdaten aus dem RAM holt. Ok, wer darauf verzichten mag…
Moderne Virtualisierer funktionieren auch mit aktiviertem Credential-Guard und HyperV. Aber ich frage mich, warum man noch (veraltete) Versionen von VMWare und Virtual-Box einsetzt, wo aktuelle Versionen problemlos damit umgehen können, oder man nutzt das sowieso vorhandene HyperV, das tut auch. Ist halt wie beim Umstieg von einer Automarke auf eine andere, man muss sich auf andere Bedienphilosophien einlassen WOLLEN.
Danke für diesen Kommentar, ich wollte was ähnliches schreiben.
Zumindest VMware Workstation 17.5 ist nicht wirklich veraltet. Das kann auch mit der "Windows Hypervisor Platform (WHP)" sauber interagieren, die ja genau dafür da ist, anderen Virtualisierern Zugriff auf die Hyper-V Funktionen zu geben, die mit VBS, Device Guard, Credential Guard usw. verwendet werden. Muss man als Feature allerdings in Windows aktivieren (bzw. der Installer von VMware Workstation bietet sogar an, das zu übernehmen).
Das Feature gibt es so weit ich das sehe seit der Version Windows 10 20H1 build 19041.264, sollte also im 21H2 nachinstallierbar sein, es sei denn das dass in der von Günther verwendeten IoT Version nicht existiert.
Mit VirtualBox habe ich das übrigens bisher nicht geschafft das zu benutzen, ich kann auch gerade nichts darüber finden, ob das die Nutzung von WHP unterstützt.
Ich habe mich im Text verlesen, Günther verwendet Windows 10 2019 LTSC, das wird das Feature noch nicht haben, da es erst in 20H1 dazu kam.
Und ich habe anscheinend auch beim Antworten nicht aufgepasst, mein Kommentar sollte eigentlich eine Antwort auf Gänseblümchen sein.
Man könnte natürlich auch einfach VMware im Hyper-V-Fallback Modus nutzen, da hat man massiv weniger Probleme und würde nicht die Sicherheit beeinflussen.
Ich werde mich definitiv nicht auf Hyper-V in neue Abhängigkeiten begeben, zumal es bei Hyper-V diverse Probleme gibt. Es läuft hier ja mit W10 2019 Enterprise LTSC wieder, und ansonsten werde ich auf Mint 22 weiter experimentieren.
Ich vermute mal du meinst mit "Hyper-V Fallback Modus" das Feature "Windows Hypervisor Platform". Das kann Günther nicht benutzen, das kam erst mit Windows 10 20H1, das ist neuer als das von ihm verwendete 2019 LTSC.