NTOSKRNL.exe Blue Screen?

[CobaltFilms]

For the past month or so I've been getting BSODS about once a week. It is quite annoying and I would like to know the cause. I used Blue Screen View and it points to the driver NTOSKRNL.exe. I *believe* the problem is my RAM, but can anyone verify this?
I have run tests on the hard drive with no issues.

Blue Screen View:
http://gyazo.com/6fabdc9bcfef8ac3f1711709a13a22ff

DMP File:
https://mega.co.nz/#!lcAUBTqR!btHlA84J4vbXPOgAM4pgAl6_4lLN6hTOtzkhEX1tKQg
(copy and paste link)

If you need any more info let me know.

Thank You!

 

[xcrossroadsx]

The BSOD you got (0xF4) translates to critical_object_termination. This doesn't really tell much other than that some critical object (usually a process/service) has stopped responding/was killed, which in this case is NTOSKRNL.exe (this is the kernel executable for an NT OS). What we have to do is figure out what is the kernel executable to crash, normally a bad driver or piece of AV or similar software that uses kernel mode drivers. I am using windbg to look at the BSOD now, give me a few moments to get back to you.

Updates so far: Windbg is saying that the BSOD was probably caused by wininit.exe. Weird, since you are pointing out NTOSKRNL.exe.

So, after a bit more deliberation, it appears that some driver is causing the issue. Did you recently install or update any new hardware or software that uses drivers (such as anti virus software, disk management software, etc) by any chance?

 

[CobaltFilms]

The BSOD you got (0xF4) translates to critical_object_termination. This doesn't really tell much other than that some critical object (usually a process/service) has stopped responding/was killed, which in this case is NTOSKRNL.exe (this is the kernel executable for an NT OS). What we have to do is figure out what is the kernel executable to crash, normally a bad driver or piece of AV or similar software that uses kernel mode drivers. I am using windbg to look at the BSOD now, give me a few moments to get back to you.

Updates so far: Windbg is saying that the BSOD was probably caused by wininit.exe. Weird, since you are pointing out NTOSKRNL.exe.

So, after a bit more deliberation, it appears that some driver is causing the issue. Did you recently install or update any new hardware or software that uses drivers (such as anti virus software, disk management software, etc) by any chance?

Sorry for the late response..

Anyways, I don't believe so.. I can't really remember installing any drivers before the blue screen started. Should I update drivers that need updating?

Generally the only driver I can recall updating is my GPU with GeForce Expierience.
EDIT: Could it be this driver I installed? The blue screens started around 3-4 days after I installed it.
http://gyazo.com/9d3429fba0fdb8f234e0e6c7254dbacd

 

[johnbl]

ok, something modified a critical windows data structure, windows detected it and shutddown.
this can be cause by hardware, malware, or software driver bugs.
------------

you have WPRO_41_2001.sys installed
\SystemRoot\system32\drivers\WPRO_41_2001.sys Mon Nov 07 13:04:48 2011

most often it is used for packet modification for game cheating but sometimes indicates that malware is scanning packets on your system. Just make sure you know about it and want it.

so: i would do:
- a malwarebytes scan (i don't think you have malware)
- run memtest86.exe and confirm your memory is ok (i think it will be ok)
then run verifier.exe and set debugging flags on the third party drivers that you have installed
(I would suspect the cfosspeed6.sys is corrupting memory of other processes)
\SystemRoot\system32\DRIVERS\cfosspeed6.sys Wed May 29 09:47:24 2013
it is used for "packet shaping" or game cheating in MMO's

reboot with the verifier flags set and wait for the next blue screen. if it is a driver making a common mistake, it will bluescreen and name the driver. Best to change your memory dump to a full memory dump or at least a kernel memory dump to allow the proper debugging info to be saved to the memory dump

The BSOD you got (0xF4) translates to critical_object_termination. This doesn't really tell much other than that some critical object (usually a process/service) has stopped responding/was killed, which in this case is NTOSKRNL.exe (this is the kernel executable for an NT OS). What we have to do is figure out what is the kernel executable to crash, normally a bad driver or piece of AV or similar software that uses kernel mode drivers. I am using windbg to look at the BSOD now, give me a few moments to get back to you.

Updates so far: Windbg is saying that the BSOD was probably caused by wininit.exe. Weird, since you are pointing out NTOSKRNL.exe.

So, after a bit more deliberation, it appears that some driver is causing the issue. Did you recently install or update any new hardware or software that uses drivers (such as anti virus software, disk management software, etc) by any chance?

Sorry for the late response..

Anyways, I don't believe so.. I can't really remember installing any drivers before the blue screen started. Should I update drivers that need updating?

Generally the only driver I can recall updating is my GPU with GeForce Expierience.
EDIT: Could it be this driver I installed? The blue screens started around 3-4 days after I installed it.
http://gyazo.com/9d3429fba0fdb8f234e0e6c7254dbacd

 

[CobaltFilms]

ok, something modified a critical windows data structure, windows detected it and shutddown.
this can be cause by hardware, malware, or software driver bugs.
------------

you have WPRO_41_2001.sys installed
\SystemRoot\system32\drivers\WPRO_41_2001.sys Mon Nov 07 13:04:48 2011

most often it is used for packet modification for game cheating but sometimes indicates that malware is scanning packets on your system. Just make sure you know about it and want it.

so: i would do:
- a malwarebytes scan (i don't think you have malware)
- run memtest86.exe and confirm your memory is ok (i think it will be ok)
then run verifier.exe and set debugging flags on the third party drivers that you have installed
(I would suspect the cfosspeed6.sys is corrupting memory of other processes)
\SystemRoot\system32\DRIVERS\cfosspeed6.sys Wed May 29 09:47:24 2013
it is used for "packet shaping" or game cheating in MMO's

reboot with the verifier flags set and wait for the next blue screen. if it is a driver making a common mistake, it will bluescreen and name the driver. Best to change your memory dump to a full memory dump or at least a kernel memory dump to allow the proper debugging info to be saved to the memory dump

The BSOD you got (0xF4) translates to critical_object_termination. This doesn't really tell much other than that some critical object (usually a process/service) has stopped responding/was killed, which in this case is NTOSKRNL.exe (this is the kernel executable for an NT OS). What we have to do is figure out what is the kernel executable to crash, normally a bad driver or piece of AV or similar software that uses kernel mode drivers. I am using windbg to look at the BSOD now, give me a few moments to get back to you.

Updates so far: Windbg is saying that the BSOD was probably caused by wininit.exe. Weird, since you are pointing out NTOSKRNL.exe.

So, after a bit more deliberation, it appears that some driver is causing the issue. Did you recently install or update any new hardware or software that uses drivers (such as anti virus software, disk management software, etc) by any chance?

Sorry for the late response..

Anyways, I don't believe so.. I can't really remember installing any drivers before the blue screen started. Should I update drivers that need updating?

Generally the only driver I can recall updating is my GPU with GeForce Expierience.
EDIT: Could it be this driver I installed? The blue screens started around 3-4 days after I installed it.
http://gyazo.com/9d3429fba0fdb8f234e0e6c7254dbacd

-Ran malwarebytes, nothing detected.
-Ran memtest, no issues.
-So, I looked into csfosspeed6.sys and found it was related to a program I had installed (which came with my AsRock motherboard) XfastLan. I uninstalled it.
-For WPRO_41_2001.sys, I looked into it and it seems it is related to Intel Smart Connect (another thing that came with my motherboard)
Would this have done anything?

 

[johnbl]

the packet driver is old, likely to have bugs that will corrupt kernel memory. The only way to prove it would be to run verifier on the driver and catch it making mistakes. Problem is when you prove it as the cause the only thing you can do is update the driver. If you want to use it try to find the most current version before you start debugging it. Window networking has has updated to new standards and bug fixes these are automatically added via windows update. Problem is that these fixes can expose bugs in existing drivers that windows does not have the rights to update. End result is bugchecks until you remove or get the vendor to update the diver with a fix

 

[CobaltFilms]

the packet driver is old, likely to have bugs that will corrupt kernel memory. The only way to prove it would be to run verifier on the driver and catch it making mistakes. Problem is when you prove it as the cause the only thing you can do is update the driver. If you want to use it try to find the most current version before you start debugging it. Window networking has has updated to new standards and bug fixes these are automatically added via windows update. Problem is that these fixes can expose bugs in existing drivers that windows does not have the rights to update. End result is bugchecks until you remove or get the vendor to update the diver with a fix

Ok, I'm still a little confused on the whole verifier thing.
I ran it on the file, here is what verifier looks like now:
http://gyazo.com/cec7d1d39e703fb3a17a12cfc30f496d

 

[johnbl]

yep, you either run it on all drivers or selected drivers, then run your system until you get a bugcheck.
verifier will tell the system to track allocations and will put debugging info that will be stored in the memory dump.
You must select a kernel memory dump or full memory dump to not have the debugging info stripped out when the memory dump is saved to disk when you bugcheck the system. Your system will run slower until you turn off the verifiy flags

verifier.exe /reset will clear the flags, then reboot your system to turn off all the checking after you are done testing for failure. Verifier will also bugcheeck if the driver makes one of any number of common driver errors. It is to allow the system to stop right after the error is made rather than later when some random process is corrupted by the driver error.

the packet driver is old, likely to have bugs that will corrupt kernel memory. The only way to prove it would be to run verifier on the driver and catch it making mistakes. Problem is when you prove it as the cause the only thing you can do is update the driver. If you want to use it try to find the most current version before you start debugging it. Window networking has has updated to new standards and bug fixes these are automatically added via windows update. Problem is that these fixes can expose bugs in existing drivers that windows does not have the rights to update. End result is bugchecks until you remove or get the vendor to update the diver with a fix

Ok, I'm still a little confused on the whole verifier thing.
I ran it on the file, here is what verifier looks like now:
http://gyazo.com/cec7d1d39e703fb3a17a12cfc30f496d