Come trovare la fonte di questo BSOD? Come sistemarlo?

Occasionalmente (sempre nel momento meno conveniente ...) ricevo questo BSOD sul mio PC desktop Windows 7:

  Problem signature:
  Problem Event Name:   BlueScreen
  OS Version:   6.1.7601.2.1.0.256.1
  Locale ID:    1033

  Additional information about the problem:
  BCCode:   124
  BCP1: 0000000000000000
  BCP2: FFFFFA8007BBB028
  BCP3: 00000000B2000040
  BCP4: 0000000000000800
  OS Version:   6_1_7601
  Service Pack: 1_0
  Product:  256_1

  Files that help describe the problem:
  C:\Windows\Minidump\010812-16578-01.dmp
  C:\Users\al\AppData\Local\Temp\WER-37500-0.sysdata.xml

Cercare di trovare ulteriori informazioni su questo sembra essere inutile perché il file C:\Users\al\AppData\Local\Temp\WER-37500-0.sysdata.xmlnon esiste (la cartella esiste, ma non tutti i file che iniziano con "WER") e tentare di analizzare il file minidump produce quanto segue:

Bug Check Code: 0x00000124
Parameter 1:    00000000`00000000
Parameter 2:    fffffa80`07bbb028
Parameter 3:    00000000`b2000040
Parameter 4:    00000000`00000800
Causing driver: hal.dll
Address:    hal.dll+12a3b
Processor:  x64
Crash address:  ntoskrnl.exe+7cc40
CPU count:  4
Major ver:  15
Minor ver:  7601
Dump size:  283,576

Filename:       ntoskrnl.exe
Addr. in Stack: ntoskrnl.exe+18d513
From addr:      fffff800`02a18000
To addr:        fffff800`03001000
Size:           0x005e9000
Timestamp:      0x4e02aaa3
Time string:    6/22/2011 9:53:23 PM
Product name:   Microsoft® Windows® Operating System
File desc:      NT Kernel & System
File ver:       6.1.7601.17640 (win7sp1_gdr.110622-1506)
Company:        Microsoft Corporation
Full path:      C:\Windows\system32\ntoskrnl.exe

Bene, hal.dlle ntoskrnl.exefanno parte del sistema operativo e non sembra esserci nulla che io possa fare per aggiornare quei "driver".

So che l'hardware è perfetto (comprese le tensioni RAM nel BIOS, ecc.) Perché questo stesso sistema esatto funziona perfettamente con Ubuntu 8e Ubuntu 10(configurazione a triplo avvio). Il problema è sicuramente nel software di sistema, ma come faccio a sapere di cosa si tratta?

— Eternal Learner
fonte

Potremmo aiutarti se Windows 7 fosse open source ...

— m0skit0

Qualcuno dei passaggi da [qui] ( sevenforums.com/crash-lockup-debug-how/… aiuta?

— AndrejaKo

@AndrejaKo Questa è una grande risorsa. Sembra esattamente quello che stavo cercando. Si prega di inviare nuovamente come risposta e lo accetterò. Grazie +1 per ora.

— Eternal Learner

@Eternal Learner Il semplice collegamento a una risposta non è considerata una risposta qui in SuperUser, dovrebbe rimanere un commento a meno che non vogliano copiare l'intero contenuto della risposta in una risposta SuperUser. Il motivo principale di ciò è il marciume dei link e i siti Web che scompaiono dal cyberspazio. Il secondo motivo è che SuperUser non è un forum.

— Moab,

Risposte:

Installa gli strumenti di debug per Windows .
Dopo l'installazione, apri WinDbg dal menu di avvio.
Fai clic su File> Percorso file simbolo e inserisci (sostituisci C: \ SymbolCache con il percorso che preferisci)SRVC:\SymbolCachehttp://msdl.microsoft.com/download/symbols
Fai clic su File> Apri Crashdump e apri il file memory.dmp in% SystemRoot% (in genere C: \ WINDOWS o C: \ WINNT) O l'ultimo file in% SystemRoot% \ Minidump se hai i dump completi disabilitati.
Il driver in questione verrà elencato di seguito, in modo simile al seguente:, Probably caused by : usbhub.sys ( usbhub!UsbhTrapFatalTimeout_x9f+28 )ma è possibile fare clic sul !analyze -vcollegamento per ottenere una traccia dettagliata dello stack.

— kinokijuf
fonte

Questo è utile per gli sviluppatori di driver, non per un amministratore.

— Eternal Learner

@EternalLearner Ma ti mostra la fonte BSOD, che è una buona cosa.

— Kinokijuf,

Sì, è una buona cosa, ma ho già tutte queste informazioni da BlueScreenView. L'unico vantaggio di !analyze -vè la possibilità di mostrare il codice sorgente se ce l'ho e dal momento che non sono lo sviluppatore di ntoskrnl.exe, non mi aiuta. A parte il fatto che è orribilmente gonfio e compromette ulteriormente la stabilità del sistema. L'installazione è giustificata solo quando si sviluppano driver.

— Eternal Learner,

@EternalLearner Quindi temo sia impossibile ottenere ulteriori informazioni.

— Kinokijuf,

Un modo molto più semplice sarebbe usare BlueScreenView . Se guardi nella colonna "Indirizzo nello stack" puoi vedere da dove proviene la chiamata problematica. Questa è l'ultima riga che ha una voce in questa colonna.

Prendendo il nome del file del driver è possibile rintracciare il fornitore / l'applicazione / il dispositivo a cui appartiene e quindi trovare il colpevole con un'alta probabilità.

— Roberto
fonte

BlueScreenView è esattamente dove ho preso le informazioni che ho pubblicato nella mia domanda. Il retro-track si ferma a quello che ho postato in origine: ntoskrnl.exe+18d513. Il commento pubblicato da @AndrejaKo è la risposta migliore finora.

— Eternal Learner