
Ich verwende Windows 10 mit DiskCryptor-Volldatenträgerverschlüsselung auf dem Systemlaufwerk. Das neueste Windows 10-Update kann nicht installiert werden. Wenn ich das System neu starte, um das Update zu installieren, tritt die folgende Ereignissequenz auf:
- Ich gebe mein DiskCryptor-Passwort ein, das die Festplatte entsperrt
- Windows Update fragt nach dem Tastaturlayout
- Windows Update schlägt dann kurz danach fehl
Wenn ich den Vorgang weit genug durchführe, wird mir eine Meldung angezeigt, dass der Vorgang nicht fortgesetzt werden kann, da eine oder mehrere Dateien gesperrt sind.
Mein Kollege verwendet auf seinem Systemlaufwerk ebenfalls DiskCryptor und hat die gleiche Erfahrung gemacht.
Also:
- Ist dies generell ein bekanntes Problem bei der Vollplattenverschlüsselung?
- Ist das speziell ein Problem mit DiskCryptor?
- Wenn ja, handelt es sich um einen Fehler, den MS beheben wird, oder ist ein Workaround erforderlich?
Antwort1
Dies scheint ein allgemeines Problem mit Software zur vollständigen Festplattenverschlüsselung zu sein (mit der mutmaßlichen Ausnahme von MS‘ eigenem BitLocker). Vom VeraCrypt-Koordinator selbst:
Update für Windows 10 Version 1511, Build 10586 schlägt fehl
TrueCrypt hätte das gleiche Problem gehabt. Es ist dieses spezielle Windows-Update, das Filtertreiber für die On-the-Fly-Verschlüsselung zu deaktivieren scheint, und wenn Windows mit TrueCrypt verschlüsselt wäre, wäre es auch fehlgeschlagen. Es gibt nichts Magisches im TrueCrypt-Treiber, das dies verhindert hätte.
Microsoft macht etwas Gemeines im Update-Installer. Der VeraCrypt-Treiber funktioniert wie erwartet, aber dieser Installer blockiert ihn offensichtlich während des Aktualisierungsprozesses des Systems. Dadurch beschädigt Microsoft FDE-Software mit Ausnahme von Bitlocker und denen von Microsoft-Partnern.
Wie kann ich dies am besten an Microsoft melden? Offensichtlich fehlt es uns bei VeraCrypt an Personal, um eine derart tiefgreifende Kernel-Blockierung durch das Update-Installationsprogramm weiter zu untersuchen.
Der Workaround ist in einem separatenForumsbeitrag:
Sie müssen die Systemverschlüsselung entschlüsseln, bevor Sie Betriebssystem-Upgrades durchführen.
Außerdem erfordert das Windows 10 November-Update die Entschlüsselung des Betriebssystems, um das Windows 10 1511-Update anzuwenden. Normalerweise ist dies nicht erforderlich.
NOTIZ: Heben Sie die Bereitstellung aller an Ihren PC angeschlossenen externen verschlüsselten Volumes auf und trennen Sie sie, bevor Sie mit dem Betriebssystem-Upgrade beginnen. Ich habe in der Vergangenheit Benutzer darüber klagen hören, dass das Windows-Betriebssystem-Upgrade das verschlüsselte Laufwerk/die verschlüsselte Partition im RAW-Format erkennt und Windows versucht, zu hilfreich zu sein, indem es die Partition automatisch schnell formatiert und ihr einen Laufwerksbuchstaben zuweist, damit sie von Windows verwendet werden kann.
UPDATE: Um den Kreis zu schließen, habe ich die folgenden Schritte ohne negative Auswirkungen durchgeführt. Wie immer,zuerst sichern!! Ich habe mein Backup nicht benötigt, aber ich kann nicht garantieren, dass Sie Ihres nicht benötigen werden ;).
- Entschlüsseln Sie das Systemlaufwerk (höchstwahrscheinlich C:).
- Ich habe eine zweite Festplatte (D:)
- Dieses Laufwerk D: wurde ebenfalls verschlüsselt
- Ich habe mein Laufwerk D: nicht entschlüsselt
- Anwenden des Windows-Updates
- Der DiskCryptor-Bootloader forderte mich bei jedem Neustart weiterhin zur Eingabe eines Passworts auf
- Ich habe einfach [Enter] ohne Passwort gedrückt und die Maschine bootete
- Das Systemlaufwerk erneut verschlüsseln
Kurzer Hinweis zum verschlüsselten Laufwerk D: (sekundäres Laufwerk):
Seien Sie sehr vorsichtig, wenn Windows 10 hochfährt und das Laufwerk C: noch unverschlüsselt ist. In diesem Szenario wird das Laufwerk D: beim Start nicht automatisch gemountet. Wenn Sie auf das Laufwerk D: doppelklicken, erkennt Windows es nicht und bietet Ihnen nicht an, es für Sie zu formatieren. Um das Laufwerk zu mounten, müssen Sie DiskCryptor öffnen, das Laufwerk D: auswählen, auf [Mount] klicken und das Passwort eingeben.
Windows hat nichtautomatischFormatieren Sie mein sekundäres Laufwerk, aber es wäre sehr leicht für mich gewesen, dies versehentlich zu tun. Gehen Sie vorsichtig vor!
Antwort2
Mir ist klar, dass dieser Thread schon etwas älter ist, aber den Suchenden zuliebe … Die Anwesenheit von DiskCryptor verhindert Updates für Windows (10) 1709 (zumindest), ohne dass irgendwelche spezifischen damit verbundenen Fehler gemeldet werden – nur ein Bluescreen am Ende und eine Neuinstallation der alten Version … spielt keine Rolle, ob DiskCryptor-Laufwerke tatsächlich gemountet sind oder nicht.
Die einfache Lösung besteht darin, DiskCryptor zu deinstallieren, die Updates auszuführen und es dann erneut zu installieren. Das hat bei mir funktioniert, nachdem ich tagelang nachgeforscht hatte, warum meine Systeme nicht aktualisiert wurden.
Aber nachdem das Update installiert wurde, hat sich, zumindest mit dem Creators Update, das Verhalten der gemounteten Laufwerke geändert. Gemountete Volumes werden beim Herunterfahren von Windows nicht mehr demontiert. Tatsächlich scheint es, dass DiskCryptor ein Herunterfahren von Windows verhindert, wenn DiskCryptor-Laufwerke gemountet sind, und die Station einfach in den Ruhezustand wechselt (was Sie, wenn Sie nicht aufmerksam sind, möglicherweise nicht bemerken) – beim Aufwachen sind alle Laufwerke noch gemountet! Ich habe dies auf zwei Lenovo-Laptops mit Win 10 Home und einem Desktop mit Win 10 Enterprise getestet – kein Unterschied. Hoffe, das hilft jemandem, und ich hoffe, Windows patcht dies schnell – es sei denn, die Absicht besteht darin, den Wechsel zu BitLocker zu erzwingen :( Übrigens war dieses neue Verhalten nicht vorhanden, als ich es mit TrueCrypt getestet habe. Laufwerke werden beim Herunterfahren automatisch demontiert.
Antwort3
Ich habe ein weiteres Problem mit DiscCryptor und GPT-Festplatte gefunden.
Ich habe mehrere Windows 32 Bits (alle Home-Versionen von Vista bis 10) auf derselben GPT-Festplatte (die einzige vorhandene, es ist ein Laptop mit nur BIOS, kein U-EFI); ja und ja, es ist nur BIOS und die Festplatte ist GPT mit mehr als 4 primären Partitionen, alle Partitionen sind GPT, außer einem kleinen 8-MiB-RAW-GrubBIOS für Grub2 core.img ... und ja, ja, Windows 32 Bits; denken Sie daran, dass Windows von keinen Festplatten bootet, die nicht MBR sind, ich mag Hybrid GPT+MBR nicht, ich bevorzuge kleine Grub2+MemDisk+VHD-Dateien (32 MiB oder weniger).
Meine Festplatte besteht zu 100 % aus GPT und verfügt über eine GPT-NTFS-Partition für jedes Windows des Systems (wo sich der WINDOWS-Ordner befindet, aber der NT60-Bootcode und BCD nicht vorhanden sind). Sie verfügt außerdem über eine zusätzliche NTFS-Partition für Grub2-, MemDisk- und VHD-Dateien (sonst können 32-Bit-Windows nicht von einer GPT-Festplatte gebootet werden, d. h. 32-Bit auf BIOS + GPT-Festplatte). Die VHD-Dateien haben eine feste Größe (nur damit Memdisk sie im RAM emulieren kann). Intern verfügt sie über eine MBR-Festplatte mit nur einer 32-MiB-NTFS-Partition, auf der sich der NT60-Bootcode und der BCD für das jeweilige Windows befinden, also eine VHD pro Windows.
Dies ist ein Beispiel (alle Windows sind 32-Bit- und Home-Versionen, kein Pro, kein Enterprise, kein Server, 100 % legales Zeug) auf der GPT-Festplatte, auf der ich Tests durchführe:
- 1. Sektor = Grub2 Bootcode + GPT Schutz
- GPT1 = 8 MiB RAW GrubBIOS (wo Grub2 core.img in RAW abgelegt hat)
- GPT2 = 1 GiB NTFS für Grub2-Dateien + MemDisk + VHD-Dateien
- GPT3 = NTFS für 32-Bit-Windows Vista SP2-System (Windows-Ordner usw.)
- GPT4 = NTFS für 32-Bit-Windows 7 SP1-System (Windows-Ordner usw.)
- GPT5 = NTFS für 32-Bit-Windows-8-System (Windows-Ordner usw.)
- GPT6 = NTFS für 32-Bit-Windows-8.1-System (Windows-Ordner usw.)
- GPT7 = NTFS für 32-Bit-Windows-10-System (Windows-Ordner usw.)
- GPT ... und so weiter ...
Jede VHD ist eine etwa 32 MiB große virtuelle MBR-Festplatte, wie folgt:
- 1. Sektor = Nt60-Bootcode + MBR-Partitionstabelle
- MBR.1 = Primäres NTFS 32 MiB (wo sich BCD-Sachen befinden)
- MBR.2 = -leer-
- MBR.3 = -leer-
- MBR.4 = -leer-
Eine VHD-Datei pro Fenster (um Bootloader und BCD zu isolieren).
Wenn ich das alles auf einem MBR unterbringen möchte (es ist auf 3 primäre + 1 erweitertes beschränkt), kann ich nur 3 Windows unterbringen (Grub2 kann auf einem logischen Verzeichnis innerhalb des erweiterten liegen), diese 3 primären sind dann diejenigen, die jeweils BCD-Sachen haben (isolierende BCDs aller Windows)... wenn ich alle Windows-BCDs auf derselben Partition zulasse, kann ich so viele Windows unterbringen wie ich will, aber alle teilen sich das BCD, sodass das Startmenü das von Windows angezeigte ist, sie werden nicht isoliert, ein Fehler bei einem von ihnen, der ein solches BCD berührt, wird den Start aller anderen ruinieren usw., ganz zu schweigen davon, dass ich auch Verschlüsselung will.
Mit diesen GPT-, Grub2-, MemDisk- und VHD-Dateien bekomme ich, was ich will (außer der Verschlüsselung) und isoliere jedes Windows zu 100 % vom Rest von Windows.
Ich möchte ein BIOS und kein U-EFI, und zwar aus drei Hauptgründen:
- Ich möchte, dass 100 % der Festplatte (außer dem ersten Sektor, der GPT-Tabelle und der zweiten Kopie der GPT-Tabelle am Ende der Festplatte) verschlüsselt werden. Ich arbeite immer noch daran, wie ich die Partition verschlüsseln kann, die ich für Grub2-, MemDisk- und VHD-Dateien verwende. Ich hatte überlegt, für jede VHD-Datei eine zusätzliche Partition zu erstellen, sodass eine wie das System verschlüsselt wird und dann eine von Grub2 mit LUKs (unter Verwendung des Modulparameters bei der Grub2-Installation).
- Mein Laptop hat kein U-EFI, es ist nur BIOS
- Meine Festplatte ist größer als 2 TiB (MBR erlaubt nur die Nutzung von bis zu 2 TiB, der Rest geht verloren)
Um auf das Problem mit DiskCryptor zurückzukommen: Wenn ich die gebootete Windows GPT-Partition verschlüssele (wo sich der WINDOWS-Ordner befindet) und den Bootcode auf die andere virtuelle MBR-Festplatte setze (die sich in der VHD-Datei befindet), werde ich nach dem Booten nach einem Kennwort gefragt, aber es wird immer die Fehlermeldung „ungültiges Kennwort“ angezeigt.
Wenn ich aber die gebootete Windows-GPT-Partition (in der sich der WINDOWS-Ordner befindet) nicht verschlüssele und nur die Partition verschlüssele, in der sich BCD befindet (die innerhalb der virtuellen MBR-Festplatte, die sich in der VHD-Datei befindet), werde ich beim Booten nach dem Kennwort gefragt. Wenn das Kennwort richtig ist, bootet Windows einwandfrei (außer dass die virtuelle Festplattenpartition von BCD nicht automatisch gemountet wird, ich muss sie manuell mounten ... muss mal sehen, ob ich sie zum automatischen Mounten hinbekomme), aber Windows funktioniert einwandfrei.
Und wenn ich beide verschlüssele (mit demselben Kennwort), wird der Windows-BootMBR geladen, aber es wird auf einem grafischen Bildschirm mit blauem Hintergrund und weißem Text die Meldung angezeigt, dass winload.exe nicht gefunden werden kann.
Wenn ich nur den MBR-Teil verschlüssele, kann die automatische Bereitstellung daran liegen, dass die VHD-Datei nicht früh genug verbunden wird. Vielleicht kann das Zwischenspeichern des Kennworts und das Ausführen von DisckCryptor bei der Anmeldung das Problem lösen, da die VHD-Verbindung in einem Aufgabenplan vor der Anmeldung erfolgt. Das muss ich testen, wenn ich Zeit habe.
Scheint so, als ob DiskCryptor die Option „System reserviert“ oder wie auch immer Sie es nennen möchten (wo sich der NT60-Bootcode und BCD-Zeug befindet) auf einer anderen Festplatte nicht unterstützt, zumindest nicht, wenn sich Windows 32 Bit auf einer GPT-Partition befindet (wo sich der WINDOWS-Ordner befindet) … denn die Verschlüsselung des virtuellen MBR funktioniert gut, aber die Verschlüsselung der GPT-Partition verursacht andere Arten von Fehlern!
Ich werde noch viele weitere Optionen erneut ausprobieren, beispielsweise das Erstellen eines ISO und das Booten damit usw.
Danke, ich habe mehrere Windows, habe mit einem anderen gebootet, DiskCryptor installiert, neugestartet und versucht, das GPT-Windows zu mounten, es wird problemlos gemountet, also habe ich es entschlüsselt und das große Problem behoben, dass ich das andere nicht booten konnte. Bis ich eine Lösung finde, werde ich weitere Tests auf einer VirtualBOX-Maschine durchführen, bevor ich wieder mit meinem Laptop loslege... ich wünschte, DiskCryptor hätte mich gewarnt, bevor ich es gemacht habe... aber zumindest weiß ich, was ich tue, und ich weiß, dass ich beim Booten von den anderen Windows-Versionen entschlüsseln kann, außerdem habe ich Clone BackUp usw.
Vielleicht übersehe ich etwas! Vielleicht verstehe ich nicht ganz, wie man bootet oder wo man den DiskCryptor-Bootloader platziert, wie man ihn konfiguriert usw.
Bedenken Sie bitte, dass ich mehr als 4 verschiedene Windows Home 32 Bits auf derselben GPT-Festplatte haben möchte, ich möchte sie 100 % isoliert haben, einschließlich Bootcodes, BCD und solchem Zeug … da gibt es keine andere Option … GPT ist zwingend erforderlich … ich möchte sie außerdem mit unterschiedlichen Passwörtern verschlüsselt haben, nicht nur das System (wo sich der Windows-Ordner befindet), sondern auch die Bootpartition (wo sich BCD befindet). Die Verschlüsselung mit Grub2 ist für mich einfach, also verwende ich es, um die Sache nicht zu kompliziert zu machen, unverschlüsselt, bis ich eine funktionierende Lösung gefunden habe.
Ich dachte, dass es viel schwieriger wäre, die Boot-Partition (wo sich BCD befindet) zu schützen, als das System selbst (wo sich der WINDOWS-Ordner befindet), aber ich habe genau das Gegenteil festgestellt.
Ich muss testen, testen und testen ... vielleicht habe ich einen Weg gefunden.
Ja, falls jemand daran denkt, ich habe TrueCrypt und VeraCrypt ausprobiert, beide haben größere Probleme, TrueCrypt erlaubt keine GPT-Systemverschlüsselung und VeraCrypt geht davon aus, dass GPT-Festplatten nur für U-EFI sind, also schlägt der Versuch fehl, U-EFI-Sachen zu sichern, egal ob ich eine EFI-Partition einlege, da die Maschine keine EFI-Variablen hat (nur BIOS, kein U-EFI), schlägt es fehl.
Der Bootvorgang (ohne Verschlüsselung) erfolgt folgendermaßen: Einschalten, BIOS ausführen, BIOS den ersten Sektor der Festplatte lesen, einen Grub2-Bootloadercode suchen, ihn ausführen, RAW GrubBIOS (core.img) lesen und ausführen, Grub2 erledigt seine Arbeit (liest die Datei grub.cfg) und zeigt das Menü an, ich wähle das System aus, das ich booten möchte, Grub2 lädt dann Memdisk und legt das entsprechende VHD-Image in die virtuelle Festplatte und springe dorthin, der Code auf dem MBR davon wird ausgeführt (NT60-Code), dann wird Bootmgr geladen und ausgeführt, dann Winload.exe usw. … normaler Windows-Boot … dann wird meine geplante Aufgabe auf dem SYSTEM-Konto gestartet, dieselbe VHD wird verbunden, jetzt kann auf den BCD zugegriffen werden, die Anmeldeaufforderung erscheint, ich wähle den Benutzer usw. … normales Windows wird fortgesetzt … der Desktop wird angezeigt.
Der gesamte Bootvorgang wird von derselben Festplatte durchgeführt, im GPT-Stil. Der Trick besteht darin, dass ich vor dem Booten von Windows eine virtuelle MBR-Festplatte mounte (mit Grub2 + Memdisk + VHD-Datei), auf der sich der NT60-Bootcode und BCD befinden. Auf diese Weise bootet Windows tatsächlich von einer ihm bekannten MBR-Festplatte, aber es ist eine virtuelle Festplatte, die in einer Datei gespeichert ist, die in einer GPT-Partition gespeichert ist. Der andere gute Trick ist Grub2 zu verdanken, das das Booten von einer GPT-Festplatte auf einem PC mit nur BIOS ermöglicht.
Ich hoffe, jemand kann meinen Startvorgang reproduzieren und DiskCryptor testen. Ich hoffe auch, dass VeraCrypt eines Tages nicht mehr davon ausgeht, dass GPT = U-EFI ist.
Zum Erstellen der VHD habe ich DiskPart von Windows verwendet. Sie kann auch erstellt, gemountet, aufgerufen usw. werden, nachdem Sie vom Windows-Installationsmedium gebootet haben und zu einer Konsole gegangen sind (Umschalt+F10 nach der Sprachauswahl) und DiskPart verwendet haben.
Danke, DiskCryptor, ich bin meinem Ziel ein Stück näher gekommen, aber noch nicht da. Nur noch ein kleiner Schritt ... Windows starten!
Der nächste Teil besteht darin, DiskCryptor von einer SystemRescueCD (einer Linux Live-Distribution) zu mounten, aber das wird eine wirklich schwierige Geschichte, wenn es möglich ist.