VMware Workstation und Device / Credential Guard sind nicht kompatibel

Ich habe VMware im letzten Jahr ohne Probleme ausgeführt. Heute habe ich es geöffnet, um eine meiner VMs zu starten und eine Fehlermeldung zu erhalten (siehe Screenshot).

Ich bin dem Link gefolgt und habe die Schritte durchlaufen. In Schritt 4 muss ich ein Volume mit "mountvol" bereitstellen. Wenn ich versuche, ein Volume mountvol X: \\?\Volume{5593b5bd-0000-0000-0000-c0f373000000}\damit zu mounten, wird immer wieder gesagt, dass The directory is not empty.ich sogar eine Partition mit 2 GB und immer noch dieselbe Meldung erstellt habe.

Meine Fragen:

Wie kann ich das Volume bereitstellen, das nicht leer ist, obwohl es leer ist?

Warum hat sich dieser Device / Credential Guard automatisch aktiviert und wie kann ich ihn entfernen oder deaktivieren?

CMD:

Device / Credential Guard ist ein Hyper-V-basierter Virtual Machine / Virtual Secure-Modus , der einen sicheren Kernel hostet, um Windows 10 wesentlich sicherer zu machen.

... ist die VSM-Instanz von den normalen Betriebssystemfunktionen getrennt und durch Versuche geschützt, Informationen in diesem Modus zu lesen. Die Schutzfunktionen werden durch Hardware unterstützt, da der Hypervisor die Hardware auffordert, diese Speicherseiten unterschiedlich zu behandeln. Dies ist der gleiche Weg, auf dem zwei virtuelle Maschinen auf demselben Host nicht miteinander interagieren können. Ihr Speicher ist unabhängig und hardwarereguliert, um sicherzustellen, dass jede VM nur auf ihre eigenen Daten zugreifen kann.

Von hier aus haben wir jetzt einen geschützten Modus, in dem wir sicherheitsrelevante Vorgänge ausführen können. Zum Zeitpunkt des Schreibens unterstützen wir drei Funktionen, die sich hier befinden können: die Local Security Authority (LSA) und die Funktionen zur Steuerung der Code-Integrität in Form der Kernel-Modus-Code-Integrität (KMCI) und die Hypervisor-Code-Integritätssteuerung selbst, die aufgerufen wird Hypervisor Code Integrity (HVCI).

Wenn diese Funktionen von Trustlets in VSM verwaltet werden, kommuniziert das Host-Betriebssystem einfach über Standardkanäle und -funktionen innerhalb des Betriebssystems mit ihnen. Während diese Trustlet-spezifische Kommunikation zulässig ist, ist es erheblich schwieriger, wenn böswilliger Code oder Benutzer im Host-Betriebssystem versuchen, die Daten in VSM zu lesen oder zu bearbeiten, als auf einem System ohne diese Konfiguration, was den Sicherheitsvorteil bietet.

Wenn Sie LSA in VSM ausführen, verbleibt der LSA-Prozess selbst (LSASS) im Host-Betriebssystem, und eine spezielle zusätzliche Instanz von LSA (LSAIso - steht für LSA Isolated) wird erstellt. Auf diese Weise können alle Standardanrufe an LSA weiterhin erfolgreich ausgeführt werden und bieten eine hervorragende Legacy- und Abwärtskompatibilität, selbst für Dienste oder Funktionen, die eine direkte Kommunikation mit LSA erfordern. In dieser Hinsicht können Sie sich die verbleibende LSA-Instanz im Host-Betriebssystem als eine "Proxy" - oder "Stub" -Instanz vorstellen, die einfach auf vorgeschriebene Weise mit der isolierten Version kommuniziert.

Und Hyper-V und VMware funktionierten erst 2020 zur gleichen Zeit , als VMware die Hyper-V-Plattform verwendete, um ab Version 15.5.5 mit Hyper-V zusammen zu existieren .

Wie funktioniert VMware Workstation vor Version 15.5.5?

VMware Workstation verwendet traditionell einen Virtual Machine Monitor (VMM), der im privilegierten Modus arbeitet und direkten Zugriff auf die CPU sowie Zugriff auf die integrierte Virtualisierungsunterstützung der CPU (Intel VT-x und AMD AMD-V) erfordert. Wenn ein Windows-Host die Funktionen "Virtualization Based Security" ("VBS") aktiviert, fügt Windows eine auf Hyper-V basierende Hypervisor-Schicht zwischen der Hardware und Windows hinzu. Jeder Versuch, den herkömmlichen VMM von VMware auszuführen, schlägt fehl, da der VMM in Hyper-V keinen Zugriff mehr auf die Virtualisierungsunterstützung der Hardware hat.

Einführung in User Level Monitor

Um dieses Problem mit der Hyper-V / Host-VBS-Kompatibilität zu beheben, hat das VMware-Plattformteam den Hypervisor von VMware neu strukturiert, um die WHP-APIs von Microsoft zu verwenden. Dies bedeutet, dass unser VMM so geändert wird, dass es auf Benutzerebene anstatt im privilegierten Modus ausgeführt wird, und dass es so geändert wird, dass die Ausführung eines Gasts mithilfe der WHP-APIs verwaltet wird, anstatt die zugrunde liegende Hardware direkt zu verwenden.

Was bedeutet das für dich?

VMware Workstation / Player kann jetzt ausgeführt werden, wenn Hyper-V aktiviert ist. Sie müssen sich nicht mehr zwischen der Ausführung von VMware Workstation- und Windows-Funktionen wie WSL, Device Guard und Credential Guard entscheiden. Wenn Hyper-V aktiviert ist, wird automatisch der ULM-Modus verwendet, sodass Sie VMware Workstation normal ausführen können. Wenn Sie Hyper-V überhaupt nicht verwenden, ist VMware Workstation intelligent genug, um dies zu erkennen, und der VMM wird verwendet.

System Anforderungen

Zum Ausführen von Workstation / Player mithilfe der Windows Hypervisor-APIs ist mindestens die Windows 10 20H1-Version 19041.264 erforderlich. Die Mindestversion von VMware Workstation / Player beträgt 15.5.5.

Um den Fehler zu vermeiden, aktualisieren Sie Windows 10 auf Version 2004 / Build 19041 (Mai 2020 Update) und verwenden Sie mindestens VMware 15.5.5 .

Es gibt einen viel besseren Weg, um dieses Problem zu lösen. Anstatt Hyper-V vollständig zu entfernen, führen Sie einfach einen alternativen Start durch, um es vorübergehend zu deaktivieren, wenn Sie VMWare verwenden müssen. Wie hier gezeigt ...

http://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx

C:\>bcdedit /copy {current} /d "No Hyper-V" 
The entry was successfully copied to {ff-23-113-824e-5c5144ea}. 

C:\>bcdedit /set {ff-23-113-824e-5c5144ea} hypervisorlaunchtype off 
The operation completed successfully.

Hinweis: Die aus dem ersten Befehl generierte ID wird im zweiten verwendet. Führen Sie es nicht nur wörtlich aus.

Wenn Sie neu starten, sehen Sie nur ein Menü mit zwei Optionen ...

• Windows 10
• Kein Hyper-V

Die Verwendung von VMWare ist also nur eine Frage des Neustarts und der Auswahl der Option Kein Hyper-V.

Wenn Sie einen Starteintrag erneut entfernen möchten. Sie können die Option / delete für bcdedit verwenden.

Holen Sie sich zunächst eine Liste der aktuellen Starteinträge ...

C:\>bcdedit /v

Dies listet alle Einträge mit ihren IDs auf. Kopieren Sie die entsprechende ID und entfernen Sie sie dann wie folgt ...

C:\>bcdedit /delete {ff-23-113-824e-5c5144ea}

Wie in den Kommentaren erwähnt, müssen Sie dies über eine Eingabeaufforderung mit erhöhten Rechten und nicht über Powershell tun. In Powershell wird der Befehl fehlerhaft sein.

Update: Es ist möglich, diese Befehle in Powershell auszuführen, wenn die geschweiften Klammern mit einem Backtick (`) maskiert werden. Wie so ...

C:\WINDOWS\system32> bcdedit /copy `{current`} /d "No Hyper-V"

Ich bin immer noch nicht davon überzeugt, dass Hyper-V das Ding für mich ist, selbst mit den Docker-Versuchen und Schwierigkeiten des letzten Jahres, und ich denke, Sie möchten nicht sehr häufig wechseln, anstatt einen neuen Boot zu erstellen und den Boot-Standard zu bestätigen oder Warten auf das Timeout bei jedem Start, den ich bei Bedarf in der Konsole im Admin-Modus durch einschalte

bcdedit /set hypervisorlaunchtype off

Ein weiterer Grund für diesen Beitrag - um Ihnen Kopfschmerzen zu ersparen: Sie dachten, Sie schalten Hyper-V mit dem Argument "Ein" wieder ein? Nee. Zu einfach für MiRKoS..t. Es ist automatisch !

Habe Spaß!
G.

Um es super einfach zu machen:

1. Laden Sie dieses Skript einfach direkt von Microsoft herunter .

2. Führen Sie Ihre Powershell als Administrator aus und führen Sie dann die folgenden Befehle aus:

   • Überprüfen, ob DG / CG aktiviert ist DG_Readiness.ps1 -Ready
   • DG / CG deaktivieren. DG_Readiness.ps1 -Disable

Für diejenigen, die möglicherweise auf dieses Problem mit den letzten Änderungen an Ihrem Computer mit Hyper-V stoßen, müssen Sie es deaktivieren, während Sie VMWare oder VirtualBox verwenden. Sie arbeiten nicht zusammen. Für Windows Sandbox und WSL 2 muss Hyper-V Hypervisor aktiviert sein, wodurch VMWare derzeit beschädigt wird. Grundsätzlich müssen Sie die folgenden Befehle ausführen, um Hyper-V-Dienste beim nächsten Neustart zu aktivieren / deaktivieren.

So deaktivieren Sie Hyper-V und bringen VMWare in PowerShell als Administrator zum Laufen:

bcdedit /set hypervisorlaunchtype off

So aktivieren Sie Hyper-V erneut und brechen VMWare vorerst in PowerShell als Administrator:

bcdedit /set hypervisorlaunchtype auto

Danach müssen Sie neu starten. Ich habe ein PowerShell-Skript geschrieben, das dies für Sie umschaltet und mit Dialogfeldern bestätigt. Mit dieser Technik wird es sogar selbst zum Administrator sodass Sie mit der rechten Maustaste auf das Skript klicken und es ausführen können, um Ihren Hyper-V-Modus schnell zu ändern. Es könnte leicht geändert werden, um auch für Sie neu zu starten, aber ich persönlich wollte nicht, dass das passiert. Speichern Sie dies als hypervisor.ps1 und stellen Sie sicher, dass Sie ausgeführt Set-ExecutionPolicy RemoteSignedwerden, damit Sie PowerShell-Skripts ausführen können.

# Get the ID and security principal of the current user account
$myWindowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent();
$myWindowsPrincipal = New-Object System.Security.Principal.WindowsPrincipal($myWindowsID);

# Get the security principal for the administrator role
$adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator;

# Check to see if we are currently running as an administrator
if ($myWindowsPrincipal.IsInRole($adminRole))
{
    # We are running as an administrator, so change the title and background colour to indicate this
    $Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + "(Elevated)";
    $Host.UI.RawUI.BackgroundColor = "DarkBlue";
    Clear-Host;
}
else {
    # We are not running as an administrator, so relaunch as administrator

    # Create a new process object that starts PowerShell
    $newProcess = New-Object System.Diagnostics.ProcessStartInfo "PowerShell";

    # Specify the current script path and name as a parameter with added scope and support for scripts with spaces in it's path
    $newProcess.Arguments = "-windowstyle hidden & '" + $script:MyInvocation.MyCommand.Path + "'"

    # Indicate that the process should be elevated
    $newProcess.Verb = "runas";

    # Start the new process
    [System.Diagnostics.Process]::Start($newProcess);

    # Exit from the current, unelevated, process
    Exit;
}

Add-Type -AssemblyName System.Windows.Forms


$state = bcdedit /enum | Select-String -Pattern 'hypervisorlaunchtype\s*(\w+)\s*'


if ($state.matches.groups[1].ToString() -eq "Off"){

    $UserResponse= [System.Windows.Forms.MessageBox]::Show("Enable Hyper-V?" , "Hypervisor" , 4)

    if ($UserResponse -eq "YES" ) 
    {

        bcdedit /set hypervisorlaunchtype auto
        [System.Windows.Forms.MessageBox]::Show("Enabled Hyper-V. Reboot to apply." , "Hypervisor")

    } 

    else 

    { 

        [System.Windows.Forms.MessageBox]::Show("No change was made." , "Hypervisor")
        exit

    }

} else {

    $UserResponse= [System.Windows.Forms.MessageBox]::Show("Disable Hyper-V?" , "Hypervisor" , 4)

    if ($UserResponse -eq "YES" ) 
    {

        bcdedit /set hypervisorlaunchtype off
        [System.Windows.Forms.MessageBox]::Show("Disabled Hyper-V. Reboot to apply." , "Hypervisor")

    } 

    else 

    { 

        [System.Windows.Forms.MessageBox]::Show("No change was made." , "Hypervisor")
        exit

    }

}

Die einfachste Lösung für dieses Problem besteht darin, das Hardware-Bereitschaftstool "Device Guard" und "Credential Guard" herunterzuladen, um die Inkompatibilität zu beheben:

• https://www.microsoft.com/en-us/download/details.aspx?id=53337
• Dekomprimieren Sie den Reißverschluss
• du wirst finden :

• Führen Sie die "DG_Readiness_Tool_v3.6.ps1" mit PowerShell aus

• Jetzt sollten Sie Ihre virtuelle Maschine normal einschalten können.

Ich weiß nicht warum, aber Version 3.6 von DG_Readiness_Tool hat bei mir nicht funktioniert. Nach dem Neustart bestand mein Laptop-Problem weiterhin. Ich suchte nach einer Lösung und stieß schließlich auf Version 3.7 des Tools, und dieses Mal verschwand das Problem. Hier finden Sie das neueste Powershell-Skript:

DG_Readiness_Tool_v3.7

Ich hatte auch viel mit diesem Problem zu kämpfen. Die Antworten in diesem Thread waren hilfreich, reichten jedoch nicht aus, um meinen Fehler zu beheben. Sie müssen Hyper-V und Device Guard deaktivieren, wie in den anderen Antworten vorgeschlagen. Weitere Infos dazu finden Sie hier .

Ich füge die Änderungen hinzu, die zusätzlich zu den oben angegebenen Antworten vorgenommen werden müssen. Der Link, der mir schließlich geholfen hat, war dieser .

Meine Antwort wird nur den Unterschied zwischen den restlichen Antworten (dh Deaktivieren von Hyper-V und Device Guard) und den folgenden Schritten zusammenfassen:

1. Wenn Sie Gruppenrichtlinien verwendet haben, deaktivieren Sie die Gruppenrichtlinieneinstellung, die Sie zum Aktivieren von Windows Defender Credential Guard verwendet haben (Computerkonfiguration -> Administrative Vorlagen -> System -> Geräteschutz -> Virtualisierungsbasierte Sicherheit aktivieren).

2. Löschen Sie die folgenden Registrierungseinstellungen:

   HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ LSA \ LsaCfgFlags HKEY_LOCAL_MACHINE \ Software \ Richtlinien \ Microsoft \ Windows \ DeviceGuard \ EnableVirtualizationBasedSecurity HKEY_LOCAL_MACHINE \ Software \ Policies \ Microsoft \ Windows \ DeviceG

   Wichtig: Wenn Sie diese Registrierungseinstellungen manuell entfernen, müssen Sie alle löschen. Wenn Sie nicht alle entfernen, wird das Gerät möglicherweise in die BitLocker-Wiederherstellung versetzt.

3. Löschen Sie die EFI-Variablen von Windows Defender Credential Guard mithilfe von bcdedit. Geben Sie an einer Eingabeaufforderung mit erhöhten Rechten (Start im Administratormodus) die folgenden Befehle ein:

    mountvol X: /s
   
    copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
   
    bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
   
    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
   
    bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
   
    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
   
    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
   
    mountvol X: /d
   

4. Starten Sie den PC neu.

5. Akzeptieren Sie die Aufforderung zum Deaktivieren von Windows Defender Credential Guard.

6. Alternativ können Sie die virtualisierungsbasierten Sicherheitsfunktionen deaktivieren, um Windows Defender Credential Guard zu deaktivieren.

SCHNELLE LÖSUNG JEDEN SCHRITT:

Fehler in VMware Workstation unter Windows 10 Host Transport (VMDB) behoben. Fehler -14: Die Rohrverbindung wurde unterbrochen.

Heute werden wir den VMWare-Fehler auf einem Windows 10-Computer beheben.

1. Geben Sie im Feld RUN "gpedit" ein und gehen Sie dann zu [ERROR SEE POINT 3].

1- Computerkonfiguration 2- Administrative Vorlagen 3- System - Device Guard: WENN KEIN GERÄTSCHUTZ: (DOWNLOAD https://www.microsoft.com/en-us/download/100591 Installieren Sie diese "c:\Program Files (x86)\Microsoft Group Policy\Windows 10 November 2019 Update (1909)\PolicyDefinitions" KOPIE auf c:\windows\PolicyDefinitions) 4- Aktivieren Sie Virtualization Based Sicherheit. Doppelklicken Sie jetzt darauf und "Deaktivieren"

2. Öffnen Sie die Eingabeaufforderung als Administrator und geben Sie das folgende gpupdate / force ein.

3. Öffnen Sie den Registrierungseditor und gehen Sie zu HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard. Fügen Sie einen neuen DWORD-Wert mit dem Namen hinzu EnableVirtualizationBasedSecurityund setzen Sie ihn auf 0, um ihn zu deaktivieren. Weiter Gehe zu HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA. Fügen Sie einen neuen DWORD-Wert mit dem Namen hinzu LsaCfgFlagsund setzen Sie ihn auf 0, um ihn zu deaktivieren.

4. Geben Sie im Feld RUN den Befehl Windows-Funktionen ein- oder ausschalten ein, deaktivieren Sie jetzt Hyper-V und starten Sie das System neu.

5. Öffnen Sie die Eingabeaufforderung als Administrator und geben Sie die folgenden Befehle ein

    bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader

    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"

    bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
    
    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS

    bcdedit /set hypervisorlaunchtype off

Starten Sie jetzt Ihr System neu

Wenn Sie zu jeder Zeit eine offene angepasste Eingabeaufforderung "Als Administrator ausführen" oder ein Powershell-Befehlszeilenfenster verwalten, können Sie optional die folgenden Aliase / Makros einrichten, um die Ausführung der von @ gue22 genannten Befehle zum einfachen Deaktivieren des Hyper-V-Hypervisors zu vereinfachen Wenn Sie den VMware-Player oder die Workstation verwenden und diese dann wieder aktivieren müssen, wenn Sie fertig sind.

doskey hpvEnb = choice /c:yn /cs /d n /t 30 /m "Are you running from elevated command prompt" ^& if not errorlevel 2 ( bcdedit /set hypervisorlaunchtype auto ^& echo.^&echo now reboot to enable hyper-v hypervisor )
doskey hpvDis = choice /c:yn /cs /d n /t 30 /m "Are you running from elevated command prompt" ^& if not errorlevel 2 ( bcdedit /set hypervisorlaunchtype off ^& echo.^&echo now reboot to disable hyper-v hypervisor )
doskey bcdL = bcdedit /enum ^& echo.^&echo now see boot configuration data store {current} boot loader settings

Mit den oben genannten Anweisungen geben Sie einfach die Befehle "hpvenb" [Hypervisor beim Booten aktiviert], "hpvdis" [Hypervisor beim Booten deaktiviert] und "bcdl" [Liste der Bootkonfigurationsgeräte] ein, um die Befehle on, off, list auszuführen.

Nun, Jungen und Mädchen, nachdem ich in den frühen Morgenstunden die Versionshinweise für Build 17093 gelesen habe, habe ich den Änderungspunkt gefunden, der sich auf meine VMware Workstation-VMs auswirkt und dazu führt, dass sie nicht funktionieren. Dies sind die Einstellungen für die Kernisolation unter Gerätesicherheit unter Windows-Sicherheit (neuer Name für Windows Defender-Seite) in den Einstellungen .

Standardmäßig ist es aktiviert. Wenn ich es jedoch ausschalte und meinen PC neu starte, funktionieren alle meine VMware-VMs wieder ordnungsgemäß. Möglicherweise könnte im nächsten Build eine Option nach Gerät integriert werden, damit wir einzelne Geräte- / Apps-Antworten testen können, damit die Kernisolation je nach Gerät oder App nach Bedarf ein- oder ausgeschaltet werden kann.

Hier sind die richtigen Anweisungen, damit jeder folgen kann.

• Laden Sie zuerst das Hardware-Bereitschaftstool für Device Guard und Credential Guard von diesem Link herunter: https://www.microsoft.com/en-us/download/details.aspx?id=53337
• Extrahieren Sie den Inhalt des Zip-Ordners an einen Speicherort wie: C: \ guard_tool
• Sie haben Dateien wie diesen Kopierdateinamen der ps1-Erweiterungsdatei in meinem Fall v3.6, also: DG_Readiness_Tool_v3.6.ps1

• Klicken Sie anschließend auf das Startmenü und suchen Sie nach Powershell. Klicken Sie dann mit der rechten Maustaste darauf und führen Sie es als Administrator aus.

• Danach wird das blaue Farbterminal angezeigt. Geben Sie den Befehl cd C: \ guard_tool ein . Ersetzen Sie den Pfad nach cd durch die extrahierte Position des Werkzeugs
• Geben Sie nun den Befehl ein : . \ DG_Readiness_Tool_v3.6.ps1 -Disable
• Nach dem Neustart des Systems
• Wenn Ihr System neu gestartet wird, zeigt das Startzeitsystem eine Benachrichtigung mit schwarzem Hintergrund an, um zu überprüfen, ob Sie diese Funktionen deaktivieren möchten. Drücken Sie daher zur Bestätigung F3.
• mache +1 wenn es geholfen hat :)