I occasionally (always at the least convenient moment...) receive this BSOD on my Windows 7 desktop PC:
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
Trying to find out more information about this seems to be futile because the file C:\Users\al\AppData\Local\Temp\WER-37500-0.sysdata.xml
doesn't exist (the folder exists, but not any file that starts with "WER"), and attempting to analyze the minidump file yields the following:
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
and:
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
Well, hal.dll
and ntoskrnl.exe
are part of the OS and there doesn't seem to be anything I can do to upgrade those "drivers".
I know that the hardware is perfect (including RAM voltages in BIOS etc) because this same exact system works perfectly with Ubuntu 8
and Ubuntu 10
(triple-boot config). The problem is definitely in the system software, but how do I find out what it is?
SRVC:\SymbolCachehttp://msdl.microsoft.com/download/symbols
(replace C:\SymbolCache with path of your choice)Probably caused by : usbhub.sys ( usbhub!UsbhTrapFatalTimeout_x9f+28 )
, but you can click the !analyze -v
link to get detailed stack trace.A much simpler way would be to use BlueScreenView. If you look into the "Address In Stack" column you can see where the problematic call originally came from. This is the last row that has an entry in this column.
Taking the driver file name you can back-track the vendor/application/device it belongs to and therefore find the culprit with a high probability.
User contributions licensed under CC BY-SA 3.0