Solved Plagued by random BSoDs

[TruePikachu]

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]

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

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]

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

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]

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]

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]

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

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]

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]

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]

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

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]

Got a new crash

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:

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:

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

 

[TruePikachu]

It does not look like a hardware issue, working on the assumption that the RAM sticks are assigned in the order they are listed by SMBios. If the assumption holds true, then the 4GB stick would be assigned to 0`00100000..1`000FFFFF and the 2GB stick would be at 1`00100000..1`800FFFFF. Looking at my current progress of isolating the issue (by hand), we have corruption at:

VIRTUAL ADDRESS     P ADDRESS    CHANGE
fffff980`5603c6c6 = 1`197a66c6 : f1 -> ef
fffff980`5603c6ce = 1`197a66ce : f1 -> ef
fffff980`5603c6d6 = 1`197a66d6 : f1 -> ef
fffff980`5603c6de = 1`197a66de : f1 -> ef
fffff980`5603c6e6 = 1`197a66e6 : f1 -> ef
fffff980`5603c6ee = 1`197a66ee : f1 -> ef
fffff980`5603c6f6 = 1`197a66f6 : f1 -> ef
fffff980`5603c6fe = 1`197a66fe : f1 -> ef
fffff8a0`10fade6e = 1`1b73fe6e : ff -> 38
fffff8a0`10fade76 = 1`1b73fe76 : ff -> 05
fffff8a0`095bfe26 = 0`b73aae26 : ff -> 0c
fffff8a0`095bfe36 = 0`b73aae36 : ff -> 04

The last two rows of the table proper would be on the 4GB, versus the 2GB (working with the mentioned assumption). However, one can note that the low three bits of the address (either physical or virtual; the low 12 bits are always identical) are always 110b ≡ 0x6 or 0xe. This means that whatever is doing the spray is doing something like a `byte ptr [rax+6]` (where RAX is qword-aligned); I _might_ actually copy the most recent (6GB) memory dump to my Linux-based server box and write up a program which searches for any code which would refer to such a pointer. Maybe a smaller dump, actually, since driver code would be in the kernel memory area, right?
EDIT: Current physical address mask is 0_1___10_11_01___1___1______110b; I expect the higher bits to disappear as I do more analysis
EDIT: It simplifies to 110b, so it is almost certain that it is, in fact, spray from SOMEthing.

 

[ThrashZone]

I was reading through "this not sure why" but then noticed this is a 8 month old thread

 

[TruePikachu]

Hm, well I just confirmed that the spray is what causes Minecraft to craft when it is the JVM which dies. The error log file thing (since I can't manage to get Java to dump on crash) reports RDX=0x009d0006f1678120, and the crashing instruction was using RDX as a pointer. This was just after using RAX as a pointer to get the value into RDX.

Since I have no way to catch the JVM when it crashes, I can't check where it was in the grand scheme of things (either the kernel's virtual address or the system's physical address).

 

[TruePikachu]

And just proved it isn't a problem with any drivers that DriverView lists as 3rd party; even having them all either disabled (renamed to .sys.disabled) or reverted to the OEM version (for drivers which have one) results in a crash from spray.

The issue is either in ir41_qcx.dll (unlikely since it isn't loaded) or one of the 147 Microsoft drivers I have loaded right now. This can be reduced by knowing that it passed a run of SFC, so it is something which either SFC doesn't check, or provided initially through Windows Update (and never registered with SFC).

I do not look forward to getting checksums and versions for all of these verified against my friends. But I'm almost certain it has to be one of these.

EDIT: Wrote up a Powershell script which would provide easily diff(1)able output. For the curious, it is at http://cdusto.selfip.com/getVersionAndMD5.ps1

EDIT: First run, checking against a different local Win7x64 machine, says that apisetschema.dll, cdd.dll, ksecdd.sys, ksecpkg.sys, mountmgr.sys, mrxsmb.sys, mrxsmb10.sys, mrxsmb20.sys, and ntoskrnl.exe (?!) are all outdated. Additionally, the files ntdll.dll, smss.exe, usbrpm.sys, volsnap.sys, and win32k.sys have matching version numbers, but differing checksums. I'll wait for another output log to help isolate against possible corruption on the first tested system, but I'm pretty sure that corruption exists on here.

EDIT: The list of differences between my system and a "stable" Win7x64:

• apisetschema.dll is 6.1.7601.18798 instead of .18933
• cdd.dll is 6.1.7601.17514 instead of .17554
• dxgkrnl.sys is 6.1.7601.22720 instead of .18510
• dxgmms1.sys is 6.1.7601.22410 instead of .18126
• ksecdd.sys is 6.1.7601.18912 instead of .18933
• ksecpkg.sys is 6.1.7601.18912 instead of .18933
• mountmgr.sys is 6.1.7600.16385 instead of .7601.18933
• mrxsmb.sys is 6.1.7601.18912 instead of .18933
• mrxsmb10.sys is 6.1.7601.18912 instead of .18933
• mrxsmb20.sys is 6.1.7601.18912 instead of .18933
• ntdll.dll is 6.1.7600.16385, and doesn't match MD5 checksum
• ntsokrnl.exe is 6.1.7601.18798 instead of .18933
• smss.exe is 6.1.7600.16385, and doesn't match MD5 checksum
• usbrpm.sys is 6.1.7600.16385, and doesn't match MD5 checksum
• volsnap.sys is 6.1.7600.16385, and doesn't match MD5 checksum
• win32k.sys is 6.1.7600.16385, and doesn't match MD5 checksum

The five files which didn't match checksums all match versions from known-good instances of Win7x64. I'd bet the corruption is coming from one of them.

EDIT: Just installed a batch of updates. cdd.dll is still old, usbrpm.sys and volsnap.sys still mismatch checksums. Why does Microsoft make modifications to system files without changing their version information? It makes locating corruption a lot harder.

EDIT: And issue isn't resolved.

 

[TruePikachu]

Hmmm...I noticed that one non-OEM driver never was unloaded (LGSHidFilt.sys) - it was determined to be the best driver for my mouse even after being disabled by rename. So I'm doing a disassembly of it right now...I do not really like what I see. For instance, some subroutines have CALL instructions reading from areas of memory (within the driver's image) which appear to never be written to, and are uninitialized (e.g. at virtual address +113C8, referencing +1E550). There are also things like a `call near ptr` pointing to a procedure past the end of the image (this being as early as DriverEntry+1F). While I'm not familiar with driver development or disassembly, it looks to me like this might be the culprit.

I don't know how I would test the driver by elimination without another mouse, since Windows insists on using the (possibly crash-inducing) driver by default, even after renaming it. The main thing is that I've been using Minecraft to test for the issue disappearing (since it both uses a lot of memory and, when the JVM crashes, it helpfully dumps the registers to file so I can check the 7th byte of the registers for corruption), and I need an external mouse to play it; the touchpad on here has a strange "issue" where it doesn't register any input when typing on the keyboard, so it isn't the best thing to use...

EDIT: Driver is WHCP signed, and obtained through WinUpdate or something. Despite the strange stuff I was seeing (as someone more experienced with application disassembly instead), it doesn't look like it would be the problem.

 

[TruePikachu]

And just hit a crash within 2 1/2 minutes of bootup. X64_IP_MISALIGNED versus an access violation (so it's harder to locate the exact site of corruption), but since there wasn't a lot of time since the drivers loaded, it might be possible to locate the problematic pointer in the dump.

 

[TruePikachu]

Well then.

Does that bitmask look familiar?

The failing address puts it on the 4GB stick (I believe), but I'll have it check the 2GB alone tonight, just in case. Yes, right now I'm running on a third of my usual memory.


So I'd be looking for PC3-12800 DDR3 4GB tomorrow?

EDIT: Ignore that the pic says DDR2, CPU-Z reports DDR3. As well as PC3-12800.

 

[Laith]

You must run MemTest86+. Never use 2 different sticks together. Remove one of the sticks. It reports a failing adress on the 4GB RAM module, so it must be failing. A single error means that it's dead.

 

[TruePikachu]

You must run MemTest86+.

That was from MemTest86+ (the + blinks, and was not visible in the picture).

Never use 2 different sticks together.

Just want a bit of clarification for this (it doesn't matter for this case anymore), only one socket should be filled when running MemTest86+, or two different sizes of stick together? The memory was supplied by the OEM, so I figured it was acceptable.

It reports a failing adress on the 4GB RAM module, so it must be failing. A single error means that it's dead.

I came to the same conclusion, so earlier today I got a pair of new 4GB modules, and have those in right now. I was meaning to upgrade to 8GB for some time, and this was the perfect excuse to do so. I might put the (most likely OK) 2GB card into one of the other laptops over here (which is running on 3GB right now), but I don't know yet.

I just finished getting all the drivers (including outdated OEM ones) re-enabled (since I had disabled many of them for troubleshooting, and later so they wouldn't eat up too much of the 2GB I had), and after a fight with HP DriveGuard not reconising the disk (I got that fixed), this system is back in it's normal configuration. I'll give it time to see if it crashes before I mark solved.

 

[TruePikachu]

Might not be entirely out of the woods yet, Garry's Mod just crashed with an access violation (according to WinDbg). While I'm sure it is probably just a bug in the code, there _might_ be spray. I can't check unless I get a kernel crash, though.
I might see if I can catch spray by rebuilding the BitCoin blockchain. If even one byte in it gets sprayed on, it won't fully build and will error out.