Random BSODs while using computer

For 3 days now I have been getting random blue screens (photos attached in BSOD.zip), all related to RAM. Today after a crash I ran a 1-hour long Memtest86+ and found absolutely nothing wrong (completed the whole process twice). Thought it may be the HDD and pagefile (why not :) ) and ran a chkdsk, nothing wrong. At first, I crashed only while compiling in Visual Studio (Ultimate 2013) and it happened 30 minutes or 5 hours after beginning to code. Having seen other's PCs crash due to compiling (not VS necessarily), I did not worry. Just now I had a crash and I hadn't even started VS in this session, which was a troubling thing. I really can't put my finger on it. Any ideas?

Getting a few mixed responses.

Code:

BugCheck 1A, {41790, fffffa800232a460, ffff, 0}

Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+35084 )

I'm seeing Page Table Entry corruption, most likely drivers.
Here's why:

The 1st parameter indicates page table entry corruption.
The 2nd parameter is the address for the Page Frame Number that represents the corrupted page table.
The 3rd parameter contains the amount of page table entries in use at the time of the crash.

Code:

1: kd> dt nt!_MMPFN fffffa800232a460
   +0x000 u1               : <unnamed-tag>
   +0x008 u2               : <unnamed-tag>
   +0x010 PteAddress       : 0xfffff6fb`40000ed8 _MMPTE
   +0x010 VolatilePteAddress : 0xfffff6fb`40000ed8 Void
   +0x010 Lock             : 0n1073745624
   +0x010 PteLong          : 0xfffff6fb`40000ed8
   +0x018 u3               : <unnamed-tag>
   +0x01c UsedPageTableEntries : 0xffff
   +0x01e VaType           : 0 ''
   +0x01f ViewCount        : 0 ''
   +0x020 OriginalPte      : _MMPTE
   +0x020 AweReferenceCount : 0n128
   +0x028 u4               : <unnamed-tag>

Indeed the 3rd parameter was correct, in fact there are less than zero page table entries which is most likely caused by a driver calling the MmUnlockPages function too many time which causes physical pages to be unlocked.

However, on the other hand you are also getting Working Set page corruption which is mainly caused by bad RAM.

Code:

1: kd> !wsle 2

Working Set @ fffff70001080000
    FirstFree     289f  FirstDynamic        5
    LastEntry     289e  NextSlot            5  LastInitialized     296e
    NonDirect        0  HashTable           0  HashTableSize          0

Reading the WSLE data ......Unable to get Wsle table block - address fffff70001081088 - count 1024 - page 0x180

Lets take a quick look at the raw stack...

Hmm a few I/O routines and Interrupts.

Avast is causing issues.

Code:

Unable to load image \SystemRoot\system32\drivers\aswMonFlt.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for aswMonFlt.sys
*** ERROR: Module load completed but symbols could not be loaded for aswMonFlt.sys
 aswMonFlt+0x2155

Remove it using the removal tool

I'd give Memtest86 a try as well.

Memtest86 will test your RAM

   Information

Run Memtest86 for at least 8 passes so we get enough information to confirm that your RAM isn't failing

Lastly I noticed you had this installed...

Code:

DAEMON Tools Pro Agent	"c:\program files (x86)\daemon tools pro\dtagent.exe" -autorun	DAVID-PC\DAVID	HKU\S-1-5-21-274158315-4080150620-116267909-1000\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Daemon Tools/Alcohol is known cause of BSODs.

Registry and SPTD problems | DAEMON Pro Help
How to remove sptd.sys from system

1. Uninstall Daemon Tools.
2. Download the SPTD standalone installer and follow these steps:
3. Double click the executable to open it
4. Click the button shown below



If the button it is grayed out, as shown in the image, there is no more SPTD installation on your system, and you can just close the window.


Free your startup, remove all unnecessary programs from launching when you first login.

Startup Programs - Change

Post back the results.

Ok it seems that it was Daemon tools after all because since I reinstalled it with Revo Uninstaller my PC hasn't crashed yet. Regarding memtest, it found nothing, so I can only assume that the crashes were software-related. Thank you for posting such a comprehensive analysis :)