Windows 10: "Your PC encountered a problem and needs to restart." - Round 2.

I downloaded and used that tool, but there were some parts of my computer that both it and Speccy couldn't find any information about (cooler, power supply, etc). I had to do some online research for the rest. I have now updated the information here on TenForums, using all of the information that I was able to find.

 

Let's see if there may be a driver issue






Diagnostic Test

DRIVER VERIFIER


Warning Please make a backup of your important files and get your rescue media or create one.
Please create a restore point.
Please follow this tutorial to run driver verifier.

Driver verifier stresses your drivers and will crash your pc if any driver fails due to a violation.

Driver verifier should be performed for a max of 48 hours, or when you have a bluescreen, whatever comes first.

If driver verifier has found a violation and you can't get back into windows normally, try to boot into safe mode and reset in safe mode driver verifier, or in the troubleshooting options open command prompt and type verifier /reset.



Note Your system will act very sluggishly while driver verifier is enabled, this is normal as your drivers will be being subjected to heavy testing in order to make them crash.

 

Warning Please make a backup of your important files and get your rescue media or create one.
Please create a restore point.
Please follow this tutorial to run driver verifier.

It will be at least several days (possibly longer) before I'm able to do that. I'll provide you with any updates.

 

No problem, I have the time to wait *Smile

 

I went through the process to use Driver Verifier described in the tutorial that you linked to (Part 1 - Option 1, then Part 2, including the restart), but I am not noticing any sluggishness on my computer. Might it be that Driver Verifier isn't working (possibly the reboot didn't cause it to kick on)?

Is there any way that I can tell for certain whether it's running (such as an item in my Task Manager)?

 

Some settings in driver verifier require the system to reboot for it to be enabled, if you don't reboot the system those settings won't be used whilst running driver verifier.

It happens from time to time that no sluggishness isn't noticed.

In an admin command prompt, run following command to see the status of driver verifier.
Code: verifier /query[/quote]

 

But (as I mentioned in my last post), I did restart my computer after applying the settings.

[/quote]
I've now done that. I have the result that the command prompt showed me attached as a text file below. Does this information confirm that Driver Verifier is indeed running?

Attachment 133590

 

It was only an explanation why driver verifier needs to be restarted, nothing else *Smile

Driver verifier is running on your system. If driver verifier wasn't running you wouldn't get this kind of information
Code: Raise IRQLs: 861860 Acquire Spin Locks: 6822007 Synchronize Executions: 4 Trims: 0 Pool Allocations Attempted: 17556682 Pool Allocations Succeeded: 17556682 Pool Allocations Succeeded SpecialPool: 915 Pool Allocations With No Tag: 24 Pool Allocations Not Tracked: 0 Pool Allocations Failed: 0 Pool Allocations Failed Deliberately: 0[/quote]

 

[/quote] Ah, that's good. The 48 hours will be over at 8:57 PM tomorrow night, so I should report back shortly after that (if I don't get a BSOD first).

 

Well, I have now run Driver Verifier for over 48 hours. It ran without incident. There were no BSODs. Right before I turned Driver Verifier off, I saved the information from Command Prompt again. Here's a text file of it:

Attachment 133883

 

Partly good *Smile

Going back a bit to the hardware tests, did you run the hard disk tests on all your hard drives or partitions?
I just went through the event logs a bit, there is an unbelievable large amount of issues with multiple disks spread over months.

The day this thread was created, a large amount of event logs like these were created
Code: Event[10497]: Log Name: System Source: disk Date: 2017-03-08T01:50:00.872 Event ID: 153 Task: N/A Level: Warning Opcode: N/A Keyword: Classic User: N/A User Name: N/A Computer: DESKTOP-AVBIS4C Description: The IO operation at logical block address 0x1ecc9fb0 for Disk 3 (PDO name: \Device\0000004f) was retried. Event[10515]: Log Name: System Source: disk Date: 2017-03-08T01:50:36.038 Event ID: 51 Task: N/A Level: Warning Opcode: N/A Keyword: Classic User: N/A User Name: N/A Computer: DESKTOP-AVBIS4C Description: An error was detected on device \Device\Harddisk3\DR3 during a paging operation.[/quote] Almost 2 months earlier, the same
Code: Event[8063]: Log Name: System Source: disk Date: 2017-01-31T01:12:13.851 Event ID: 153 Task: N/A Level: Warning Opcode: N/A Keyword: Classic User: N/A User Name: N/A Computer: DESKTOP-AVBIS4C Description: The IO operation at logical block address 0x137d5000 for Disk 3 (PDO name: \Device\0000004d) was retried. Event[6421]: Log Name: System Source: disk Date: 2017-01-16T16:24:57.552 Event ID: 51 Task: N/A Level: Warning Opcode: N/A Keyword: Classic User: N/A User Name: N/A Computer: DESKTOP-AVBIS4C Description: An error was detected on device \Device\Harddisk2\DR2 during a paging operation.[/quote]

 

No. As my C drive is the only one that necessary for the computer to function correctly, I only tested it. I've run rudimentary tests on my other drives, but nothing advanced.

The two hard drives listed as having problems in those reports (Disk 2 and Disk 3) are both external drives (neither of which is necessary for my computer to run correctly). Disk 3 is an ancient external Western Digital drive that I use only as a backup and which showed me some warnings in a hard drive test long ago. I already knew that it likely had issues.

Disk 2 is an internal SATA drive placed in an external USB enclosure (also used as a backup). I had to replace said enclosure, as it was faulty and kept causing (non-dangerous to my system) errors (hence the read errors on Disk 2). All of those error reports for Disk 2 are from times when I had a faulty hard drive enclosure.

 

Glad you explained it *Smile


Another 'going back to', this time because I'm having some issues with gathering information about the crashes to find some patterns.

What you're trying to do is exactly what the BSOD is meant to do, preventing OS corruption and/or personal data corruption.
The BSOD occurs when it sees that something is breaking rules in the kernel, it saves the data in the RAM so others can have a look at it and safely shuts down the system to prevent (further) corruption. In certain crashes there is already corruption, it is only caught when the corruption is being accessed, but userdata corruption and OS corruption is rare to occur.
The crashes do not cause any damage to the system, if they somehow do then there is an entirely different problem with the OS since the crashes are meant to protect your system.

The risk of important data being removed when restoring to a date before the system crashes is quite high, I ask you to not do this anymore while troubleshooting.

 

I see. I had thought that since I saved the information each individual crash, all needed data would be preserved. I hadn't thought about the possibility of detecting patterns over multiple crash dumps at the time.

 

I noticed 0x124 crashes, they are mostly solved by patterns. The 0x124 minidumps mainly save the reason why a BSOD was called but not the cause. With patterns we can identify possibilities for causes and solutions to resolve the crashes.