Inaccessible Boot Device nach einspielen von Backup
Inaccessible Boot Device nach einspielen von Backup
Ich bekomme nach einspielen meines C: Backups immer einen Inaccessible Boot Device beim starten. Danach geht er in die automatische Reparatur mit installiertem WinRE System.
Darauf habe ich ein neues zweites Windows auf Partition D: installiert und kann jetzt zw. beiden Systemen im Bootloader wechseln. Mein(e) System(e): Version 10.0 (Build 19041) mit UEFI und GPT NVMe
Hier der bcdedit aus der Sicht, wenn das neu installierte Windows gestartet wurde:
Das alte Windows bootet/lädt nur ganz kurz (Gehäuse HDD-Led flackert nur ca. 1 Sekunde, dann ca. 30 Sek. aus bis IBD BlueScreen). Es wird auch, obwohl aktiviert, kein NTBTLOG.txt geschrieben. Also kann da nicht viel von der alten Windowspartition geladen werden.
Ich habe mir mal die letzten Zugriffe der Dateien angeschaut um zu sehen was überhaupt alles geladen wird (zuvor habe ich das C: Backup nochmal eingespielt um wirklich den letzten Stand vor dem "Crash" zu haben). Hier ein paar Screenshots, vom neuen Windows aus gemacht:
Ich habe das alte Windows (LW D:) versucht heute um 3.17 Uhr zu starten mit IBD BS:
download/file.php?mode=view&id=18505
download/file.php?mode=view&id=18503
Dann habe ich das neue Windows (LW C:) heute um 3.31 Uhr gestartet:
download/file.php?mode=view&id=18504
download/file.php?mode=view&id=18502
Da ich ja ein UEFI System mit GPT habe sollte doch eigentlich die winload.efi und nicht die winload.exe geladen werden!?
Hier noch ein Screenshot von meinem Backup (als H: gemountet)
download/file.php?mode=view&id=18501
Am 28.12 habe ich das System das letzte mal gestartet und danach das Backup gemacht, was bis zum nächsten Tag lief, da wurde die winload.efi geladen...
Wie ist das bei euch? Habt ihr bei euch auf der winload.efi auch keinen Zugriff (zeitnahen letzten Zugriff) beim Windows start?
Darauf habe ich ein neues zweites Windows auf Partition D: installiert und kann jetzt zw. beiden Systemen im Bootloader wechseln. Mein(e) System(e): Version 10.0 (Build 19041) mit UEFI und GPT NVMe
Hier der bcdedit aus der Sicht, wenn das neu installierte Windows gestartet wurde:
Code: Alles auswählen
Windows-Start-Manager
---------------------
Bezeichner {bootmgr}
device partition=\Device\HarddiskVolume1
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale de-DE
inherit {globalsettings}
default {current}
resumeobject {ca0a9357-a951-11ee-9732-a9d285c81a72}
displayorder {current}
{f2c084d9-a808-11ee-a0d7-f728f6cda9c7}
toolsdisplayorder {memdiag}
timeout 30
Windows-Startladeprogramm
-------------------------
Bezeichner {current}
device partition=C:
path \Windows\system32\winload.efi
description Windows 10 new
locale de-DE
inherit {bootloadersettings}
recoverysequence {ca0a9359-a951-11ee-9732-a9d285c81a72}
displaymessageoverride Recovery
recoveryenabled Yes
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \Windows
resumeobject {ca0a9357-a951-11ee-9732-a9d285c81a72}
nx OptIn
bootmenupolicy Standard
Windows-Startladeprogramm
-------------------------
Bezeichner {f2c084d9-a808-11ee-a0d7-f728f6cda9c7}
device partition=D:
path \Windows\system32\winload.efi
description Windows 10
locale de-DE
inherit {bootloadersettings}
recoverysequence {f2c084da-a808-11ee-a0d7-f728f6cda9c7}
displaymessageoverride Recovery
recoveryenabled Yes
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=D:
systemroot \Windows
resumeobject {f2c084d8-a808-11ee-a0d7-f728f6cda9c7}
nx OptIn
bootmenupolicy Standard
bootlog Yes
Ich habe mir mal die letzten Zugriffe der Dateien angeschaut um zu sehen was überhaupt alles geladen wird (zuvor habe ich das C: Backup nochmal eingespielt um wirklich den letzten Stand vor dem "Crash" zu haben). Hier ein paar Screenshots, vom neuen Windows aus gemacht:
Ich habe das alte Windows (LW D:) versucht heute um 3.17 Uhr zu starten mit IBD BS:
download/file.php?mode=view&id=18505
download/file.php?mode=view&id=18503
Dann habe ich das neue Windows (LW C:) heute um 3.31 Uhr gestartet:
download/file.php?mode=view&id=18504
download/file.php?mode=view&id=18502
Da ich ja ein UEFI System mit GPT habe sollte doch eigentlich die winload.efi und nicht die winload.exe geladen werden!?
Hier noch ein Screenshot von meinem Backup (als H: gemountet)
download/file.php?mode=view&id=18501
Am 28.12 habe ich das System das letzte mal gestartet und danach das Backup gemacht, was bis zum nächsten Tag lief, da wurde die winload.efi geladen...
Wie ist das bei euch? Habt ihr bei euch auf der winload.efi auch keinen Zugriff (zeitnahen letzten Zugriff) beim Windows start?
-
Tante Google
- DK2000
- Legende
- Beiträge: 9272
- Registriert: 03.04.2018, 00:07
- Hat sich bedankt: 161 Mal
- Danke erhalten: 499 Mal
- Gender:
Re: Inaccessible Boot Device nach einspielen von Backup
Das mit dem Datum sagt nichts aus, sieht bei mir so aus:
Ist das Datum, wo die Dateien das letzte Mal aktualisiert wurden. Der Zugriff beim Booten wird nicht gespeichert, weil der NTFS-Treiber an der Stelle noch nicht läuft. Und der rudimentäre NTFS-Zugriff vom Bootmanager schreibt da nichts. Die winload.efi wird aber definitiv ausgeführt, da ansonsten das Windows nicht gestartet wird.
Deaktiviere mal für das 2. Windows das Recovery. Eventuell steht da dann noch etwas und es kommt nicht gleich der BSOD.
So wirklich was Richtiges fällt mir da auch nicht mehr ein.
Ist das Datum, wo die Dateien das letzte Mal aktualisiert wurden. Der Zugriff beim Booten wird nicht gespeichert, weil der NTFS-Treiber an der Stelle noch nicht läuft. Und der rudimentäre NTFS-Zugriff vom Bootmanager schreibt da nichts. Die winload.efi wird aber definitiv ausgeführt, da ansonsten das Windows nicht gestartet wird.
Deaktiviere mal für das 2. Windows das Recovery. Eventuell steht da dann noch etwas und es kommt nicht gleich der BSOD.
So wirklich was Richtiges fällt mir da auch nicht mehr ein.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Re: Inaccessible Boot Device nach einspielen von Backup
Schade, das ist natürlich schlecht das noch kein Zugriff gesetzt wird... Dann müssten sie aber kurz danach gesetzt werden, da könnte ich ja gucken wo er da sonst noch Zugriffe setzt. Vor dem ausführen des Kernels wären die alle im System32 Ordner?
Und wo speichert W10 einen Fehlstart? Sprich woher weis die WinRE das sie anstelle des Systems booten soll?
Und wo speichert W10 einen Fehlstart? Sprich woher weis die WinRE das sie anstelle des Systems booten soll?