Solved Recurring BSOD during desktop use (0x0000003b)

[Raider82]

Hi everyone.

This is a self-built system which has been running (mostly) smoothly for about four months now with a BSOD every now and then. Suddenly I've had three in the space of four days.

In the attached file are the last four minidumps. Each and every one of them has always happened on the regular desktop, for example during video playback or browsing the net. Three of them (SYSTEM_SERVICE_EXCEPTION 0x0000003b) were during active use, while the other one (NTFS_FILE_SYSTEM 0x00000024) occurred over night while I was in bed.

I've tried to search for some more information on the specific error codes, but haven't really found one thing that stood out. Can you find out any specific part of my system that is causing these errors? If not, what steps must I take to locate and eliminate this problem?

Thanks for your efforts,
Raider

 

[richc46]

Welcome
You have given us about 6 dump reports. They have different conclusions. I would lean toward a hardware problem. Lets test your hardware, then move on.
Initial Hardware Diagnostics

 

[Raider82]

Richard, I'm grateful that you took the time to have a closer look at my minidumps. When I tried to look at them closer with the Nirsoft BlueScreenView, I saw that 3 of the 4 BSOD's I included minidumps of in the zip-file, were caused by the same file and address (ntsokrnl.exe+7f1c0). How did you come to several different conclusions from that?

Anyway, after 4 cycles with MemTest86 4.2 produced no errors, I used SeaTools because the original Samsung diagnostic tools weren't available for download anymore. That produced no errors either from any of my three drives. What else can I test?

 

[richc46]

Very good, I like the fact that you want to understand why I am suggesting what I did.
First of all we do not use Blue Screen View. I must be careful of what I say at this point, but we prefer windbg, because the results sometimes differ, so lets keep it at that.
In 2 of the 4 dumps, I saw this
icrosoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Users\Richard\AppData\Local\Temp\Temp1_crashdata.zip\Seven Forums\070912-20014-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17835.amd64fre.win7sp1_gdr.120503-2030
Machine Name:
Kernel base = 0xfffff800`02e08000 PsLoadedModuleList = 0xfffff800`0304c670
Debug session time: Mon Jul 9 11:10:23.735 2012 (GMT-4)
System Uptime: 12 days 5:00:22.262
Loading Kernel Symbols
...............................................................
................................................................
................................
Loading User Symbols
Loading unloaded module list
..................................................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 3B, {c000001d, fffff80002e7c576, fffff8800bdffa00, 0}
Probably caused by : ntkrnlmp.exe ( nt!ExpReleaseResourceForThreadLite+46 )
Followup: MachineOwner
---------
ntkrnlmp.exe is a driver, but it is a Microsoft Driver (a lead driver so to speak) and is not the cause. All that is given in that report is that the cause is a driver.
Your other two showed different drivers. Now this part comes from experience. When the reports all show different drivers the cause is many times hardware
You must use memtest for 8 passes and then test each stick in a known good slot. Lets do it right, before we rule out memory.

 

[Raider82]

Thanks for this in-depth response to my question.

The extended RAM checks took me a while longer. Even after running the tests with ~10-12 passes during the evening & night, it hasn't produced a single error. I guess that means the RAM is okay then.

For some curious reason, I haven't had a single BSOD since I posted my minidumps in the first post and it's a clear difference from a few almost daily crashes prior to that.

This newly found stability might have something to do with what I did since posting here. First, I noticed that I had always used the Oracle VirtualBox application hours before a BSOD, so I uninstalled it for the time being. On the hint from a co-worker, I raised the CPU vCore to an offset of +0.050 volt in order to eliminate the possibility of an unstable CPU. To get ahead of the question: no, I had been running everything with the original unchanged BIOS configuration and have not undervolted or overclocked in any way.

I don't know if I should hope for another BSOD now or not. I'll gladly test my other hardware for errors, but after both RAM & HDD have been ruled out, what's left that I can reliably test without a crash around the corner?

 

[richc46]

If you followed my instructions and took the ram out to test each in a good slot, you may have reseated them when put back, ie. one stick may have been loose or dusty.

 

[Raider82]

It's been a few days again and the BSOD problem hasn't surfaced again. Everything's been running incredibly stable lately.

Yes Richard, I did exactly as you told me to. After you let me know that 4 passes was too little to get a credible result, I tested the present RAM configuration of 2x4GB as they were and when that didn't produce an error after I let it run over-night to a total of ~10 passes, I removed both modules and tested them separately. While I did a bit of cleaning as well, without any pressured air on hand, I wasn't able to ensure completely dust free RAM slots. If the RAM was indeed the problem, maybe the repeated movement of the modules was enough.

While I'm not sure what exactly has been the problem, my issues have all thankfully gone now. I just wanted to post again to thank you for your help in trying to solve my problems and for your patience and willingness to explain things to me beyond the correct answers, when I asked about more details on my minidumps. Thanks

 

[richc46]

If you took the ram out to test, when you reinstalled you may have put them in tighter than they were, you reseated them and that may have been the problem.