Well, the most load increase it could have, would be during the moments that I play games. But it actually never does that while I play games, so I don't think it's the PSU either.
If the problem occurs again, I'll try a clean boot and see what happens.
The point is to demonstrate whether it does occur when you have done a clean boot and left it in that state for 'long enough'.
What you are trying to do is to correlate the problem with some software, and demonstrate it's not hardware-related.
Right, so, I'm using a clean boot at the moment. I'll see if something wrong happens. How much long should I use the clean boot for?
How long is a piece of string? You know how often your PC crashes- so you'd need to wait sufficiently long to gain some confidence it's behaving similarly or differently...
The question to answer is: does being in clean boot make a difference?
I see. So, 7 days it is
- - - Updated - - -
So, during the first day with a clean boot everything was 100% fine. Today (second day) happened twice already. What do you think?
EDIT: As I tried to update this post, it happened again. So, I don't know what's wrong with it... Any opinions?
If I have it right- Safe Mode- no crashes, clean boot, crashes?
Assuming that's consistently true, two significant differences occur to me- in Safe Mode you're loading drivers which are different in some cases (e.g. graphics) and not loading others at all, and not loading some services. With a clean boot, you're loading normal drivers and services, and not starting a number of programs.
Normal mode also uses more RAM.
It's disappointing there's apparently no diagnostic report in Reliability History or the Event Viewer, but I suppose that depends exactly how the crash occurs- perhaps no time to write one. If there isn't anything reported, articles like this:
https://www.howtogeek.com/222730/how...shed-or-froze/
can't help you.
Programs like appcrashview, bluescreenview, or these
from
WinCrashReport v1.25
WinCrashReport provides an alternative to the built-in crash reporting program of Windows operating system. When application crashes in your system and Windows displays the internal crash window of the operating system, you can run WinCrashReport, and get extensive report about the crashed application. The crash report of WinCrashReport is displayed as simple text or in HTML, and includes the following information: Crash memory address, Exception code, Exception description, Strings found in the stack, call stack, processor registers, modules list, threads list, and more...WhatIsHang v1.27
Sometimes, a Windows software hangs, the user interface doesn't respond anymore, and you cannot find out what is cause of the problem. This utility tries to detect the software that is currently hang, and displays some information that may allow you to understand what exactly cause the software to hang. Most of the information displayed in the report of WhatIsHang, like Call Stack, Stack Data, Processor Registers, and Memory Data, is designed for users with Windows programming knowledge. However, WhatIsHang also displays a list of strings and dll files related to the hang problem, which can also help users without programming knowledge to understand the cause of the problem.
Freeware Tools and System Utilities for Windows
rely on Windows reporting something- feel free to try them.
Similarly
Resplendence Software - WhoCrashed, automatic crash dump analyzer
Assuming that means it's not a hardware problem, you're left- as far as I can see- with a process of elimination.
If you don't already have one. make sure you have a current disk image which you can restore, as you're going to make a lot of changes in the hope of identifying the cause. You'll need that to restore your system to 'as is' after having done that. E.g. use Macrium Reflect (free) + external storage for images.
Now you have a system you can hack.
Start by recording everything relevant- the current state.
Get a copy of Autoruns (free from MS).
This gives you access to anything starting- from programs to drivers.
Save a copy for reference. (disk save icon almost top right).
Do this both in Safe Mode and Normal Mode- print both so you can see them side by side.
Now you can start to uninstall programs and change startups in whatever order you think best, based on the difference in the above.
Be somewhat careful with Autoruns- don't disable anything MS related.
As you will have to leave the system for 'long enough' to see if it doesn't crash- frustrating- I suggest you uninstall and change a lot of things, then leave it, to see if there's any change, then work back from there.
You can uninstall (and delete) your graphics driver, or maybe work out how to stop it loading in Autoruns.
When doing that with drivers, you may have to disconnect your internet connection to prevent it being downloaded.
There's nothing easy about that.. someone else may have a bright idea, of course.
if its an amd system. some hardware monitoring software will cause this weird shutdown.
Good enough place to start- remove any manufacturer diagnostic or monitoring tools, and any 3rd party tools of that kind.
So, in the clean boot I wasn't even using nvidia drivers or anything. I don't know if any 3rd party drivers were still on (even Steam was off). I also had Wallpaper Engine on, but I've test it in the past and the problem happens even without it.
As for monitoring software, I've uninstalled CpuZ and EVGA Precision (though the second one was through Steam and it was never open. As for the first one, I only opened it once or twice and had no problem with it).
I don't think I have anything else when it comes to monitoring Software.
As for non MS drivers, I don't think that I had anything in the clean boot that I didn't have befofe the problem appears. Plus, I disabled everything during the clean boot, just in case.
However, as you suggested, I need to check some drivers/autoruns. It may appear that it's something about a 3rd party app, or even the OS itself (which is a problem).
A clean boot does not change the drivers loaded if you did this:
Perform a Clean Boot in Windows 10 to Troubleshoot Software Conflicts
Quote
