NEW asus system COMPLETE random bsod

[znikotine]

I hope when Vir will be back,

i hope wherever he is, he comes back soon

 

[znikotine]

i have also been running memtest86 version 4.20 for about 20 hours now i got 8 passes and o fails 0 errors... does this rule out ram as the possible problem?

 

[Arc]

Hopefully. Have you tasted it in each slot, each module?

 

[znikotine]

Hopefully. Have you tasted it in each slot, each module?

no how should it be tested one stick at a time in each slot??

if so that would take days.....im fine doing this how many passes should i get on each stick in each slot to feel comfortable?

 

[Arc]

Remove the RAM modules. Place one in one slot, do memtest. Then same stick another slot ....

when done, take another ram module, do the same process.

 

[znikotine]

Remove the RAM modules. Place one in one slot, do memtest. Then same stick another slot ....

when done, take another ram module, do the same process.

ok gotcha ill run through that and wait for VIR hopefully he can weigh in again.

 

[znikotine]

3 passes on first dimm slot with the first module
3 passes on the second dimm slot with the first module

now im gonna test the other module......anyone know if vir is gone or just otherwise indisposed

 

[znikotine]

2 passes on the first slot with the second module
2 passes on the second slot with the second module

hopefully this will rule out the ram

 

[znikotine]

vir you had some good tips WHERE did you go ?!??!?!?! ....... since this is a clients computer i guess if i cant get some help soon i am just gonna sell the board and start new,........ i appreciate the time and help i did recieve but i have been working on this for a week on the forum here and still no results.

 

[Vir Gnarus]

Sorry. Was in a Missions Conference. I'm back, though.

Just so you know, Driver Verifier does not function in safe mode, hence why you weren't having problems getting DV to run things in Safe Mode (because it wasn't active).

Bleh, it seems like Arc was on to something with the crashdump he saw. The error code that actually caused that crash was a c0000010, which means invalid operation for target device. It means Windows was trying to get the drive to do something, and the drive rejected it because it couldn't understand it. Unfortunately, without a kernel dump for this crash, I cannot figure out anything beyond this. The rest of the crashes are also rather vague without kernel dumps for them (including the manually initiated one you did, which is worthless without its kernel dump).

From what I'm seeing, though, are what appear to be some issues with crosstalk between your drive and your RAM. This means either the RAM is bad, the drive is bad, or the mobo is bad. Hardware tests are not showing up issues in RAM or disk, so I'm getting more and more suspicious of the motherboard. PSU problems can cause this as well, but we should not consider it at this point in time. This is not a driver/software issue, because if you're getting instability problems in Safe Mode as well, you have a hardware problem (or your Windows installation is corrupt and you have to reinstall Windows).

Unfortunately, this does sound like it's going to be a case of hardware swapping, and I'd start with the motherboard first, then drive, then RAM. It sucks having to go this route, but unless there's professionals around that can have the system hands-on in a lab environment, it's very difficult to ascertain bad hardware, especially if hardware tests are coming up short.

 

[Arc]

Bleh, it seems like Arc was on to something with the crashdump he saw. The error code that actually caused that crash was a c0000010, which means invalid operation for target device. It means Windows was trying to get the drive to do something, and the drive rejected it because it couldn't understand it.

I am sorry Vir
Still F4 is the hardest thing to understand, as far as I found

 

[Vir Gnarus]

That's all right, you are most likely correct in your suspicions of some kind of drive I/O failure (which was the case here). !analyze -v output is mostly sufficient with this crashdump, but minidumps for this don't really go beyond that. You just worked with what you had.

 

[znikotine]

Sorry. Was in a Missions Conference. I'm back, though.

Just so you know, Driver Verifier does not function in safe mode, hence why you weren't having problems getting DV to run things in Safe Mode (because it wasn't active).

Bleh, it seems like Arc was on to something with the crashdump he saw. The error code that actually caused that crash was a c0000010, which means invalid operation for target device. It means Windows was trying to get the drive to do something, and the drive rejected it because it couldn't understand it. Unfortunately, without a kernel dump for this crash, I cannot figure out anything beyond this. The rest of the crashes are also rather vague without kernel dumps for them (including the manually initiated one you did, which is worthless without its kernel dump).

From what I'm seeing, though, are what appear to be some issues with crosstalk between your drive and your RAM. This means either the RAM is bad, the drive is bad, or the mobo is bad. Hardware tests are not showing up issues in RAM or disk, so I'm getting more and more suspicious of the motherboard. PSU problems can cause this as well, but we should not consider it at this point in time. This is not a driver/software issue, because if you're getting instability problems in Safe Mode as well, you have a hardware problem (or your Windows installation is corrupt and you have to reinstall Windows).

Unfortunately, this does sound like it's going to be a case of hardware swapping, and I'd start with the motherboard first, then drive, then RAM. It sucks having to go this route, but unless there's professionals around that can have the system hands-on in a lab environment, it's very difficult to ascertain bad hardware, especially if hardware tests are coming up short.

thanks for the input i was thinking that i was gonna start having to swap hardware .... before i go that route will the kernel dump (which i assume is the memory.dmp) help?

or are we past that and in need of the hardware swap route

 

[Vir Gnarus]

I don't think so. Dump files can only give an educated guess at best when we're dealing with hardware failure. We've pinpointed it to having to do with some sort of drive I/O, and while that in itself involves a good number of hardware pieces, we can be sure that others like the video or network would not be related here. Unless you bring the kernel dump to a professional analyst (and pay beaucoup money for it), this is as far as we may be able to go, and I'm pretty confident even they won't be able to pinpoint it on just one piece of hardware.