Click on the Category button to get more articles regarding that product.
Es gibt einige Server, bei denen Sie nicht in den Wiederherstellungsmodus oder den abgesicherten Modus booten können. Wenn das Volume nicht verschlüsselt ist, haben Sie eine Möglichkeit, die fehlerhafte CrowdStrike-Def-Datei von der Festplatte zu löschen.
Basisartikel von uns:
https://www.butsch.ch/post/19-07-2024-bsod-blue-screen-crowdstrike/
Um eine virtuelle Festplatte in einer VMware-Umgebung von einem Server auf einen anderen zu verschieben und eine Datei auf der Festplatte zu ändern, befolgen Sie diese Schritte:
1. Trennen Sie das Festplattvolumen:
- Schalten Sie den betroffenen virtuellen Server aus.
- Öffnen Sie den VMware vSphere-Client und navigieren Sie zur betroffenen VM.
- Wählen Sie die VM aus, gehen Sie zu “Einstellungen bearbeiten”, suchen Sie die Festplatte, die Sie trennen möchten, und entfernen Sie sie. Stellen Sie sicher, dass Sie die Festplatte nicht aus dem Datenspeicher löschen, sondern nur aus der VM-Konfiguration entfernen.
2. Erstellen Sie einen Snapshot oder Backup:
- Erstellen Sie vor dem Fortfahren einen Snapshot oder ein Backup des Festplattvolumens, um Datenverlust bei unbeabsichtigten Änderungen zu vermeiden.
3. Fügen Sie die Festplatte zu einem neuen virtuellen Server hinzu:
- Navigieren Sie zum neuen virtuellen Server, bei dem Sie die Festplatte anschliessen möchten.
- Gehen Sie im vSphere-Client zu “Einstellungen bearbeiten” für die neue VM.
- Klicken Sie auf “Hinzufügen”, um eine neue Festplatte hinzuzufügen, und wählen Sie “Vorhandene virtuelle Festplatte verwenden”.
- Durchsuchen Sie den Speicherort der getrennten Festplatte und fügen Sie sie zur Konfiguration des neuen Servers hinzu.
4. Ändern Sie die erforderliche Datei:
- Schalten Sie die neue VM mit der angeschlossenen Festplatte ein.
- Sobald die VM läuft, greifen Sie auf das Dateisystem der angeschlossenen Festplatte zu.
- Navigieren Sie zum Verzeichnis, in dem sich die erforderliche Datei befindet, z.B.: `C:\Windows\System32\drivers\CrowdStrike`.
- Suchen und löschen Sie die problematische Datei (z.B. `C-00000291*.sys`).
5. Trennen und Wiederanbringen des reparierten Volumens:
- Schalten Sie die neue VM aus.
- Entfernen Sie im vSphere-Client die Festplatte aus der Konfiguration der neuen VM, ohne sie aus dem Datenspeicher zu löschen.
- Gehen Sie zurück zur ursprünglichen betroffenen VM und bringen Sie die Festplatte wieder an, indem Sie eine vorhandene virtuelle Festplatte hinzufügen und das reparierte Volumen auswählen.
6. Schalten Sie die ursprüngliche VM ein:
- Starten Sie die ursprüngliche VM und überprüfen Sie, ob die Änderungen das Problem behoben haben. Falls nein siehe weiter unten > Drive letter anpassen
Dieses Verfahren stellt sicher, dass die problematische Datei entfernt wird, während die Datenintegrität erhalten bleibt. Es nutzt die Flexibilität von VMware bei der Handhabung virtueller Festplatten, indem Sie die Festplatteninhalte ändern, indem Sie sie vorübergehend an eine andere VM anhängen.
Winload.exe error code 0xc000000e on an Azure VM – Azure | Microsoft Learn
https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/error-code-0xc000000e
|
Falls “winload.exe boot manager error“ |
|
Follow the instructions in the document to run bcdedit repairs on your boot directory. So in our case, that meant the following — replace F: and H: with the appropriate drive letters.
Note that the document says you need to delete your original VM — we found that just swapping out the disk was OK and we did not need to actually delete and recreate anything, but YMMV.
bcdedit /store F:\boot\bcd /set {bootmgr} device partition=F:
bcdedit /store F:\boot\bcd /set {bootmgr} integrityservices enable
bcdedit /store F:\boot\bcd /set {af3872a5-<therestofyourguid>} device partition=H:
bcdedit /store F:\boot\bcd /set {af3872a5-<therestofyourguid>} integrityservices enable
bcdedit /store F:\boot\bcd /set {af3872a5-<therestofyourguid>} recoveryenabled Off
bcdedit /store F:\boot\bcd /set {af3872a5-<therestofyourguid>} osdevice partition=H:
bcdedit /store F:\boot\bcd /set {af3872a5-<therestofyourguid>} bootstatuspolicy IgnoreAllFailures
|
Also read for AZURE VM:
Attach an unmanaged disk to a VM for offline repair – Azure | Microsoft Learn
Also read for AZURE VM with Bitlocker Disks:
Unlocking an encrypted disk for offline repair – Azure | Microsoft Learn
AWS-specific documentation:
To attach an EBS volume to an instance:
Detach an Amazon EBS volume from an instance:
https://docs.aws.amazon.com/ebs/latest/userguide/ebs-detaching-volume.html
Bitlocker recovery
related KB‘s:
BitLocker recovery in Microsoft Azure: https://www.crowdstrike.com/wp-content/uploads/2024/07/BitLocker-recovery-in-Microsoft-Azure.pdf
BitLocker recovery in Microsoft environments using SCCM: https://www.crowdstrike.com/wp-content/uploads/2024/07/BitLocker-recovery-in-Microsoft-environments-using-SCCM.pdf
BitLocker recovery in Microsoft environments using Active Directory and GPOs: https://www.crowdstrike.com/wp-content/uploads/2024/07/BitLocker-recovery-in-Microsoft-environments-using-Active-Directory-and-GPOs.pdf
BitLocker recovery in Microsoft environments using Ivanti Endpoint Manager: https://www.crowdstrike.com/wp-content/uploads/2024/07/BitLocker-recovery-in-Microsoft-environments-using-Ivanti-Endpoint-Manager.pdf
BitLocker recovery: known issues – Windows Client | Microsoft Learn
Zusätzlich haben wir einige Chats bezüglich AWS EC2 von unseren Cloud-nativen Administratoren gesehen:
https://www.redditmedia.com/r/aws/comments/1e6ykzy/how_to_boot_windows_ec2_instance_into_recovery/
Bitte prüfen Sie dies und erstellen Sie einen neuen Abschnitt speziell für EC2: Ich habe vorgeschlagen, es mit EC2Rescue zu versuchen, aber es benötigt dennoch eine andere EC2-Instanz in derselben AWS-Region, um das Volumen zu mounten.
Also werde ich denselben Weg gehen – eine neue WIN EC2-Instanz in derselben Verfügbarkeitszone erstellen, das EBS-Volumen mounten, die Datei löschen und das Volumen dann wieder an die ursprüngliche EC2-Instanz anschließen.
https://azure.status.microsoft/en-us/status
