Run the W10 built in Troubleshooter. Settings > Update & Security > Troubleshoot
https://i.imgur.com/usmqspd.gif
If that does not reveal the problem, use the online tool.
Troubleshoot blue screen errors
https://support.microsoft.com/en-us/...rs=en-US&ad=US
- - - Updated - - -
Remove each stick of ram/memory & tell me exactly what is marked on each.
The process of replacing Windows protected files is quite complicated and not risk free. I would not recommend attempting replacing Windows protected files manually because you may introduce serious security risks as there is no guarantee you can restore everything to the exact state it used to be without leaving your computer open to exposure of malware or anything. These files are protected for a reason and you should not ever meddle with the security around it, or you may risk malware injecting itself or replacing the file with a malicious copy should you get infected. You could consider it a tikking timebomb that is just waiting for someone to either fix the security problems or for someone to abuse the security.
Do not attempt it manually, SFC can do it for you without security risks.
Having said that, I have not yet looked at this thread but don't really have much time the coming few days.
In case you might be interested on the 0xEF, something I wrote about why 0xEF occurs and why it's not an easy bugcheck to debug.
The Special BSOD Reason: 0xEF and 0xF4 | Sysnative Forums
Can you link to the results of test results indicating the RAM is good? I've tried finding anything but came up empty.
Ahhhhhh I get it, well the RAM tested good and is fine. So I understand you correctly, tracking and nailing down this bug is about as easy trying find flea sh!t in a barrel of black pepper!?
You haven't replied to this.
"Remove each stick of ram/memory & tell me exactly what is marked on each"
The question I have is, is it really a software bug or hardware problem? With this 0xEF I want to ensure hardware is excluded as much as possible as a potential cause, there's not much of a point troubleshooting software problems when the hardware can corrupt software.
Pretty much yeah, 0xEF isn't easy. Theoretically it is possible to debug a 0xEF, but you would need to provide a full memory dump so we could look into data that isn't accessible with any other crash dump. The question I always ask myself is if it is really worth it and needed considering the size of the dump file. The answer is usually no, because the cause is found long before there are no other options.
What test did you use and how many passes? We have what you could say 'a standard' regarding memory testing, because history has proven that not following this standard means the memory hasn't been tested sufficiently.
What memory test d'ya want me to run?
Here is the memory: It is ALL a matched set of OCZ DDR3 RAM - they came in the same packet, 4x2Gb Modules.
This is the memory test I would like you to run, all important information is in the tutorial.
MemTest86+ - Test RAM
Quote
