Solved Not necessarily a BSOD crash but..

[Vir Gnarus]

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.

 

[Hisophonic]

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

 

[Hisophonic]

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.

 

[Vir Gnarus]

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.

 

[Hisophonic]

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

 

[Vir Gnarus]

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

 

[Hisophonic]

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?

 

[Vir Gnarus]

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.

 

[Hisophonic]

Update: it seems to have done it again will post the crash dumps after i run driver verifier

 

[Vir Gnarus]

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.

 

[Hisophonic]

The snakeeyes.sys was actually my Corsair mouse, driver needed updating.
As for the second one ive only encountered it once but it seems to be a one off, though im still on edge with these crashes and deadlocks.

 

[Vir Gnarus]

I'm really returning back to my regular suspicion about this being either a CPU/PSU/Mobo issue. Have you tried Prime95 yet? Also, IBT is also a good test for the CPU and doesn't have to run nearly as long. Again, just make sure for both tests that you're watching CPU temps. If crashing occurs during either test, send us the crashdump. If deadlocking occurs and you can reproduce it from one of the tests, then it's a surefire sign one of those three parts are responsible.

 

[Hisophonic]

I replaced my PSU from the original i had to a CorsId 600M and my Mobo was deemed not faulty after i sent it for RMA.
Not tried Prime95 yet since i am mostly away from the computer.
I also tried intel burn in test for at least 2 hours will try it again though

 

[Vir Gnarus]

I have doubts about your mobo's manufacturer and their position on this. There have been previous instances where people sent their mobo's in, came up "clean", but still caused problems. Take what they say with a grain of salt.

Your best option right now is to provide a Driver Verifier induced crashdump and send the minidump so I can see if the kernel dump's worth looking at, or if you want just send the kernel dump straight away.

 

[Hisophonic]

Thing is the company that did the RMA was Scan, and yeah that's what ive been trying to do but it hasn't locked up yet, only experienced a BSOD with wdf.. sys which is related to MotionJoy.

I'll give it a try but not sure if the crash dump will be saved or produce one if it deadlocks because i have to hard reset it, after the hard reset the computer acts like it was just turned off normally well with the exception of the "start windows normally screen".

I heard this "fixes" the deadlock issue but im still unsure
http://support.microsoft.com/kb/2575077

Either way it happens during installation of anything really or downloading which i did a few today and the day before, it seemed that sorted it but yeah grain of salt.

Short little update:
Was playing music via Chrome and installing something on and then i heard a somewhat long "bzzzt" noise but i think the noise sounds different depending on the music played.
It didn't freeze though...

Just to ask, where would i find a kernel dump or generate one?

 

[Vir Gnarus]

So the deadlocking is gone, but just BSODs? Also, motionjoy driver has a bad history of BSODs that we've had to deal with, it may be necessary to remove it.

The kernel dump is MEMORY.DMP and is located in your Windows directory. It's a larger copy of the minidump that the minidump is derived from. It will only be one file, and will be replaced with each BSOD, so best thing to do is make sure the BSOD we get is relevant with the minidump, then we can snag the kernel dump for a closer look.

 

[Hisophonic]

I'm not entirely sure the deadlocking is gone since im away from the computer on most days, during installations i do hear a "bzzt" noise relevant to the song playing but no deadlocks or freezes.
As far as im aware it may still do it but without me there so im still on the edge.

 

[Hisophonic]

I thought the crashes were gone except they appeared again on a new HDD

 

[Vir Gnarus]

I'm not entirely sure the deadlocking is gone since im away from the computer on most days, during installations i do hear a "bzzt" noise relevant to the song playing but no deadlocks or freezes.
As far as im aware it may still do it but without me there so im still on the edge.

Well I can tell you if your system deadlocks, it will lock up and will not recover, so you'll return to a frozen system.

So what we have now are crashes and the 'bzzt' sound. On the new HD, did you install a new Windows or just imaged everything from the old drive onto the new?

 

[Hisophonic]

A new fresh install of windows which it happened 2 times.