BSOD - Windows 8.1 - CRITICAL_STRUCTURE_CORRUPTION

knubl2

Cadet 3rd Year
Registriert
Jan. 2008
Beiträge
33
Hallo,

bei meinem neugekauften Asus Notebook R751L stürzt Windows 8.1 immer nach einiger Zeit (manchmal schon nach 10 Minuten, mal nach 30 Minuten) mit dem immer gleichen Bluescreen ab:
:( Auf dem PC ist ein Problem aufgetreten. Er muss neu gestartet werden. Es werden einige Fehlerinformationen gesammelt, und dann wird ein Neustart ausgeführt. (100% abgeschlossen) Wenn Sie weitere Informationen wünschen, können Sie später online nach diesem Fehler suchen: CRITICAL_STRUCTURE_CORRUPTION

Mehr Infos stehen nicht drin. Darum habe ich die Minidumps mit angehängt.
Anhang anzeigen Minidump.zip

Während der stundenlangen Installation der ganzen Programme (Office, Bildbearbeitung, Browser, usw.) stürzte Windows kein einziges Mal ab.

Ich hoffe, ihr könnt mir helfen.
 
Der Fehler bedeutet dass eine Struktur im Kernelspeicher korrumpiert wurde.

Das kann eigentlich nur ein Treiber sein der im Kernelspeicher rumfummelt wo er nix zu suchen hat
oder der Arbeitspeicher ist defekt, bzw. zu hoch übertaktet.

Den Minidump kann ich mangels WInodws 8.1, bzw. den passenden Debugsymboldateien nicht vollständig analysieren. Vielleicht kann es jemand anderes. Ich sehe aber schon dass der Kern aufgrund eines Treiberfehlers gecrasht ist.

Wenn nicht nachvollziehbar ist nach welcher Software-/Treiberinstallation die Bluescreens anfangen würde ich mal den Support des Herstellers kontaktieren oder den Rechner mit Verdacht auf kaputten Arbeitsspeicher einschicken sofern er noch in der Garantiezeit ist.
 
Zuletzt bearbeitet:
Ein Treiberproblem ist aus den Dumps leider nicht rauszulesen:

SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
BUCKET_ID: BAD_STACK

Da es aber immer der gleiche Fehler ist, würde ich erst mal nicht von einem Hardwareproblem ausgehen.

Aktiviere den Treiber Verifier und lade die hiervon erzeugten Dumps erneut hoch.
http://support.microsoft.com/kb/244617
http://www.codeproject.com/Articles/31072/How-to-Use-Microsoft-s-Driver-Verifier-to-Interpre

Einmal gestartet, muss der Verifier manuell wieder deaktiviert werden (er läuft sonst auf ewig weiter). Dies kannst du -wenn der Verifier nicht mehr benötigt wird- in der Eingabeaufforderung mittels "verifier.exe /reset" vornehmen.

Mittels den von Verifier erzeugten bluescreens, wird hoffentlich der Problemtreiber zu erkennen sein.

Unabhängig davon fallen ein paar veraltete Treiber auf, die aktualisiert werden sollten:

- ASMMAP64.sys (von Juli 2009) -> Hotkey ATK0101 ACPI UTILITY
- azvusb.sys (von August 2009) -> AzureWave Technologies - Virtual USB Hub driver - pctv usb tv Card
- sptd.sys (von April 2010) -> DamonTools
- afcdp.sys (von Juli 2011) -> Acronis File Level CDP Kernel Helper
- AiCharger.sys (von Sept. 2011) -> Asus Tool
- truecrypt.sys (von Feb. 2012) -> TrueCrypt
 
Zuletzt bearbeitet:
Danke für die Hilfe, ich werde den Driver Verifier laufen lassen, und melde mich dann mit den Dumps zurück.
 
Bei CRITICAL_STRUCTURE_CORRUPTION hilft DriverVerifier leider nicht. Die dumps sind immer gleich und enthalten kaum neue Details.
 
Leider hat das Benutzen des Driver Verifiers dazu geführt, dass Windows 8.1 jetzt nicht mehr hochfährt. :(

Ich hatte die Standardeinstellung in der grafischen Benutzeroberfläche des Driver Verifiers gewählt, hatte alle auf dem Computer installierten Treiber automatisch auswählen lassen, auf Fertigstellen geklickt und dann den Rechner neugestartet.

Ein paar Sekunden nach dem Neustart erschien der Bluescreen mit DRIVER_VERIFIER_IOMANAGER_VIOLATION und danach folgte ein automatischer Neustart. Dann nochmal Bluescreen mit DRIVER_VERIFIER_IOMANAGER_VIOLATION und nach dem folgenden Neustart erschien dann die Nachricht: Automatische Reparatur wird vorbereitet.
Aber am Ende kam dann die Meldung: Der PC konnte nicht automatisch repariert werden. Klicken Sie auf „Erweiterte Optionen“, um weitere Reparaturoptionen für Ihren PC auszuprobieren, oder auf „Herunterfahren“, um den PC auszuschalten. Protokolldatei: C:\Windows\System32\Logfiles\Srt\SrtTrail.txt

Jetzt komme ich nicht weiter und brauche Hilfe.

In der Zwischenzeit lasse ich gerade Memtest86+ v5.01 laufen, um die 8 GB RAM zu testen.
War gar nicht so leicht, im Aptio UEFI des Asus ein anderes Bootmedium einzustellen, aber nachdem ich Boot Security auf disabled und CSM auf enabled gestellt hatte und den Rechner neugestartet hatte, kam ich mit F2 wieder ins UEFI und konnte dann in den Bootoptionen das DVD-Laufwerk als erstes Startlaufwerk auswählen. Allerdings lief Memtest86+ v4.20 nicht auf diesem System - nur ein Teil der Anzeigen erschien und der RAM-Test startete nicht. Aber zwischenzeitlich ist ja auf ComputerBase eine neue Version zum Download verfügbar gewesen. Die habe ich mir dann geladen und auf eine CD getoastet. Der erste Durchlauf ist nach einer halben Stunde ohne Fehler durch, und ich lasse ihn noch ein paar Stunden laufen.

Und wie wir weitermachen, schreibt ihr mir ja.
 
PC im abgesicherten Modus starten und dort den Verifier wieder deaktivieren.

@MagicAndre: Wieso sollte der Verifier hier (grundsätzlich) nicht helfen können?
Für den 109er gibt es grundsätzlich drei mögliche Ursachen:
1. Treiberprobleme
2. Probleme Marke "Eigenbau"
3. Hardwareprobleme

WinDbg Output Example:

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
 
Zuletzt bearbeitet:
Ja, das werde ich machen: Ich breche jetzt den Memtest86+ ab, der 3,5 Stunden die Gigabytes durch die Riegel gewalzt hat und in 3 Durchgängen keine Fehler anzeigte. Und dann werde ich versuchen, in den abgesicherten Modus zu kommen und dort den Driver Verifier zu deaktivieren.

Bis dann, ich gebe Bescheid.

Auf das Notebook sind ja zwei Jahre Gewährleistung drauf. Sollte was an der Hardware sein, dann geb ich ihn natürlich in die Reparatur. Mir schien halt eines der Dutzenden von mir installierten Programme/Treiber das Windows abstürzen zu lassen. Und weil ich nicht weiterwusste, habe ich mich hierher gewandt. Und ich fühle mich hier auch sehr gut aufgehoben, hier gibts schnelle und freundliche und kompetente Hilfe.

Soll ich dann die neuen Minidumps hier hochladen, die durch die DRIVER_VERIFIER_IOMANAGER_VIOLATION verursacht wurden?
Ergänzung ()

Ich habe den abgesicherten Modus erreicht, den Driver Verifier deaktiviert und konnte Windows wieder normal hochfahren. Danke!

Anbei die neuen Minidumps. Hoffentlich kann man denen was entnehmen. Oder gibts eine Möglichkeit an irgendein Log vom Driver Verifier zu kommen? Hätte ich da was einstellen sollen?

Anhang anzeigen Minidump aktuell.zip
 
Was kannst du jetzt machen:
1. Backup, dazu habe ich heute genug geschrieben
2. die Recovery-DVDs zu deinem NB erstellen

Was ich selbst noch machen würde:
1. Kopien von den wirklich wichtigen Daten, Emails usw.
2. in den Gerätemanager und ins Ereignisprotokoll schauen
3. Alle fremde Software in der Systemverwaltung komplett löschen
4. aufräumen, Datenträgerbereinigung

x. eventuell mal Prime95 länger laufen lassen, gute Kühlung, NB auf Abstandhaltern vom Tisch!

Später dann Backup, nur jedes wirklich notwendige Programm einzeln installieren, 3 Tage testen, Backup, nächstes Programm installieren, ...
 
Zuletzt bearbeitet:
Bevor ich ihn neu aufsetze/Werksimage zurückspiele wollte ich noch auf die Diagnose der neuen Minidumps warten und auf weitere Lösungsmöglichkeiten.

Einen Burn-In-Test habe ich im abgesicherten Modus schon mit Prime95, AIDA64 Systemstabilitätstest, Folding@Home und JAM HeavyLoad über mehrere Stunden gemacht, alles okay. Aber im normalen Modus ist eine Belastung des Systems vom Auftreten des CRITICAL_STRUCTURE_CORRUPTION Bluescreens unabhängig. Selbst nach dem Hochfahren von Windows und anschließendem 18 Minuten langen Nichtstun kommt der Bluescreen. Gerade vorhin versuchte ich mit ASUS Backtracker einen Recovery Stick zu erstellen (DVDs werden nicht mehr angeboten als Recovery Medien), als diesmal nach einer knappen Stunde der Bluescreen erschien. Beim zweiten Mal hats jetzt geklappt mit Asus Backtracker - nach 27 Minuten war der Recovery-Stick erstellt.

Wenn ich bloß wüsste, was Windows abstürzen lässt ...
 
Du tust mir jetzt echt leid. Besser könnte ich das auch nicht machen.

Ich würde in Kürze das NB noch mal frischmachen, nur offizielle MS-Anwendungen installieren und inständig hoffen, dass es damit abstürzt - und zurück damit!
 
simpel1970 schrieb:
@MagicAndre: Wieso sollte der Verifier hier (grundsätzlich) nicht helfen können?

weil ich das auch mal probiert hatte und alle Nutzer haben mir die neuen Dumps gegeben und da war nix neues drin.

knubl2 schrieb:
Ergänzung ()

Ich habe den abgesicherten Modus erreicht, den Driver Verifier deaktiviert und konnte Windows wieder normal hochfahren. Danke!

Anbei die neuen Minidumps. Hoffentlich kann man denen was entnehmen.

Laut der neusten Dump knallt es durch den Treiber azvusb.sys (AzureWave Technologies)

Code:
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 000000000000022e, The caller has completed a successful IRP_MJ_PNP instead of passing it down.
Arg2: fffff800d4694a70, The address in the driver's code where the error was detected.
Arg3: ffffcf8014f54dc0, IRP address.
Arg4: 0000000000000000

Debugging Details:
------------------


BUGCHECK_STR:  0xc9_22e

DRIVER_VERIFIER_IO_VIOLATION_TYPE:  22e

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP

PROCESS_NAME:  System

CURRENT_IRQL:  2

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre

LAST_CONTROL_TRANSFER:  from fffff800d46846a8 to fffff800d4165ca0

STACK_TEXT:  
nt!KeBugCheckEx
nt!VerifierBugCheckIfAppropriate
nt!ViErrorFinishReport
nt!VfPnpVerifyIrpStackUpward
nt!VfMajorVerifyIrpStackUpward
nt!IovpCompleteRequest2
nt!IovpLocalCompletionRoutine
nt!IopfCompleteRequest
nt!IovCompleteRequest
azvusb
0x0
0x0


IMAGE_NAME:  azvusb.sys

BUCKET_ID:  0xc9_22e_VRF_azvusb+dbdb
 
Zuletzt bearbeitet:
Der azvusb.sys gehört zur Pinnacle USB-PC-TV-Karte mit dem TVCenter. Ich habe die Software deinstalliert, den Rechner neugestartet, jetzt läuft grad der Prime95, und hoffentlich stundenlang. Ich sage euch bescheid.
 
DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 000000000000022e, The caller has completed a successful IRP_MJ_PNP instead of passing it down.
Arg2: fffff800d4694a70, The address in the driver's code where the error was detected.
Arg3: ffffcf8014f54dc0, IRP address.
Arg4: 0000000000000000

Debugging Details:
------------------


BUGCHECK_STR: 0xc9_22e

DRIVER_VERIFIER_IO_VIOLATION_TYPE: 22e

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre

LAST_CONTROL_TRANSFER: from fffff800d46846a8 to fffff800d4165ca0

STACK_TEXT:
nt!KeBugCheckEx
nt!VerifierBugCheckIfAppropriate
nt!ViErrorFinishReport
nt!VfPnpVerifyIrpStackUpward
nt!VfMajorVerifyIrpStackUpward
nt!IovpCompleteRequest2
nt!IovpLocalCompletionRoutine
nt!IopfCompleteRequest
nt!IovCompleteRequest
azvusb
0x0
0x0
IMAGE_NAME: azvusb.sys

Das ist eine Dump des Verifiers. Wenn es jetzt keine Probleme mehr geben sollte, hat der Verifier doch etwas gebracht.
 
Zurück
Oben