I used something called Blue Screen View to load the dump file and analyse... the program has a go at identifying which drivers or code was likely causing the BSoD.
-
Lie with passion and be forever damned... -
Bad pool header. Memory issues methinks but I'll ask today. The memory.dmp file is what we would analyze, however do a google for windbg as it's the same tool Microsoft useComment
-
Chap is happy to have a look at your dump file.. but driver issues are most likely. The trick is getting your dump file!!Comment
-
Here's the dump file - compacted down to 75mb zipped!
I used Blue Screen View (thanks Mayhem) and in each case, it's ntoskrnl.exe that's highlighted. Occasionally, USBSTOR.SYS also shows the problem as well.Comment
-
I'm just trying to grab it now - i'll have a poke around and if I can't nail it I'll send it on to the Microsoft guy. He's just writing a new course for debugging Windows 7/2008 for MS so he's looking for decent examples..
It won't be ntoskrnl, but the usbstor.sys could be suspect - have you got the latest/greatest motherboard drivers?Comment
-
I do - and the latest firmware, too.
Do SSDs tend to have firmware updates I wonder? I'll have a poke around.
Appreciate it!Comment
-
hmm.. Well contrary to the other tool you used, the windows debugger is saying that it's the tcpip.sys driver.. Which by the timestamp looks to be reasonably recent. x64 version of windows 7 right?
Quick snapshot of some of the data:
************************************************** *****************************
* *
* Bugcheck Analysis *
* *
************************************************** *****************************
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: fffff28007ccc010, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002cc5a52, address which referenced memoryComment
-
Yes, x64.
I upgraded my motherboard firmware. And I also tried updating my SSD firmware, but you can't do that if it's your primary drive (well that's a lot of flipping use!)Last edited by Lyris; 26-01-2011, 18:23.Comment
-
General rule is always drivers before firmware-just in case. Is your network card integrated on your motherboard? And what sort of motherboard is it?(make etc)Comment
-
It's a Gigabyte GA-X58A-UD3R (rev. 2.0). The network stuff is all on-board. I'll grab new drivers for that and hope for the best.Comment
-
Quick googlage finds quite a few people with bsod's on the v1.0 of that motherboard.Comment
-
Hopefully the new LAN driver fixes the issue.
If it happens again, I'll contact Gigabyte and tell you how it goes.
Not hugely impressed with this - this is the first time I've strayed from an ASUS board in years and was worried about stability...
Thanks to this thread I now know how to better debug the issue. Microsoft should really make the error messages more useful - if you turn the machine on first thing in the morning and you're in a hurry to check your email, the last thing you have time to do is note down which driver caused the problem. I'm grateful for your help, but I shouldn't have had to ask the NTSC-UK forum and learn about aftermarket utilities to get this far.Last edited by Lyris; 26-01-2011, 20:13.Comment
-
Hope it works for you mate - gigabyte should be all over it really though.Originally posted by Lyris View PostComment
-
No crashes this morning!Comment
-
Comment