Not necessarily a BSOD crash but..

So no mouse movement either? If that's the case, then it sounds like a deadlock of some kind. It can't be an application or service, it is far more likely a driver or hardware issue.

I know Driver Verifier has deadlock detection in it, but it's fairly rudimentary, nevertheless it along with the other driver checks might give us the edge on this. Before your turn it on, though, it's best to run through your hardware and update drivers, firmware and BIOS for em. That way it's far less likely for us to hit a false positive from Driver Verifier. Make sure to read the entire article carefully.

Well i ran it and it BSOD but it didn't tell me which driver was it

I ran WhoCrashed to find out what the BSOD said and:

On Fri 28/06/2013 18:53:56 GMT your computer crashed
crash dump file: C:\Windows\Minidump\062813-20701-01.dmp
This was probably caused by the following module: dtsoftbus01.sys (dtsoftbus01+0x1324)
Bugcheck code: 0xC9 (0x23E, 0xFFFFF8800187C324, 0xFFFFF98004B3AE10, 0x0)
Error: DRIVER_VERIFIER_IOMANAGER_VIOLATION
file path: C:\Windows\system32\drivers\dtsoftbus01.sys
product: DAEMON Tools
company: DT Soft Ltd
description: DAEMON Tools Virtual Bus Driver
Bug check description: This is the bug check code for all Driver Verifier
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
A third party driver was identified as the probable root cause of this system error. It is suggested you look for an update for the following driver: dtsoftbus01.sys (DAEMON Tools Virtual Bus Driver, DT Soft Ltd).
Google query: DT Soft Ltd DRIVER_VERIFIER_IOMANAGER_VIOLATION

On Fri 28/06/2013 18:53:56 GMT your computer crashed
crash dump file: C:\Windows\memory.dmp
This was probably caused by the following module: pxhlpa64.sys (PxHlpa64+0x35DD)
Bugcheck code: 0xC9 (0x23E, 0xFFFFF8800187C324, 0xFFFFF98004B3AE10, 0x0)
Error: DRIVER_VERIFIER_IOMANAGER_VIOLATION
file path: C:\Windows\system32\drivers\pxhlpa64.sys
product: PxHelp64
company: Rovi Corporation
description: Px Engine Device Driver for 64-bit Windows
Bug check description: This is the bug check code for all Driver Verifier
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
A third party driver was identified as the probable root cause of this system error. It is suggested you look for an update for the following driver: pxhlpa64.sys (Px Engine Device Driver for 64-bit Windows, Rovi Corporation).
Google query: Rovi Corporation DRIVER_VERIFIER_IOMANAGER_VIOLATION

Also this:

BCCode: c9
BCP1: 000000000000023E
BCP2: FFFFF8800187C324
BCP3: FFFFF98004B3AE10
BCP4: 0000000000000000
OS Version: 6_1_7601
Service Pack: 1_0
Product: 256_1

Quick Update:
After a few days of testing i have encountered anymore spontaneous crashing, more so it might be closely related to the RAM so im going to RMA it in a few days time.

Hmm, RAM issues shouldn't really be causing deadlocks like what you're experiencing, it's far more likely that something else is involved. Nevertheless, if you want to do some more hardware checking, here's some other tests to run through:

RAM: Memtest86+ - 7+ passes (1 pass = all tests 1x)
CPU: Prime95 - Torture Test; Blend; overnight (9+ hours)

All of these are included in the UBCD if you prefer a Live CD environment (which is the best environment to test hardware on). Also, please provide us temps/voltages using HWInfo with Sensors only option checked. Log two 30-minute instances: one for idle, and one for high load. If you can get the system to crash during high load logging, that's even better. Last, make sure that when running Prime95 that you check temps during first 30minutes or so to see if temps are stable. Prime95 runs very hot so be sure your cooling can handle it before letting it run extensively.

Oh, and if you want, on the UBCD under Peripherals there's a Video Memory Tester, if you wanna try that out go ahead.



Btw, the two bugchecks from Driver Verifier are caused by you checking the "Force Pending I/O Requests" option, which causes false positives. If you want, run Driver Verifier without this check. Oh, and when you do get crashes, send us a BSOD report, especially the crashdumps so we can look at it ourselves.

I'll probably run those tests tomorrow specially Memtest86+ i only ran it for 3 passes on the 16GB sticks no problem occurred.
Prime95 sounds like a good idea i mean im pretty sure my system is stable but this will probably decide it.
Ah i might run the Driver Verifier again and untick that see what happens

You'll want to run one stick at a time for Memtest. Remove all but one stick, run a couple passes, rinse and repeat.

Vir Gnarus said:

You'll want to run one stick at a time for Memtest. Remove all but one stick, run a couple passes, rinse and repeat.

So 7 passes for each stick? or less?

If you want 7 passes go ahead, that's usually the recommended amount. If you want to shorten it down to a few like 3/4 passes that's fine too. Again, my suspicion doesn't lie on the RAM right now, but we're testing it anyways as a just-in-case.

The one crashdump without DV showed up SnakeEyes driver. I really don't know what this is for, I've been looking for what it could be but closest I could find is some Razer product that was actually an April Fool's thing. If you have a better idea what it is I'd like to hear it. Anyways, it's dated March 2012, so see if there's an update or anything for it.

The other crashdump with DV is inconclusive. I will need at least a kernel dump for that crash to determine cause. If you've crashed since then, MEMORY.DMP would've already been overwritten so don't bother.

I say let Driver Verifier crash system again and make a copy of the resulting kernel dump. If I find that it's identical to this one, I'll request that you send the dump over.