none
BSOD 0x7B nach Microsoft Updates auf HP ProLiant ML350 G6 RRS feed

  • Frage

  • Hilfe!

    wir haben eine hartknäckigen BSOD 0x7B nach den letzten MS Updates und dem nachfolgenden Reboot.

    Das System fährt weder hoch, noch lässt sich der direkte Verursacher ermitteln.

    Prüfung HDDs, Prüfung Registry, Boot & MBR alles OK, keine Fehler. Ein Zugriff auf das System per MS DART ist problemlos möglich.

    Eine Crash Dump gibt es nicht und auch keinerlei Fehler im Event-Log (OK war ja auch erst nach dem Neustart aufgetreten)

    Der HP Support schließt ein HW Problem aus, obwohl ich schon gelesen habe, dass es evtl. Probleme mit dem HP SAS SmartController - Treiber und/oder Firmware gegeben haben könnte (andere berichteten).

    HP Support geht von einem MS Update Problem aus.

    Wer kann helfen?

    Was können wir noch tun?

    Danke und LG an alle


    Danke und liebe Grüße Oliver Richter

    Donnerstag, 18. Februar 2016 19:46

Antworten

  • Hi,

    Problem wurde mit BMR des Systems gelöst und zwar mit dem Sicherungsstand vom 31.12.2015. Änderungen in der AD haben wir dann mit Granluar Restore der Mitte Januar veränderten Elemente (ist ja bei ca. 40 APC noch überschaubar) hinbekommen. Alles läuft jetzt seit gut 24 Stunden ohne Mängel.

    Beunruhigend ist und bleibt, was hier vermutlich irgendwo im Januar passiert sein sollte. Aus zeitlichen Gründen habe ich nun nicht jeden einzelnen Sicherungstag restored. Zumindest am 15.01.16 kam noch der BSOD 0x7B

    Ich bin heil froh hier wirklich eine Sicherung gehabt zu haben, die auch mal ein paar Wochen und Monate zurück liegt. Trotzdem sitzt einem bei so einer Aktion unwahrscheinlich die Zeit im Nacken. Wäre diese nicht, hätte man sich wohl genau an den Tag des Erstauftretens des Problems heranarbeiten können.

    Daher mal wieder (und nicht nur wegen Locky) - Leute macht ordentliche Dasi und haltet die auch langfristig vor!


    Danke und liebe Grüße Oliver Richter

    Sonntag, 21. Februar 2016 10:30

Alle Antworten

  • Am 18.02.2016 schrieb Oliver Richter:

    wir haben eine hartknäckigen BSOD 0x7B nach den letzten MS Updates und dem nachfolgenden Reboot.

    Das System fährt weder hoch, noch lässt sich der direkte Verursacher ermitteln.

    Überprüf im BIOS ob IDE oder AHCI eingestellt ist. Wenn IDE, stell
    doch mal um auf AHCI und starte neu, geht es jetzt?

    Servus
    Winfried


    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Donnerstag, 18. Februar 2016 20:10
  • Danke @Winfried

    Werde ich gleich tun. Zumindest hat sich im Verzeichnis c:\win...\drivers\ seit 11/2015 nichts an den Treibern verändert. (Ich hatte was gelesen, wo mal 32 Bit Treiber in eine 64 Bit Umgebung upgedatet worden)

    Melde mich gleich wieder...

    P.S. An IDE ist eigentlich nur das CDROM angeschlossen. Der Rest hängt am HP SmartArray Kontroller


    Danke und liebe Grüße Oliver Richter


    Donnerstag, 18. Februar 2016 20:16
  • Mit IDE auf AHCI geht nicht, daher habe ich einfach alle IDE Geräte abgeschalten.

    Keine Besserung.

    Auffällig bei den letzten Updates ist, dass sehr viele Systemdateien erneuert wurden (ntdll.dll, ntkernel.dll usw.) das bereitet mir Bauchschmerzen ....

    Jemand noch eine gute Idee?

    Danke


    Danke und liebe Grüße Oliver Richter

    Donnerstag, 18. Februar 2016 21:59
  • Hi,

    doofer Fehler, bei 0x7B wird kein Crashdump geschrieben.

    Wie sieht es mit der Last Known Good Configuration aus? Bootet die noch?
    Ansonsten sind hier vom Core Team einige Troubleshooting Steps beschrieben, die du auf jeden Fall ausprobieren solltest:
    https://blogs.technet.microsoft.com/askcore/2013/08/05/troubleshooting-a-stop-0x7b-in-windows/

    Freitag, 19. Februar 2016 15:24
  • Moin Oliver, 

    ich vermute mal du hast beim Update die Treiber für Hardware nicht mit ausgeschaltet und dir damit einen Synthetischen Treiber für den RAID Controller eingefangen. Da es sich hier um einen Software RAID Controller handelt, hat der sich bei Update die nicht von HP sind immer etwas zickig. Ich kenn das Problem auch bei Dell PERC Sxxx oder CERC Controllern. 

    Probier mal das unter folgendem Link. Eventuell hilft dir das weiter. 

    https://neosmart.net/wiki/0x0000007b/#Fix_0x0000007B_in_Windows_8_or_81

    Insert your Windows 8/8.1 installation disk
    If you don’t have the installation disk, follow the next set of instructions below.

    Restart your PC and press any key to boot from the disk
    Click Repair your computer
    Select Troubleshoot, then Advanced Options and then Command Prompt
    Type this command and hit Enter:
    chkdsk /f /r

    --------------

    Rebuild BCD

    To rebuild the BCD of a Windows 8 or 8.1, follow these steps:

    Boot from your Windows 8/8.1 disc
    If you don’t have the installation disc, follow the next set of instructions below.

    Click Repair your computer, then Troubleshoot, then Advanced Options and then Command Prompt
    Type these commands and press Enter after each:
    bootrec /fixmbr
    bootrec /fixboot
    bootrec /scanos
    bootrec /rebuildbcd
    Type exit, hit Enter and remove the disk from the disk tray

    --------------

    Repair EFI bootloader

    Windows 8/8.1 features a EFI bootloader that you repair if the commands from Rebuild the BCD don’t work.

    To do so, follow these steps:

    Restart your computer and boot from the Windows 8/8.1 DVD/USB
    Click Repair your computer, then Troubleshoot, and then Command Prompt
    Type these commands and press Enter after each:
    diskpart
    sel disk 0
    list vol
    Check the “Fs” column and find the item that has “FAT32” at this “Fs” column. The EFI partition is formatted under FAT32.
    If, for example, the number for the EFI item is “1”, type this command:
    sel vol 1
    Now you need to assign a letter to the partition, a unique letter that isn’t already available on your computer (for example, y:\):
    assign letter=y:
    When this message appears – DiskPart successfully assigned the drive letter or mount point – type exit to quit the utility software
    exit
    Type this command, but replace y:\ with the letter of your choice:
    cd /d y:\EFI\Microsoft\Boot\
    Type this command:
    bootrec /fixboot
    Type this command to backup the old BCD:
    ren BCD BCD.backup
    Type this command to recreate the BCD. Remember to replace y:\, if needed:
    bcdboot c:\Windows /l en-us /s y: /f ALL
    Type exit, hit Enter and remove the disk from your disk tray
    Restart the PC


    Kind regards, Flo

    Freitag, 19. Februar 2016 17:13
  • Vielen Dank @Florian

    Die Sache mit dem Controller war mir von Anfang einer der Hauptverdächtigen. STOP 0x7B wäre für zumindest primär ein Fehler beim Zugriff auf das Startvolume und daher Kontroller. Der auf dem HP Proliant ML350 G6 installierte Treiber war vom quasi Originalstand 04/2009 - hier gibt es seitens HP neue "recommended" Treiber von 2013 ... aber erstmal egal.

    Bei der Prüfung mit MS DART auf dem System habe ich daher auch die Treiber für den Kontroller geprüft. Offensichtlich alles vorhanden und auch vom "alten" Stand (wie oben genannt).

    Mit MS DART haben wir auch die Platten die Bootbereiche usw. usw. geprüft - alles OK - alles unauffällig.

    Dann wurden die System Registries vom Vortag rückgesichert -> ohne Erfolg.

    Nebenbei gesagt hatten wir auch den (osteuropäischen) MS Support per Emergency Call mit in Boot geholt. Auch dieser hat div. Prüfungen und Tests ausgeführt. Auf dessen Anraten haben wir die Dateien im System32 zurückgesichert (von der Sicherung über Nacht zuvor) -> ohne Besserung.

    Obiges war dann unsere Aufgabe von gestern. Gegen Nachmittag gingen war dann auch der MS Support am Ende seiner Ideen und sprach von Neuinstallation oder Vollrücksicherung.

    Ein BMR hätte ich gern von Anfang an durchgezogen, doch die vorher das Unternehmen betreuende IT Firma hatte dem Unternehmen eine NAS verkauft, die in der Rücksicherung übers LAN auf Geschwindigkeiten von gemittelt um die 12 MB/sek. kommt. Was bei ca. 650 GB rücksicherbaren Daten auf eine Dauer von ca. 15 Stunden hinausläuft (Trotz verschiedener Einstellversuche, neuer Firmware usw. keine Besserung in Sicht. Wer verkauft eigentlich so einen Schrott an Unternehmen???). Da wir aber nicht wissen, ob der Fehler nicht auch schon am Vortag (verdeckt) vorlag, hätte es passieren können, dass nach den 15 Stunden wieder der BSOD 0x7B erscheint. Sich dann von Tag zu Tag an den Punkt des Funktionierens zurück zuarbeiten wäre aus meiner Sicht bei dem Zeitaufwand absolut unrealistisch und auch genauso zeitvergeudend. Hinzu kommt, dass die NAS vermutlich weil sie so alt ist, dass der Zugriff auf die NAS per WinPE (für BMR notwendig) gar nicht möglich war. Ich tippe mal auf ein Problem mit dem SMB Signing o.ä. So haben wir erstmal den Sicherungsbestand von der NAS (gesamt über 1 TB) auf eine HDD überspielt um hier vor allem Speed zu haben, um evtl. verschiedene Sicherungsstände mal testen zu können.

    Anhand des Aufwandes und des Zeitfensters sieht man mal wieder, dass sich der Anwender - trotz unserer früheren Empfehlung und Drängen - keine Gedanken gemacht hat, mal eine BMR oder Rücksicherung an sich zu testen. Das wurde bisher nie (!!!) ausgeführt. Da hätte man die Probleme mit der NAS schon viel viel eher erkennen und ändern können.

    Zumindest läuft jetzt der erste Test in der BMR - mal sehen, ob der klappt. BMR mache ich erst mal in einer VM um zu sehen, ob der Stand überhaupt funktioniert.


    Danke und liebe Grüße Oliver Richter

    Samstag, 20. Februar 2016 07:06
  • Hi,

    wie befürchtet, die DASI Stände der letzten zwei Tage haben ebenfalls schon den Fehler BSOD 0x7B.

    Der DASI Stand vom 31.12.15 hingegen "noch" nicht. Bin jetzt am Stand Anfang Februar 2016 dran, wenn der klappt nehmen wir den oder evtl. arbeite ich mich noch mal Tag für Tag näher an den Fehlerverursacher ran ;-)


    Danke und liebe Grüße Oliver Richter

    Samstag, 20. Februar 2016 08:42
  • Hi,

    Problem wurde mit BMR des Systems gelöst und zwar mit dem Sicherungsstand vom 31.12.2015. Änderungen in der AD haben wir dann mit Granluar Restore der Mitte Januar veränderten Elemente (ist ja bei ca. 40 APC noch überschaubar) hinbekommen. Alles läuft jetzt seit gut 24 Stunden ohne Mängel.

    Beunruhigend ist und bleibt, was hier vermutlich irgendwo im Januar passiert sein sollte. Aus zeitlichen Gründen habe ich nun nicht jeden einzelnen Sicherungstag restored. Zumindest am 15.01.16 kam noch der BSOD 0x7B

    Ich bin heil froh hier wirklich eine Sicherung gehabt zu haben, die auch mal ein paar Wochen und Monate zurück liegt. Trotzdem sitzt einem bei so einer Aktion unwahrscheinlich die Zeit im Nacken. Wäre diese nicht, hätte man sich wohl genau an den Tag des Erstauftretens des Problems heranarbeiten können.

    Daher mal wieder (und nicht nur wegen Locky) - Leute macht ordentliche Dasi und haltet die auch langfristig vor!


    Danke und liebe Grüße Oliver Richter

    Sonntag, 21. Februar 2016 10:30
  • Nimm mal noch die Update von Treibern etc. aus den automatischen Windows Updates. Dann sollte es nicht mehr passieren :) 

    Kind regards, Flo

    Sonntag, 21. Februar 2016 16:00
  • Danke @Flo

    das war schon raus. Zumindest hoffe ich, wir meinen beide das gleiche (siehe Bild):

    Zum anderen zieht der Server sich Updates (nur) über den WSUS und der WSUS ist auch extra nochmals auf "keine Treiberupdates laden" eingestellt. Ganz klar sähe ich den BSOD 0x7B auch in einer Treibersache, aber selbst im Vergleich der Verzeichnisse C:\windows\system32\drivers\ vom "defekten" Stand mit dem Stand vom 31.12.15 (funktionierend) sehe ich keinerlei Änderungen/Unterschiede in den Treiberdateien. Wo sollte sich dann ein neuer Treiber noch versteckt haben? (OK ich habe nur die Änderungsdaten der Dateien vergleichen, nicht den Inhalt bzw. deren Größe - denkbar wäre schon, dass sich hier etwas eingeschmuggelt hat.)


    Danke und liebe Grüße Oliver Richter

    Montag, 22. Februar 2016 09:41