Plagued by random BSoDs

TruePikachu · 15 Jan 2015

cluberti said:

downloading the dump file from 2 days ago right now. I would say that trusting drivers from the OEM is *usually* OK, although there's no way to be certain. Microsoft does not write drivers, they only push out drivers with security or stability updates after working with OEMs, so drivers gotten from Windows Update / Microsoft Update are no better (or worse) than what would come from the OEM directly.

In my experience, I generally start with antivirus software and software that emulates (or allows writing to) external devices. From there I look at video drivers, and after that I move down to audio, USB, and chipset drivers.

OEM drivers which I have not had issues with in the past. As in the specific driver. For example, Accelerometer.sys was never updated, and there was a time when I didn't get all these BSoDs.

MS does have a few generic drivers which are in use - things like vga.sys and usbhub.sys. There are also kernel parts found by e.g. DriverView. But I'm not saying that drivers from manufacturers on winupdate are any more reliable; I'm saying that drivers which are a part of Windows's operation and which exist and are likely in use on just about every single system are probably not the cause of the issues.

AV is Security Essentials, haven't seen any kernel stability updates for that; it likely isn't the cause. None of my virtual disk managers have been updated on here for ages, Virtual Box is the only possible canidate in that category. Video, USB, and chipset are all up-to-date, and audio is the OEM original (I had reverted it to remove it as a canidate).

I'll get VBox updated, see if anything changes.

**cluberti** · 15 Jan 2015

IN the latest dump, something in a shared svchost created a page fault, and this triggered a paged pool lookup - it complains about memory corruption (PTE invalid), which really doesn't help much. I've been sidetracked today, but I'll try to dig deeper tomorrow.

TruePikachu · 17 Jan 2015

Updating VirtualBox to the latest version did not fix anything; I have experienced 2 BSoDs since updating (the first one terminating the string of uptime including the update, the second one not having the old driver loaded in memory at all).

TruePikachu · 18 Jan 2015

Code:

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff96000735e4d, The address that the exception occurred at
Arg3: fffff880025f4638, Exception Record Address
Arg4: fffff880025f3e90, Context Record Address
(...)
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP: 
cdd!PresentWorkerThread+ae1
fffff960`00735e4d f7f1            div     eax,ecx
(...)
STACK_TEXT:  
fffff880`025f4870 fffff800`0371a73a : 00000000`040e3231 fffffa80`07ffa710 00000000`00000080 fffffa80`07fd1b30 : cdd!PresentWorkerThread+0xae1
fffff880`025f4c00 fffff800`0346f8e6 : fffff880`009eb180 fffffa80`07ffa710 fffffa80`06627060 00000028`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`025f4c40 00000000`00000000 : fffff880`025f5000 fffff880`025ef000 fffff880`025f43a0 00000000`00000000 : nt!KxStartSystemThread+0x16

http://cdusto.selfip.com/7f_dump_03.zip

**cluberti** · 19 Jan 2015

That call on the stack, cdd!PresentWorkerThread's next target is DirectX. That would point towards video drivers (and supporting software) in that dump. Note that most WDDM video drivers have both user-mode and kernel-mode components to make them work, so... that would fit the pattern of the previous dumps and kernel spray too....

TruePikachu · 20 Jan 2015

Just did a clean reinstall of the GFX (AMD's uninstaller for CCC and the display drivers, safe mode run of DDU set to not remove displays (monitors)*, reinstall of CCC, display drivers, and pretty much everything but the chipset. First sign is that CCC no longer crashes immediatly (which it had been since my less recent driver update), however I'm still on the same version numbers as reported by DriverView. While it might be the case that AMD doesn't always increment their version numbers, what is more likely is that I'm on the same drivers again.

*it is a pain to recalibrate color on all the displays I use when I dual-head - this is not related to the crashes, since they also occur during sessions when Windows has only used the primary display

TruePikachu · 22 Jan 2015

Quick update, no BSoDs since reinstalling the video drivers, but Bitcoin has been randomly crashing, so it is possible that there _might_ still be an issue, which hasn't hit the kernel yet due to random chance.

**cluberti** · 22 Jan 2015

You'd have to get a process dump of bitcoin crashing to know for sure. DebugDiag and a crash rule for the bitcoin process .exe can help in that regard.

TruePikachu · 28 Jan 2015

And a new BSoD. Too much of a headache right now to load up the dump in WinDbg, WhoCrashed report:
On Wed 1/28/2015 11:47:53 PM GMT your computer crashed
crash dump file: [ http://cdusto.selfip.com/7f_dump_04.zip ]
This was probably caused by the following module: ntkrnlmp.exe (nt!KeBugCheckEx+0x0)
Bugcheck code: 0x1 (0x774313BA, 0x0, 0xFFFFFFFF, 0xFFFFF88007EA4B60)
Error: APC_INDEX_MISMATCH
Bug check description: This indicates that there has been a mismatch in the APC state index.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.

TruePikachu · 01 Feb 2015

Back to crashing the "usual" amount, couple of SYSTEM_SERVICE_EXCEPTIONs today, as well as Explorer crashing.