Plagued by random BSoDs

TruePikachu · 10 Jul 2015

Poking in again, still not solved. It is, however, causing access violations more frequently right now in user code.

I've attached the full current list of drivers, as exported from DriverView. It could be possible that I somehow have a problematic version of a MS driver, which is never seen to need updating (and, by extension, repair).

I'm going to mess around with my most recent kernel dump, which is from yesterday, IIRC. I've been plagued by whatever driver is responsible for far too long.

TruePikachu · 04 Aug 2015

Got an interesting Verifier crash last night. Had Verifier running on all drivers (though with only the special pool, IRQL, DMA, and misc. checks).

Code:

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff9600007660e, Address of the instruction which caused the bugcheck
Arg3: fffff880076a8a20, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.
(…)
FAULTING_IP: 
win32k!xxxBeginPaint+13a
fffff960`0007660e 432c02          sub     al,2

CONTEXT:  fffff880076a8a20 -- (.cxr 0xfffff880076a8a20;r)
rax=0000000000000000 rbx=fffff900c3206750 rcx=fffff900c3200a70
rdx=0000000000000008 rsi=ffffffff92040fb4 rdi=0000000000000002
rip=fffff9600007660e rsp=fffff880076a9400 rbp=fffff880076a95b0
 r8=00000000000001ef  r9=0000000000000001 r10=0000000056008b4d
r11=00000000c0000880 r12=0000000000000000 r13=fffff880076a94c0
r14=0000000000000001 r15=0000000000010086
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246

WinDbg later goes to say that the IP is misaligned (X64_IP_MISALIGNED; how does this happen?) and blame the hardware; I really don't believe that, and rather believe that the spray caught win32k.
That function which crashed, I believe, is called frequently, so it should be a simple matter of looking for the issue and searching for what still has a reference to whatever bytes got changed. Except when I rebooted, the minidump was present, and there was no MEMORY.DMP...so whatever did it is a mystery, since this minidump is useless for finding the cause.

Just to make sure, since both MC86+ and Prime95 passed, as well as Furmark (which I ran just in case, since several crashes have been in GPU-heavy conditions), there likely isn't a hardware problem, correct? I haven't overclocked anything (intentionally; AMD Overdrive is the only thing which would have, and I haven't messed with it at all, and it isn't even on here anymore), Linux is rock-solid (when I have it booted from an external medium), and thermal limits aren't being exceeded (Prime95 peaked at 74°C on a chip rated for 100°C, and Furmark IIRC didn't even reach 70°).

What, other than the video driver, can cause a system to stop responding (confirmed from lack of response to ACPI shutdown) when the displays go to standby? I can frequently lock up the system (and sometimes crash it, like this recent Verifier dump) just by issuing a user32.dll:SendMessage(HWND_BROADCAST,WM_SYSCOMMAND,SC_MONITORPOWER,2) to standby the displays.

TruePikachu · 04 Aug 2015

So soon, another minidump which failed to write the full MEMORY.DMP. Something might be messed up, since it was a couple days ago...

Code:

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
        use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
        use .trap on that value
Else
        .trap on the appropriate frame will show where the trap was taken
        (on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050033
Arg3: 00000000000406f8
Arg4: fffff8800415a9e0
(…)
STACK_TEXT:  
fffff880`009f1c68 fffff800`034d0fe9 : 00000000`0000007f 00000000`00000008 00000000`80050033 00000000`000406f8 : nt!KeBugCheckEx
fffff880`009f1c70 fffff800`034cf4b2 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`009f1db0 fffff880`0415a9e0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2
fffff880`090f8330 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : dxgkrnl!DxgkCheckOcclusion+0x308

This was with monitor standby, which I figured was a good idea to test when screensharing with a friend on Skype. Sadly, no full dump this time either...

EDIT: Is it possible I wasn't getting the full dump since the pagefile was too small, despite being system managed? I just reconfigured it to be 8-16GB large, to see if that helps anything.

**cluberti** · 04 Aug 2015

System Managed can be a problem yes. Make sure it's RAM+255MB (at least) min and max, and that should be sufficient for a full dump. The paging file must be on the same volume as \Windows as well, for what it's worth.

TruePikachu · 05 Aug 2015

6GB of ram, 8-16GB pagefile on the only mounted HDD volume...yeah, this should probably work fine :)

I have Verifier disabled right now (since I needed CPU time), but decided to change the dump mode from kernel dump to full dump. Using the registry hack, of course, but this might help at least somewhat with debugging.

TruePikachu · 14 Aug 2015

Hmmm... Firefox just crashed; I pulled the dump file and it was an access violation:

Code:

FAULTING_IP: 
xul!CallWindowProcCrashProtected+528b5
5dd85650 a5              movs    dword ptr es:[edi],dword ptr [esi]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 5dd85650 (xul!CallWindowProcCrashProtected+0x000528b5)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000001
   Parameter[1]: 00001118
Attempt to write to address 00001118
(...)
STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
003fde1c 6e9c3aa1 08ec3e54 21c43390 1a28ec80 xul!CallWindowProcCrashProtected+0x528b5
003fde38 5ddcfb13 0c3e0168 08ec3e50 00000000 mozglue!aligned_free+0xd1
003fde50 5de9f03d 00000000 00000000 00000000 xul!mozilla::LoadInfo::QueryInterface+0xe59b
003fde60 5dd89015 00000000 0c3e0224 1a2e4000 xul!JSTracer::setTracingLocation+0x46dad
00000000 00000000 00000000 00000000 00000000 xul!CallWindowProcCrashProtected+0x5627a
(...)
0:000> lmvm xul
start    end        module name
5daf0000 5fe91000   xul        (export symbols)       xul.dll
    Loaded symbol image file: xul.dll
    Mapped memory image file: C:\Program Files (x86)\Mozilla Firefox\xul.dll
    Image path: C:\Program Files (x86)\Mozilla Firefox\xul.dll
    Image name: xul.dll
    Timestamp:        Thu Aug 06 03:51:45 2015 (55C33C41)
    CheckSum:         022DBD7C

(I don't expect anyone here to see if there is actually a bug, but I have it mentioned just in case someone does want to check).
This coupled with the access violations that Java has had recently tells me that I'm still getting spray at the moment, it just hasn't killed the system yet.
Since the last dump, I had reverted the graphics and AMD chipset drivers back to the OEM versions again. I had also run CCleaner (since someone somewhere mentioned the Java crash might be from a registry issue; I don't see how that is possible, but I ran CCleaner just in case (yes, a real CCleaner, direct from Piriform's site)). And I think the timestamp for stwrt64.sys (IDT PC Audio) got nulled by something, since it has a modified date of midnight 2000 UTC (12/31/1999 5PM for PST).

I just started a new run of sfc.exe, just in case. When it finishes, I'll probably need someone to verify checksums from files which failed verification (since that tends to happen with some files from Windows Update). I'm almost convinced it's not a 3rd-party driver issue, since I've pretty much tested every non-OEM 3rd party driver on here through removal and getting crashes.

EDIT: Not a nulled modification date; NTFS's epoch is in 1601. Still strange it's the Y2K point, though.

TruePikachu · 14 Aug 2015

Okay, the CBS.log is attached. I know that autochk.exe (probably winupdate false positive), BitsTransfer.psd1, CNBP_342.DLL.mui (only in the winsxs/ tree), ir41_qc.dll (with an instance in both system32/ and syswow64/; identical), and ir41_qcx.dll (also only in winsxs/) failed through SFC.

...SFC verifies stuff in system32/drivers, right?

EDIT: Just got autochk.exe and BitsTransfer.psd1 verified by MD5 from a friend. ir41_qc.dll doesn't match, however, so that _might_ be actual corruption.

TruePikachu · 23 Aug 2015

Want a second opinion on this, one driver which I haven't done tested through uninstall is my mouse driver (not touchpad). I haven't really tested it since the mouse itself is a gaming mouse (Logitech G600) with the most up-to-date support drivers installed, and uninstalling the drivers will revert it to using a really horrible MMORPG profile versus what I have it set to right now (which has useful stuff like the modifier keys, the lock keys, and the ability to launch stuff like Process Explorer)...That and one of my friends has the software installed as well (different hardware, but same drivers), but no problems like what I'm having.

I really need these drivers to be functional, so I have no idea what I'll do if they are actually the cause. The DRT doesn't list anything bad about them (LGBusEnum, LGSHidFilt, and LGVirHid), and web searches don't really find anything bad about them either, so I'm tempted to think they're OK.

TruePikachu · 23 Aug 2015

Uhhh... I just saw my NB clock hit 1605.8 MHz. My RAM is all 1600. Am I misreading something, or is something overclocking the RAM?

EDIT: 1600-speed as in what wmic reports

Code:

BankLabel  Speed
CHANNEL A  1600
CHANNEL B  1600

EDIT: New peak of 1618.6 MHz

EDIT: CPU-Z is saying that the memory frequency is at the 1:8 ratio from the FSB frequency, which peaked at 101.2MHz this login (809.6MHz), and the memory timings table only goes up to 800MHz, the max bandwidth (PC3-12800). Either way, it looks like the memory is being pushed too hard every now and then. For the record, this login has the FSB clock logged at 99.8..101.2MHz ≡ 798.4..809.6MHz. I'll get it monitored and see what happens when I run Minecraft, which tends to crash the JVM with access violations.

TruePikachu · 25 Aug 2015

Got a new crash

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: fffff88004578fd5, The address that the exception occurred at
Arg3: fffff880031ac728, Exception Record Address
Arg4: fffff880031abf80, Context Record Address
(…)
STACK_TEXT:  
fffff880`031ac960 fffff880`04568731 : fffffa80`07b8d000 fffff8a0`065d8de0 fffff8a0`031487a0 fffffa80`0782b000 : dxgmms1!VIDMM_SEGMENT::MarkResourcesForEviction+0x201
fffff880`031ac9c0 fffff880`04566f3f : fffff8a0`10fadcd0 fffffa80`07b8d000 fffffa80`092bd140 fffffa80`07b8d000 : dxgmms1!VIDMM_GLOBAL::NotifyAllocationEviction+0x59
fffff880`031ac9f0 fffff880`04562498 : fffffa80`0b059bc0 00000000`00000000 00000000`00000000 fffff880`031acb60 : dxgmms1!VIDMM_GLOBAL::ProcessDeferredCommand+0x523
fffff880`031acb10 fffff880`04580301 : fffffa80`00000000 fffffa80`04ec2010 00000000`0000000f fffff880`0458209d : dxgmms1!VidMmiProcessTerminationCommand+0x4c
fffff880`031acb60 fffff880`0457f58c : fffff880`009efec0 fffffa80`0a353d50 00000000`00000000 fffffa80`04ec2010 : dxgmms1!VidSchiSubmitDeviceCommand+0x39
fffff880`031acb90 fffff880`0457f02a : 00000000`00000000 fffffa80`0a353d50 00000000`00000080 fffffa80`04ec2010 : dxgmms1!VidSchiSubmitQueueCommand+0xb0
fffff880`031acbc0 fffff800`03759aba : 00000000`06b07952 fffffa80`0779b260 fffffa80`04eb5450 fffffa80`0779b260 : dxgmms1!VidSchiWorkerThread+0xd6
fffff880`031acc00 fffff800`034b1426 : fffff880`009eb180 fffffa80`0779b260 fffff880`009f5f40 00000000`ffffffff : nt!PspSystemThreadStartup+0x5a
fffff880`031acc40 00000000`00000000 : fffff880`031ad000 fffff880`031a7000 fffff880`031ac540 00000000`00000000 : nt!KiStartSystemThread+0x16

My dump is 5.47GB; Windows did a full memory dump. As a result, I can not distribute the dump (due to both size and content), but I can easily issue WinDbg commands to it to help find whatever gave the bad address (ffffffff`ffffffff).
As a bit of scope, I had just exited Minecraft after a session. Specifically, the child process with the game itself had exited just around the time of the dump (or maybe didn't exit fully yet, I'll check that).
EDIT: It didn't exit yet. PID 5968, 1 thread, 6,414,600K virtual size. Time to see what it was doing, exactly, in that thread.
EDIT:

Code:

0: kd> !thread 0xfffffa80069e0220
THREAD fffffa80069e0220  Cid 1750.0878  Teb: 000007fffffd5000 Win32Thread: fffff900c1f64010 READY on processor 0
Not impersonating
DeviceMap                 fffff8a00613f8e0
Owning Process            fffffa800a21d060       Image:         javaw.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      11682976       Ticks: 0
Context Switch Count      109727         IdealProcessor: 0                 LargeStack
UserTime                  00:00:57.002
KernelTime                00:00:02.246
Win32 Start Address msvcr100!endthreadex (0x000000006e5e1dbc)
Stack Init fffff8800a1c3c70 Current fffff8800a1c33e0
Base fffff8800a1c4000 Limit fffff8800a1bc000 Call 0
Priority 11 BasePriority 10 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`0a1c3420 fffff800`034c509e : fffffa80`069e0220 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSwapContext+0x7a
fffff880`0a1c3560 fffff880`04581b34 : fffffa80`0779b260 fffffa80`00000000 fffffa80`0a4f6e00 fffffa80`0779b368 : nt!KeSetEvent+0x3dc
fffff880`0a1c35d0 fffff880`04548d84 : fffffa80`00000001 fffffa80`07b8d000 fffffa80`0a4f6ec0 fffff8a0`0510f3d0 : dxgmms1!VidSchiSubmitCommandPacketToQueue+0x1d8
fffff880`0a1c3640 fffff880`0448998e : fffff8a0`06173000 fffff8a0`06173000 00000000`00000001 00000000`00000000 : dxgmms1!VidMmTerminateAllocation+0x268
fffff880`0a1c3720 fffff880`0448daec : 00000000`00000000 fffff880`0a1c3b60 00000000`00000000 fffff880`044543cb : dxgkrnl!DXGDEVICE::TerminateAllocations+0x166
fffff880`0a1c3770 fffff880`04490285 : fffff8a0`06173000 fffff880`0a1c3850 00000002`00000000 00000000`00000701 : dxgkrnl!DXGDEVICE::DestroyAllocation+0x44c
fffff880`0a1c3800 fffff960`001db692 : 00000000`1445b858 fffffa80`069e0220 00000000`00000020 00000000`1bac4a10 : dxgkrnl!DxgkDestroyAllocation+0xa9d
fffff880`0a1c3ab0 fffff800`034becd3 : 00000000`00000000 00000000`14434040 fffffa80`05def901 00000000`00000000 : win32k!NtGdiDdDDIDestroyAllocation+0x12
fffff880`0a1c3ae0 000007fe`fe144a5a : 00000000`6fb3caad 00000000`11593920 00000000`1169ed78 00000000`1444da80 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`0a1c3ae0)
00000000`1169ecd8 00000000`6fb3caad : 00000000`11593920 00000000`1169ed78 00000000`1444da80 00000000`1444da80 : GDI32!NtGdiDdDDIDestroyAllocation+0xa
00000000`1169ece0 00000000`11593920 : 00000000`1169ed78 00000000`1444da80 00000000`1444da80 00000000`7792d670 : aticfx64!gslCfxExit+0x748d
00000000`1169ece8 00000000`1169ed78 : 00000000`1444da80 00000000`1444da80 00000000`7792d670 00000000`00000005 : 0x11593920
00000000`1169ecf0 00000000`1444da80 : 00000000`1444da80 00000000`7792d670 00000000`00000005 00000000`1c204998 : 0x1169ed78
00000000`1169ecf8 00000000`1444da80 : 00000000`7792d670 00000000`00000005 00000000`1c204998 00000000`00000000 : 0x1444da80
00000000`1169ed00 00000000`7792d670 : 00000000`00000005 00000000`1c204998 00000000`00000000 00000000`1c18a640 : 0x1444da80
00000000`1169ed08 00000000`00000005 : 00000000`1c204998 00000000`00000000 00000000`1c18a640 00000000`1d14dc50 : ntdll!PebLdr+0x30
00000000`1169ed10 00000000`1c204998 : 00000000`00000000 00000000`1c18a640 00000000`1d14dc50 00000000`1169ee00 : 0x5
00000000`1169ed18 00000000`00000000 : 00000000`1c18a640 00000000`1d14dc50 00000000`1169ee00 00000000`6fb191fc : 0x1c204998

EDIT: Found the corruption which caused the crash:

Code:

lea     rdx,[rsi+198h]          ; RSI = fffff8a0`10fadcd0
                                ; RDX = fffff8a0`10fade68
mov     rax,qword ptr [rdx+8]   ; RAX = ff05f8a0`01c951a8
                                ;         ^^ ERROR!
mov     rcx,qword ptr [rdx]     ; RCX = ff38f8a0`08ac3798
                                ;         ^^ ERROR!
mov     qword ptr [rax],rcx     ; CRASH

The specific manifestation of the corruption (the specific alignment) is the same as the other dump I found the corruption in. This (now) has a physical memory address of 1`1b73fe68, time to check the other dump's physical address.
EDIT: Old has a physical address of 1`197a66c0. Somewhat far, but close enough to be on the same stick (assuming that the sticks were in the same places both times...is it possible to check that from WinDbg?) If they are indeed on the same stick, I'll swap the two to see if the corruption moves (which would likely mean my slight overclocking theory has merit, at least that it is one stick having trouble). If the corruption moves to the other stick, it is almost certainly a driver problem or something.
EDIT: Sticks were in the same place both times (under slot 4GB, over slot 2GB.) Time to swap them