none
Permanenter BSOD 0x7B auf Win7 nach Windows Update RRS feed

  • Frage

  • Auf meinem Medion S5612-Notebook habe ich Win7HP 32bit installiert.

    Nach dem Windows-Update-Versuch der Patches 3069762, 3075851, 2952664 (alle fehl) trat beim Restart sofort der BSOD 0x7B auf.

    Als Fehlerursachen erhielt ich: "Ein Patch verhindert den Systemstart" und "Das Systemvolume ist beschädigt".

    Alle Reparaturversuche scheiterten (Last Known Good, Computerstartreparatur von der Setup-DVD, sfc /scannow und chkdsk /f über die Kommandozeile).

    Den Windowsdebugger zur Analyse des BSOD kann ich nicht einsetzen, weil kein MEMORY.DMP und kein Minidump-Ordner auf Win7 geschrieben werden, obwohl ich in der Registry AlwaysKeepMemoryDump = 1 gesetzt hatte. 

    Gibt es eine Möglichkeit vom Nachbar-OS Win8.1 aus auf die Registry von Win7 zuzugreifen, um die AlwaysKeepMemoryDump-Einstellung zu überprüfen?


    • Bearbeitet czer27 Donnerstag, 6. August 2015 15:18 Fehler
    Donnerstag, 6. August 2015 15:17

Alle Antworten

  • > Gibt es eine Möglichkeit vom Nachbar-OS Win8.1 aus auf die Registry von
    > Win7 zuzugreifen, um die AlwaysKeepMemoryDump-Einstellung zu überprüfen?
     
    Das geht von der Boot-DVD aus - Shift-F10 öffnet eine Commandline, hier
    kannst Du regedit starten und die Struktur
    C:\Windows\System32\Config\system laden. Das ist der HKLM\System-Hive.
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Donnerstag, 6. August 2015 16:38
  • Hallo Martin Binder,

    vielen Dank für Deinen Hinweis. Der Anfang funktioniert, der Rest leider nicht!

    Im Einzelnen:

    1. Mit ShiftF10/X:\Sources>regedit komme ich in eine Registry (wohl die von WinPE?).

    2. Unter HKLM\System\CCS\Ctrl\CrashControl stehen dort nur 4 Eintragungen:

        - AutoReboot = 0

        - CrashDumpEnabled = 0

        - DumpFilters = dumpfve.sys

        - Overwrite = 1

    3. Unter Datei ist Importieren/Exportieren möglich aber nicht zielführend, Struktur laden/Struktur

        entfernen ist ausgegraut. Damit komme ich nicht an den HKLM\System-Hive von Win7 ran, eine

        Kontrolle oder gar Reparatur ist nicht möglich.

    4. Eine Änderung in den vorhandenen Eintragungen unter CrashControl ist zwar möglich, wird aber immer

        verworfen, sobald man die Setup-DVD verlässt. Auch eine Änderung der Berechtigungen innerhalb von

        Regedit auf z.B. Vollzugriff für Benutzer ändert daran nichts.

    5. Die Folge davon: Es wird kein MEMORY.DMP und kein Minidump geschrieben. In der BSOD-Anzeige ist

        mit ***STOP: 0x0000007B (0x80786B58....)

        Schluss!

    Fragen: Warum ist Regedit unter WinPE so eine Krücke? Kann man von dem Nachbar-OS Win8.1 aus auf die Registry von Win7 zugreifen? Gibt es noch eine andere Möglichkeit, das gecrashte Win7 zu einem MEMORY.DMP zu überreden?

       

    Freitag, 7. August 2015 13:19
  • > 1. Mit ShiftF10/X:\Sources>regedit komme ich in eine Registry (wohl die
    > von WinPE?).
     
    Ja. Und da markierst Du im Baum erst mal HKLM, dann im Menü auf Datei -
    Struktur laden... Das geht nur , wenn entweder HKLM oder HKU ausgewählt
    ist :)
     
    > Fragen: Warum ist Regedit unter WinPE so eine Krücke? Kann man von dem
     
    Ist es nicht - es ist das gleiche Regedit wie im "vollständigen" OS.
     
    > Nachbar-OS Win8.1 aus auf die Registry von Win7 zugreifen?
     
    Ja - mit der gleichen Methode "Struktur laden".
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Freitag, 7. August 2015 13:55
  • Hallo Martin,

    danke für die schnelle Antwort. Ich habe sie gleich ausprobiert und bin ein Stück weiter gekommen, aber nicht bis zum Ende.

    Ich habe die Struktur aus Windows 7 C:\Windows\System32\config\system geladen.

    Unter dieser Struktur erscheinen aber nur ControlSet 001 und ControlSet 002.

    Der Pfad System\CurrentControlSet\Control\CrashControl ist nicht möglich.

    Mache ich etwas falsch oder ist das so?

    Die Probe, von Win8.1 aus die Win7-Struktur laden, ergab dasselbe Ergebnis.

    czer27

    Freitag, 7. August 2015 17:15
  • > Unter dieser Struktur erscheinen aber nur ControlSet 001 und ControlSet 002.
    > Der Pfad System\CurrentControlSet\Control\CrashControl ist nicht möglich.
     
    Ob 001 oder 002 aktiv ist, steht in HKLM\System\Select: "Current" :)
     
    Notfalls ändere es in beiden.
     

    Greetings/Grüße, Martin

    Mal ein gutes Buch über GPOs lesen?
    Good or bad GPOs? - my blog…
    And if IT bothers me - coke bottle design refreshment (-:
    Montag, 10. August 2015 14:14
  • Ich habe den Inhalt der ControlSets mit denen auf einem anderen Win7 verglichen und festgestellt, dass sehr viel fehlte.

    Daraufhin habe ich den System-Zweig eines Win7Pro kopiert und damit den fehlerhaften System-Zweig des gecrashten Win7HP überschrieben.

    Nun ist dessen Inhalt in Ordnung mit 9 Einträgen unter CrashControl.

    Ich dachte, nun würde ein MEMORY.DMP geschrieben, aber es wurde nichts geschrieben.

    Die nötigen Einstellungen unter Systemsteuerung/System sind aber in Ordnung.

    Als Nächstes habe ich versucht zu testen, ob von dem Nachbar-OS, das ich inzwischen auf Win10 upgegradet habe, ein MEMORY.DMP geschrieben wird. Dazu habe ich in der Registry CrashOnCtrlScroll = 1 eingefügt. Die Tastenkombination re.STRG-Taste halten und 2x Scroll-Taste klicken bewirkt aber nichts. Das Medion Akoya S5612 hat eine kombinierte Num/Rollen-Taste. Offenbar hat die nicht den notwendigen Tastencode. Die andere Variante von MS, einen frei wählbaren Tastencode festzulegen und unter CrashControl einzutragen (mit DumpKeys 1 und DumpKey 2) ist diffizil wegen der Tastenzuordnung von DumpKey 2. Zahlreiche Versuche damit haben aber auch zu keinem Manually initiated BSOD geführt.

    Das Tool BANG! von OSR Online funktioniert nur bis Windows Vista, ist also unbrauchbar. 

    Ich weiß also bisher nicht, ob auf dem Medion-Notebook, egal unter welchem Betriebssystem, überhaupt ein MEMORY.DMP oder Minidump geschrieben wird.

    Die Auswertung eines MEMORY.DMP ist meiner Meinung nach der schnellste Weg, dem Fehler auf die Spur zu kommen. Alles andere ist Stochern im Nebel. Deswegen bin ich bisher keiner anderen Spur gefolgt.

    Dienstag, 11. August 2015 10:10
  • Hallo nochmal,

    ich habe den Fehler gefunden (nach der Methode des scharfen Ansehens)!

    Unter \Windows\system32\drivers stehen auch die SATA AHCI Treiber, bei mir handelte es sich um die Datei iaStorA.sys.

    Mein Windows 7 Pro ist eine 32bit-Installation, der Treiber aber ist ein 64bit-Treiber. Das löste den permanenten BSOD 0x7B Inaccessible boot device aus.

    Der Fehler wurde vom Treiber-Updater Driver Toolkit verursacht, der hat den 32bit-Satz und den 64bit-Satz an Treiberdateien an Bord, hat aber fälschlicherweise den 64bit-Satz installiert.

    Die Fehlersuche hat mich viel Zeit gekostet. Glücklicherweise hatte ich einen gängigen Wiederherstellungspunkt zur Verfügung, der von dem Fehler nicht betroffen war und Windows 7 wieder lauffähig machte. 

    Leider funktioniert das Schreiben eines MEMORY.DMP bei mir nicht, sonst hätte ich den Fehler schneller gefunden.

    czer27

    • Als Antwort vorgeschlagen David das Neves Donnerstag, 20. August 2015 18:52
    Donnerstag, 20. August 2015 17:35