Bei einem Testlauf eines Skript auf einem Windows 7 Professional 64-bit-Computer, das 22 neue Datensicherungen aus vorhandenen Voll- und Differenz-Sicherungen erstellen sollte (merge), kam es unerwartet zu Problemen. Seltsam war zunächst, das es bis vor ein paar Tagen noch klappte.

Der Fehler trat allerdings nicht immer an der gleichen Stelle oder mit den gleichen Sicherungen auf. Mal liefen zig Sicherungen durch, mal ging gar nichts mehr. Das Problem besteht darin, das die versteckte RAMDISK nicht mehr erstellt werden kann:

Beim gemeinsamen Testen mit Hr. Pawletta von Tom Ehlert Software fiel dann weiter auf, das auch das Mounten von Images zwar zuerst klappte, aber kurze Zeit später kein Inhalt der eingehängten Datensicherung mehr zu sehen war. Ein Backup von der eingehängten Sicherung war ebenfalls nicht möglich. Immer erst nach einem Neustart konnte wieder wie gewohnt vorgegangen werden.

Während des Telefonats dämmerte mir dann, das die letzte Änderung an dem System das Update auf VirtualBox 5.2.24 war. Vor dem Update lief das Ganze bereits erfolgreich. Naheliegend, das es in dieser Kombi wohl nun zu Schwierigkeiten kommt. Mit PoolMonEx wurde nach dem nicht-ausgelagerten Kernel-Speicher geschaut, dabei Stach an oberster Stelle “xoBV” ins Auge. Danach im Netz gesucht stellt man fest, das dies wohl mit dem “VirtualBox Support Driver”, kurz “vboxdrv”, zu tun hat.

Jedenfalls wurde VirtualBox beendet und der Treiber mittels einer Eingabeaufforderung mit erhöhten Rechten auf den Starttyp “Manuell” gesetzt:

sc config vboxdrv start= demand

Dann der Computer neugestartet und anschließend wieder getestet, leider ohne Änderung. Also in Sachen VirtualBox wieder Rolle rückwärts. Damit es irgendwie weiter geht, wurde kurzerhand eine virtuelle Maschine mit WinPE erstellt, die lediglich zum Durchführen der Eingangs erwähnten Drive Snapshot-“Mergerei” dienen soll.

Das klappte soweit zunächst gut und das obwohl diese VM nur mit einer virtuellen CPU und 512 MB RAM versehen ist. Interessanterweise trat dort ebenfalls ein Fehler auf als von einer auf zwei virtuelle CPUs geändert wurde. Plötzlich konnte sporadisch der Drive Snapshot-Treiber nicht mehr geladen werden.

So recht erklären können wir es im Moment nicht. Möglich das es irgendwie an der Hardware oder einem Wechselspiel mit einem Treiber oder anderer Software liegt, wobei eigentlich fast nichts auf der Kiste drauf ist.

Für den Moment muss der Workaround mit der WinPE-VM als Drive Snapshot-System herhalten.

Kleiner Tipp zum Ende:

Führt man Drive Snapshot via Skript bzw. Aufgabe aus, unterbindet für gewöhnlich “-W” das es bei einem Fehler oder am Ende “hängen” bleibt. Mitunter reicht das alleine allerdings nicht, wie sich am Beispiel mit dem WinPE-Workaround gezeigt hat. Im Fehlerfall blieb Drive Snapshot in der VM mit einer grafischen Fehlermeldung, wie im obigen Screenshot zu sehen, stehen. Abhilfe schafft das zusätzlich Anhängen von “-Gx” damit in jedem Fall Drive Snapshot beendet wird, ganz gleich ob erfolgreich oder nicht, ob via Batch, Aufgabe oder Grafisch ausgeführt, unabhängig von der verwendeten Shell bzw. Session.

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.