Repeated BSOD events of various types

[Mysers Briggs]

Okay, bad RAM certainly seems to be the same culprit here. Memtest just isn't showing any signs of failure, apparently.

//Performing a write operation, changing a volume size was caused by invalid operation code

ffffd000`99275cf8 fffff801`886c19a5 : 00000000`00000024 000000b5`00190637 ffffd000`99276ec8 ffffd000`992766d0 : nt!KeBugCheckEx
ffffd000`99275d00 fffff801`886c27ed : ffffd000`99276c70 00000000`00000001 fffff801`88708c28 00000000`00000000 : Ntfs!NtfsExceptionFilter+0x529
ffffd000`99275ec0 fffff800`835bdb26 : ffffd000`99278000 00000000`00000000 ffffd000`99272000 fffff800`8353f3ed : Ntfs!NtfsFsdWrite$filt$0+0x16
ffffd000`99275f00 fffff801`886c2462 : fffff801`88708c38 ffffd000`99276ec8 ffffd000`99277660 00000000`00000000 : nt!_C_specific_handler+0x86
ffffd000`99275f70 fffff800`835d5eed : 00000000`00000000 ffffd000`992760d0 ffffd000`99276ec8 00000000`00000000 : Ntfs!_GSHandlerCheck_SEH+0x76
ffffd000`99275fa0 fffff800`8353cb25 : 00000000`00000001 fffff801`886b7000 ffffd000`99276e00 ffffd000`00000000 : nt!RtlpExecuteHandlerForException+0xd
ffffd000`99275fd0 fffff800`83540ede : ffffd000`99276ec8 ffffd000`99276bd0 ffffd000`99276ec8 ffffc000`e7ee2b00 : nt!RtlDispatchException+0x1a5
ffffd000`992766a0 fffff800`835da5c2 : 00000000`00000011 00000000`82d45801 00000000`00000000 fffff800`834e8897 : nt!KiDispatchException+0x646
ffffd000`99276d90 fffff800`835d8347 : 00000000`00000008 00000000`00000000 ffffb001`a021a000 00000000`00000000 : nt!KiExceptionDispatch+0xc2
ffffd000`99276f70 fffff801`88771031 : ffffd000`992773c0 00000000`00000058 00000000`057d9800 fffff801`88770fac : nt!KiInvalidOpcodeFault+0x107 (TrapFrame @ ffffd000`99276f70)
ffffd000`99277100 fffff801`8879469b : 00000000`00000000 ffffd000`99277690 00000000`00000000 00000000`057d9800 : Ntfs!NtfsChangeAttributeSize+0x85
ffffd000`99277150 fffff801`886c7096 : 00000000`00000000 ffffd000`99277690 ffffe000`82bdfde8 ffffe000`8231c5f0 : Ntfs!NtfsChangeAttributeValue+0x4ff
ffffd000`99277350 fffff801`886cef02 : 00000000`00000000 ffffc000`e7ee2c30 00000000`00000000 ffffc000`e7ee2c00 : Ntfs!NtfsAddAllocationForResidentWrite+0x106
ffffd000`99277450 fffff801`886d01cc : ffffe000`82bdfde8 00000000`00000001 ffffd000`992776a8 00000000`00000000 : Ntfs!NtfsCommonWrite+0x270a
ffffd000`99277660 fffff800`83af7911 : ffffe000`81e8a760 ffffe000`81e8a760 00000000`00000002 ffffe000`827e3dd0 : Ntfs!NtfsFsdWrite+0x1dc
ffffd000`99277720 fffff801`88423cf8 : ffffe000`8151ed00 ffffd000`992777c0 [COLOR=#800080]ffffe000`81e8a760[/COLOR] ffffe000`827e3dd0 : nt!IovCallDriver+0x3cd
ffffd000`99277770 fffff801`884220b6 : ffffe000`80ffb040 00000000`00000002 ffffe000`81e8a760 ffffe000`80ffc030 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x258
ffffd000`99277810 fffff800`83af7911 : ffffe000`81e8a760 00000000`00000002 ffffe000`8151edf0 ffffe000`81fe5e00 : fltmgr!FltpDispatch+0xb6
ffffd000`99277870 fffff800`83826f08 : 00000000`00000001 ffffd000`99277941 ffffe000`81fe5e00 ffffe000`82acbea0 : nt!IovCallDriver+0x3cd
ffffd000`992778c0 fffff800`8389b782 : ffffe000`81fe5e00 ffffd000`99277b80 00000000`00000000 ffffe000`81e8a760 : nt!IopSynchronousServiceTail+0x170
ffffd000`99277990 fffff800`835da1b3 : ffffe000`82d45880 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtWriteFile+0x682
ffffd000`99277a90 00000000`77b12352 : 00000000`77b11fff 00000023`77c1d5dc 00000000`00000023 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffd000`99277b00)
00000000`039df128 00000000`77b11fff : 00000023`77c1d5dc 00000000`00000023 00000000`00000000 00000000`0504f578 : wow64cpu!CpupSyscallStub+0x2
00000000`039df130 00000000`77b3219a : 00000000`00000000 00000000`77b11574 00000000`00000000 00000000`77b32380 : wow64cpu!ReadWriteFileFault+0x31
00000000`039df1e0 00000000`77b320d2 : 00000000`00000000 00000000`00000000 00000000`039dfd30 00000000`039df830 : wow64!RunCpuSimulation+0xa
00000000`039df230 00007ffc`326cbb3b : 00000000`00000000 00000000`77b31f60 00000000`00000000 00000000`00000000 : wow64!Wow64LdrpInitialize+0x172
00000000`039df770 00007ffc`326cba1e : 00000000`039df830 00000000`00000000 00000000`7ffdf000 00000000`00000000 : ntdll!_LdrpInitialize+0xcb
00000000`039df7e0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!LdrInitializeThunk+0xe

//The file object being accessed was related to utorrent, a data file

0: kd> !fileobj ffffe00081fe5e00

\Users\MSW\AppData\Roaming\uTorrent\updates.dat

LockOperation Set  Device Object: 0xffffe00080f65060   \Driver\volmgr
Vpb: 0xffffe00080f63230
Access: Read Write SharedRead SharedWrite 

Flags:  0x40062
    Synchronous IO
    Sequential Only
    Cache Supported
    Handle Created

File Object is currently busy and has 0 waiters.

FsContext: 0xffffc000e7ee2c30    FsContext2: 0xffffc000e7ee2e50
CurrentByteOffset: 0
Cache Data:
  Section Object Pointers: ffffe0008231c608
  Shared Cache Map: ffffe00082eba770         File Offset: 0 in VACB number 0
  Data at offset 0 not mapped

File object extension is at ffffe00081b464b0:

/*The device object that represents a file system volume is mapped to a device object that represents a physical device
The actual device is Bitlocker. The strange part is that the pointers were passed correctly, and the operation was fine to complete. The issue appears to stem from corruption of code where the operation was initiated, hence the invalid opcode fault*/

0: kd> !devstack ffffe00080f65060
  !DevObj           !DrvObj            !DevExt           ObjectName
  ffffe00080f6e290  \Driver\volsnap    ffffe00080f6e3e0  
  ffffe00080f6d030  \Driver\fvevol     ffffe00080f6d180  
> ffffe00080f65060  \Driver\volmgr     ffffe00080f651b0  HarddiskVolume1
!DevNode ffffe00080f6b970 :
  DeviceInst is "STORAGE\Volume\{fa1da5c2-b9a5-11e4-824f-806e6f6e6963}#0000000000100000"
  ServiceName is "volsnap"

/* Again, the corruption is on the 8th and 16th bit of an address, and the 8th bit of 3 more addresses. It's consistently this pattern, yet obviously, the addresses are different. */

0: kd> !chkimg -lo 50 -db !Ntfs
6 errors : !Ntfs (fffff80188771027-fffff80188806037)
fffff80188771020  00  b0  01  48  8b  5c  24 *51  48  8b  6c  24  58  48  8b *75 ...H.\$QH.l$XH.u
...
fffff80188806010  04  00  01  00  00  74  1b *4c  8b  42  50  f0  ff  48  3c *4c .....t.L.BP..H<L
fffff80188806020  8b  4a  50  f0  ff  49  40 *74  09  48  8b  4a  50  e8  d2  c7 .JP..I@t.H.JP...
fffff80188806030  fb  ff  48  8d  43  08  48 *8a  10  48  8b  48  08  48  39  42 ..H.C.H..H.H.H9B

//The addresses accessing the corrupt memory occurred once, on boot by the file system, so it's highly unlikely any code corrupted it.

Searching PFNs in range 0000000000000001 - 000000000021EFFF for [FFFFFFFFFFF6AFF0 - FFFFF00310F7705E]

Pfn              Offset   Hit              Va               Pte              
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Search done.

 

[softwaremaniac]

So, my initial suspicions were right.

 

[STAR4ONE]

Right il find a set that (def) works and then give it a test.

 

[STAR4ONE]

A related question, how would memtest not pick up the problem?

 

[Mysers Briggs]

More than likely.
Do bear in mind that memory corrution doesn't necessarily mean bad RAM, poor programming code can easily cause such issues.
Without a large memory dump, its very difficult to say because you don't have much to go on.
Due to the consistency of the error in specific memory allocations, it's more than likely bad RAM.
Especially given that this thread is executing on boot.

 

[STAR4ONE]

Hi

Another complete memory dump file.

https://drive.google.com/file/d/0B098Mml2C1ycOGJsVXptYVdTVFE/view?usp=sharing

 

[STAR4ONE]

Hi

So I used my old 4GB memory set and I had no errors, my friend using the suspected bad memory had his pc fail on him repeatedly( first time ever). My question is, could the voltage rating on the memory be an issue. The suspected bad RAM is 1.5V, the set my friend used before and I am using now are both 1.65 V. Could there be an issue?

 

[STAR4ONE]

Hi
I replaced the problematic RAM, with 1600 DDR3 1.5V Corsair units Vengence units and the blue screen issue returned. I tried enabling and disabling the XMP mem. profile and made sure to run at 1.5V. Still no joy. Can the increase from 4 to 8 gigs be drawing too much power? Coudl there be a physical defect in the RAM slots on my MB?

Any idea of where to start looking would be appreciated

 

[softwaremaniac]

Too much power draw is highly unlikely. You have a 750 Ti and it draws little power, so you should be fine. I'd suspect a faulty MB then, yes. Test the new RAM in another computer to make sure.