Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.
  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:

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 


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?

share|improve this question
We could help you if Windows 7 was open source... – m0skit0 Jan 8 '12 at 13:56
Do any of the steps from [here](… help? – AndrejaKo Jan 8 '12 at 16:39
@AndrejaKo This is a great resource. Looks like exactly what I have been looking for. Please re-post as an answer and I will accept it. Thanks +1 for now. – Eternal Learner Jan 8 '12 at 17:01
@Eternal Learner Simply linking to an answer is not considered an answer here at SuperUser, it should remain a comment unless they want to copy the entire content of the answer over to a SuperUser answer. The main reason for this is link rot and websites that disappear from cyberspace. Second reason is SuperUser is not a forum. – Moab Jan 8 '12 at 17:31
up vote 4 down vote accepted
  1. Install the Debugging Tools for Windows.
  2. After Installing, open WinDbg from start menu.
  3. Click File > Symbol File path and enter SRV*C:\SymbolCache* (replace C:\SymbolCache with path of your choice)
  4. Click File > Open Crashdump and open the memory.dmp file in your %SystemRoot% (usually C:\WINDOWS or C:\WINNT) OR the latest file in %SystemRoot%\Minidump if you have full dumps disabled.
  5. The offending driver will be listed below, similar to this: Probably caused by : usbhub.sys ( usbhub!UsbhTrapFatalTimeout_x9f+28 ), but you can click the !analyze -v link to get detailed stack trace.
share|improve this answer
This is good for driver developers, not for an admin. – Eternal Learner Jan 9 '12 at 18:29
@EternalLearner But it shows you the BSOD source, which is a good thing. – kinokijuf Jan 9 '12 at 20:42
Yes it's a good thing but I already get all that information from BlueScreenView. The only advantage of !analyze -v is the ability to show the source code if I have it and since I am not the developer of ntoskrnl.exe, it doesn't help me. Aside from the fact that it's horribly bloated and further compromises the stability of the system. Installing it is only justified when you develop drivers. – Eternal Learner Jan 11 '12 at 4:45
@EternalLearner Then I’m afraid it’s impossible to get further info. – kinokijuf Jan 11 '12 at 6:58

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.

share|improve this answer
BlueScreenView is exactly where I took the information I posted in my question. The back-track stops at what I posted originally: ntoskrnl.exe+18d513. The comment posted by @AndrejaKo is the best answer so far. – Eternal Learner Jan 9 '12 at 18:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .