Random Crash and Restart

[NoddyPirate]

And after reboot - just for the fun:

 

[NoddyPirate]

Yes agreed @Scott thanks! I've reduced the Undervolt back to what it was first time around.

In many reports I've read the 5600X has been able to handle the maximum undervolt available with the Curve Optimiser in BIOS - so I think I may have pushed my luck a bit by getting greedy recently.

We shall see!

A bit off the topic of this thread in some ways @Scott but I might ask for your knowledge of LLC?

My concern with the Undervolt was the likelihood of Vdroop getting excessive when some process called for increased power - causing the voltage to drop below usable limits before the system can adequately respond - leaving the CPU incapable of keeping up and causing the process to fail - leading to a crash.

I haven't played with LLC yet - as I believe it can result in excessive voltage spikes that might come with it as a load suddenly ceases - sort of the opposite of the above - and as excessive voltage worries more than insufficient voltage - I want to do a good bit more reading before I consider playing with it.

But I do understand that it can help alleviate the excessive VDroop that can come with undervolting - and more generally help keep the voltage delivered to the CPU more usable and stable for Overclocking.

Increasing the VRM phase switching frequency would seem to be in a similar camp but with less risk of the spiking that LLC might bring.

Any gen on your side worth sharing?

 

[ubuysa]

I'll have as scan of the cbs.log tomorrow. I'll also compare your list of UWP apps with mine to see what additional apps you have installed.

 

[NoddyPirate]

I'll have as scan of the cbs.log tomorrow. I'll also compare your list of UWP apps with mine to see what additional apps you have installed.

Again @ubuysa thank you so much - but please don't worry about time taken - I really appreciate your help and will wait however long it takes to get your analysis.

FWIW - I have had no further issues for the past 5.5 hours of continuous operation since reducing my UnderVolt. Early days yet of course, but I tentatively hope we may be moving out of - Phase 1 Panic Onset - and gradually entering the much longer - Phase 2 Change Impact Assessment - we shall see!

 

[ubuysa]

Again @ubuysa thank you so much - but please don't worry about time taken - I really appreciate your help and will wait however long it takes to get your analysis.

FWIW - I have had no further issues for the past 5.5 hours of continuous operation since reducing my UnderVolt. Early days yet of course, but I tentatively hope we may be moving out of - Phase 1 Panic Onset - and gradually entering the much longer - Phase 2 Change Impact Assessment - we shall see!

That's good news - assuming it was failing more frequently. I'm still staggered at how an overclock or undervolt can cause exactly the same failures each time? You'd expect variety of failures I'd have thought? Every day is a learning day.

Your CBS log contains nothing important. The only repair that was made was to the shortcut for OneDrive...

2021-04-19 17:10:15, Info                  CSI    000001ca [SR] Repairing file \??\C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\\OneDrive.lnk from store

....and that's not the cause of your problems!

I did look down your list of UWP apps and the main non-Microsoft apps that you have installed (which will have been installed manually) are these:

ArmouryCrate
AURACreator
HiddenCityMysteryofShadows
PrimeVideo
Cinebench
Netflix
iTunes
CanonInkjetPrintUtility
AdobeNotificationClient
NVIDIAControlPanel
1ED5AEA5.4160926B82DB (which research suggests is Angry Birds)
6918E89D.THECHESSLV.100 (which research suggests is a chess game)

If it turns out that this is a UWP issue rather than an overclock/undervolt issue then one of these apps is your most likely culprit I would have thought.

For now, I think it's essential to run without the undervolt and without any (non-PCS applied) overclock for a time. To figure out how long to run it for, estimate how long it would run before failing in the past and then multiply that by four. Run it at least that long to be sure. This will prove (or not) that it was the undervolt/overclock that was the cause of your crashes/restarts - obviously then you'll need to reapply those much more carefully and with longer real-world testing.

FWIW I've been back and taken a closer look at your system log, and found a WHEA error. WHEA is the Windows Hardware Error Architecture, it's involved whenever a hardware error is detected....



....that's a processor machine check error - that might suggest an issue with the undervolt perhaps?

Incidentally, all those BITS-Client errors are because you have more BITS jobs running than your job limit specifies.

 

[NoddyPirate]

I left the PC running for a few hours last night and no issues arose. So I think I’ll wait until I have had no critical events for the past 24 hours and I might reintroduce the Undervolt and see if the crashes recur.

I also flushed the Bits Client Job list - which was full of 60 Microsoft Outlook Offline Address Book entries - and the jobs list has remained at zero with no Bits Client events since. (EDIT - this was done mostly to calm my OCD which disliked the continuous string of entries in the event log, rather than because I thought it would help!)

 

[NoddyPirate]

That's good news - assuming it was failing more frequently. I'm still staggered at how an overclock or undervolt can cause exactly the same failures each time? You'd expect variety of failures I'd have thought? Every day is a learning day.

Your CBS log contains nothing important. The only repair that was made was to the shortcut for OneDrive...

2021-04-19 17:10:15, Info                  CSI    000001ca [SR] Repairing file \??\C:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\\OneDrive.lnk from store

....and that's not the cause of your problems!

I did look down your list of UWP apps and the main non-Microsoft apps that you have installed (which will have been installed manually) are these:

ArmouryCrate
AURACreator
HiddenCityMysteryofShadows
PrimeVideo
Cinebench
Netflix
iTunes
CanonInkjetPrintUtility
AdobeNotificationClient
NVIDIAControlPanel
1ED5AEA5.4160926B82DB (which research suggests is Angry Birds)
6918E89D.THECHESSLV.100 (which research suggests is a chess game)

If it turns out that this is a UWP issue rather than an overclock/undervolt issue then one of these apps is your most likely culprit I would have thought.

For now, I think it's essential to run without the undervolt and without any (non-PCS applied) overclock for a time. To figure out how long to run it for, estimate how long it would run before failing in the past and then multiply that by four. Run it at least that long to be sure. This will prove (or not) that it was the undervolt/overclock that was the cause of your crashes/restarts - obviously then you'll need to reapply those much more carefully and with longer real-world testing.

Sorry @ubuysa - I crossed with you there.
All understood.

Yesterday, my machine could not get past a 2 hour period roughly while idle without a crash. I’ve had it running for about 9 hours yesterday since the last event, but will leave it until this evening at least before I look at anything else....

 

[Scott]

A bit off the topic of this thread in some ways @Scott but I might ask for your knowledge of LLC?

My concern with the Undervolt was the likelihood of Vdroop getting excessive when some process called for increased power - causing the voltage to drop below usable limits before the system can adequately respond - leaving the CPU incapable of keeping up and causing the process to fail - leading to a crash.

I haven't played with LLC yet - as I believe it can result in excessive voltage spikes that might come with it as a load suddenly ceases - sort of the opposite of the above - and as excessive voltage worries more than insufficient voltage - I want to do a good bit more reading before I consider playing with it.

But I do understand that it can help alleviate the excessive VDroop that can come with undervolting - and more generally help keep the voltage delivered to the CPU more usable and stable for Overclocking.

Increasing the VRM phase switching frequency would seem to be in a similar camp but with less risk of the spiking that LLC might bring.

Any gen on your side worth sharing?

I played with the LLC on my Z390 when trying to eek out the maximum I could out of the 9900k. The Vdroop was doing my nut in and I felt that it was impacting performance.

Turns out there may have been a hair in it but nothing that was worth the temps that I was hitting.

Vdroop is a board level type thing. The higher the level, the less of an impact it should have. My board is very much middling in the voltages so there's no firm control on it for me to have any particular success by trying to be precise. You may find a similar experience.

The undervolt you applied while overclocking potentially shaved a little too much off. Whatever process is drawing the spike at the time is likely being corrupted and hanging, hence the BSOD. The down-side of LLC is overshooting your cap, but as you are undervolting I don't think overshooting for a brief spike will cause any concern.

With all that in mind... it's probably worth an experiment or 2. Like boost control in a car, brief spikes don't worry me too much..... as long as they aren't sustained for any length of time and don't get into the realms of dangerous I would be quite happy.

 

[ubuysa]

I played with the LLC on my Z390 when trying to eek out the maximum I could out of the 9900k. The Vdroop was doing my nut in and I felt that it was impacting performance.

Turns out there may have been a hair in it but nothing that was worth the temps that I was hitting.

Vdroop is a board level type thing. The higher the level, the less of an impact it should have. My board is very much middling in the voltages so there's no firm control on it for me to have any particular success by trying to be precise. You may find a similar experience.

The undervolt you applied while overclocking potentially shaved a little too much off. Whatever process is drawing the spike at the time is likely being corrupted and hanging, hence the BSOD. The down-side of LLC is overshooting your cap, but as you are undervolting I don't think overshooting for a brief spike will cause any concern.

With all that in mind... it's probably worth an experiment or 2. Like boost control in a car, brief spikes don't worry me too much..... as long as they aren't sustained for any length of time and don't get into the realms of dangerous I would be quite happy.

You're talking hardware at me now and whilst I can read the words that might as well be a recipe for chocolate cheesecake for all the sense it makes to me!

 

[NoddyPirate]

I played with the LLC on my Z390 when trying to eek out the maximum I could out of the 9900k. The Vdroop was doing my nut in and I felt that it was impacting performance.

Turns out there may have been a hair in it but nothing that was worth the temps that I was hitting.

Vdroop is a board level type thing. The higher the level, the less of an impact it should have. My board is very much middling in the voltages so there's no firm control on it for me to have any particular success by trying to be precise. You may find a similar experience.

The undervolt you applied while overclocking potentially shaved a little too much off. Whatever process is drawing the spike at the time is likely being corrupted and hanging, hence the BSOD. The down-side of LLC is overshooting your cap, but as you are undervolting I don't think overshooting for a brief spike will cause any concern.

With all that in mind... it's probably worth an experiment or 2. Like boost control in a car, brief spikes don't worry me too much..... as long as they aren't sustained for any length of time and don't get into the realms of dangerous I would be quite happy.

Thanks so much @Scott - I think that is mostly in line with my undertsanding. I just wasn't sure how much higher my voltage might go under initial load or immediately after a reduction in load, but as you say really I guess - I've been careful to not have them exceed the spikes that would occur under stock behaviour, so any overshoot would be modest and short lived perhaps.

I really wish I had a better motherboard for monitoring the VRM conditions though. That is far and away the biggest handicap here. I have no way to monitor VRM temperatures effectively and if I was to play with the switching frequency in particular in any significant way I think I would need that.

Part of me says I am way below the VRM capability so I don't need to worry, but another part of me wants proof!

It looks like any playing with the LLC will also have to be alongside a simple sit and wait approach and seeing if crashes occur. Even the tightest polling frequency at 50ms within HWInfo just isn't going to be quick enough to properly see any voltage spikes I imagine, outisde of pure pot luck. Also, setting HWI to 50ms to try to see the idle behaviour more clearly causes my CPU activity to shoot up tpo 9% (HA!) as it constantly bugs the CPU for reports! That means that with the monitoring software doing it's monitoring, my CPU is never really at idle anyway, in which case the beneift of LLC would be completely hidden.

What gives!!!

(Maybe @AgentCooper could buy me an oscilliscope with his 11900K project pocket money?)

 

[NoddyPirate]

FWIW I've been back and taken a closer look at your system log, and found a WHEA error. WHEA is the Windows Hardware Error Architecture, it's involved whenever a hardware error is detected....

View attachment 25160

....that's a processor machine check error - that might suggest an issue with the undervolt perhaps?

Incidentally, all those BITS-Client errors are because you have more BITS jobs running than your job limit specifies.

Sorry - I missed these comments first time around @ubuysa - thank you!

The WHEA error is interesting and perhaps the first (and only) indication of an undervolt issue as you say.

I checked the Bits Job list with 'bitsadmin /list' and every single entry was basically the same Microsoft Outlook thingy. I then cleared them with 'bitsadmin /reset' and the list has remained empty. Not sure what was going on there really.... ('bitsadmin /?' gave me a full list of commands with help too - which was very handy!)

My plan is to:

Wait and see if things are stable then:

1) Re-introduce Undervolt and see if crashes recur.
2) Remove Undervolt again and see if they disappear again - this should confirm what's happening once and for all.
3) Reintroduce the RAM OC and see if things remain stable.
4) Reinstall BitDefender and see if things remain stable.

All the above to with a day or two in between and with a panicked reversion to you if one of the steps fail!

 

[Scott]

Thanks so much @Scott - I think that is mostly in line with my undertsanding. I just wasn't sure how much higher my voltage might go under initial load, but as you say really I guess - I've been careful to not have them exceed the spikes that would occur under stock behaviour, so any overshoot would be modest and short lived perhaps.

I really wish I had a better motherboard for monitoring the VRM conditions though. That is far and away the biggest handicap here. I have no way to monitor VRM temperatures effectively and if I was to play with the switching frequency in particular in any significant way I think I would need that.

Part of me says I am way below the VRM capability so I don't need to worry, but another part of me wants proof!

It looks like any playing with the LLC will also have to be alongside a simple sit and wait approach and seeing if crashes occur. Even the tightest polling frequency at 50ms within HWInfo just isn't going to be quick enough to properly see any voltage spikes I imagine, outisde of pure pot luck. Also, setting HWI to 50ms to try to see the idle behaviour more clearly causes my CPU activity to shoot up tpo 9% (HA!) as it constantly bugs the CPU for reports! That means that with the monitoring software doing it's monitoring, my CPU is never really at idle anyway, in which case the beneift of LLC would be completely hidden.

What gives!!!

(Maybe @AgentCooper could buy me an oscilliscope with his 11900K project pocket money?)

I know you really want the proof but it's genuinely a moot point. Even absolutely hammering the VRMs as much as possible by OCing the 5600X to the max... it's not going to make them sweat. The board is designed to handle the big boys in standard guise without going on fire, and advertised as overclock capable for them too (which would make me sweat personally). Regardless, there are so many safeguards in place now that you can be confident there won't be any VRM concerns. Any limitations would show when overclocking with maximum voltage use, which you aren't considering, and won't be able to sustain without a huge cooler on there.

Basically, water is wet...... don't try and measure the wetness if you don't have to

The LLC is a perfectly safe feature. Again, well covered within the safety features of the board & chipset. I couldn't tell you the last time I heard of someone actually managing to fry a CPU while knowing what they were doing. I pushed my 9900k to 1.6v and nothing happened........ although I think I may have got a tan.

A 50ms spike to kill a CPU would need to be about 10V Anything around 1.8 I would worry about and switch off, anything inside 1.5V and I'm sleeping soundly.

 

[NoddyPirate]

I know you really want the proof but it's genuinely a moot point. Even absolutely hammering the VRMs as much as possible by OCing the 5600X to the max... it's not going to make them sweat. The board is designed to handle the big boys in standard guise without going on fire, and advertised as overclock capable for them too (which would make me sweat personally). Regardless, there are so many safeguards in place now that you can be confident there won't be any VRM concerns. Any limitations would show when overclocking with maximum voltage use, which you aren't considering, and won't be able to sustain without a huge cooler on there.

OK - that makes me feel much better - and yes the motherboard default limits for power and current are far and away on a different planet to anything the 5600X could ask for.

Basically, water is wet...... don't try and measure the wetness if you don't have to

But that goes against my entire modus operandi - If you were to sum up all my efforts over the past month or two it could be summarised with "Played with settings and adjustments that were entirely unecessarily, provided minimal actual benefit, for the sole purpose of being able to see what would happen." I can't stop now!!!

The LLC is a perfectly safe feature. Again, well covered within the safety features of the board & chipset. I couldn't tell you the last time I heard of someone actually managing to fry a CPU while knowing what they were doing. I pushed my 9900k to 1.6v and nothing happened........ although I think I may have got a tan.

A 50ms spike to kill a CPU would need to be about 10V Anything around 1.8 I would worry about and switch off, anything inside 1.5V and I'm sleeping soundly.

1.6V? I'm running a cold sweat just reading that! An abundance of caution has me pondering voltages a fraction of those sort of values. Seeing my single core boost voltage during Auto-OC up at 1.45V had me shaking and screaming "FIRE!" before immediately rebooting back into BIOS.

Your points are very well made though, there is more room for manouvreing and more inherent protections available to me than I am aware of. As long as sense prevails and the law of diminshing returns is kept in mind as you push things then all should be perfectly OK.

(Apart from annoying Ubuysa with further crash reports of course......)

 

[ubuysa]

(Apart from annoying Ubuysa with further crash reports of course......)

I've picked this bit out because it's the only thing in both your and @Scott's posts that makes any sense at all to me. I'm not annoyed by crash reports - I'm annoyed by people who don't pick up their dog's poo.

 

[NoddyPirate]

I'm annoyed by people who don't pick up their dog's poo.

Oh don't get me started on that topic! Walking the kids to school in the mornings is more like running an obstacle course.

 

[Scott]

OK - that makes me feel much better - and yes the motherboard default limits for power and current are far and away on a different planet to anything the 5600X could ask for.

(had to snip, too long)

You're showing quite the degree of caution considering you were filling up various vessels with JET-A1 with a lit cigarette hanging out your gub

I'm the guy that was wiring the 110v engine test rigs bare handed knowing fine well a wee jolt will wake me up but not kill me.

I have the same disregard for safety in all walks of life....... leccy, fuel, fire...... I'm amazed I've made it to 40 to be honest. 1.6v on a CPU was barely even a consideration of danger.

However.... since we like to keep things mildly technical... consider what kills parts. It's the compound effect of voltage, current and time. Effectively...... power * time. Without getting into serious voltage territory, consider the dangers of how much power a motherboard can release to a CPU in a 50ms interval that would actually cause problems. It's basic concepts that are missed on the interwebs by very clever people. Your reading and digging around has no doubt highlighted a lot of these missing concepts and basis to some of their conclusions and arguments. It may seem that I actually throw caution to the wind but I don't, I'm just a little more calculated in my decision making than most.

I'll give a good analogy that's a true argument I made years ago...... with highly regarded experts.... when I told them they were wrong (went down a storm as you can no doubt imagine).......

Safe known (agreed) boost limit for a 2JZ-GTE JSpec TT 1.2bar. Anything more than this and you work the turbos too hard and they will generate too much heat thus making the system less effective. This was well regarded as being true and I would never argue against this particular part. The part I argued against was boost spikes. The theory goes that boost spikes kill turbos as they are working harder than they are designed to and with the known limit of 1.2bar being breached this was going to cause major issues. Now.... I'm not going to spoon feed here as I'm sure you will very much get the jist of where I'm coming from...... I argued that most boost spikes were due to the boost solenoid holding the wastegate closed that split second too long while generating the boost (basically the LLC). This meant that the boost came in strong, and hard.... which was brilliant, but often overshot to around 1.3 or 1.4 bar. The shock and horror from people when I explained I was happy with this ended up with the entire forum against me. I stood firm though as I explained that at 4000RPM the intake of the engine was around 50% capacity, ergo in order to produce 1.2bar at 4000RPM the airflow was SIGNIFCIANTLY less than 1.2bar at 8000RPM (The known safe limit). With all that in mind there was absolutely no issues with having 1.3/4/5/6BAR at those levels, as long as they tailed off to the already known safe limit of 1.2bar over the coming rpms. I showed many times that my spike was short lived and petered off to 1.2bar holding firm by around 5000rpm. Eventually a very experienced, and well respected mapper, jumped in and got on board with my point of view. He said that a lot of the experienced race teams would factor in a staggered boost control and that it was a very effective way of maximising performance and efficiency while maintaining the safety limits of the turbos at the ragged edge. Put a fair bit of gas at a peep that day I'll tell you.

Anyway, TL;DR........ LLC is exactly the same as staggered boost control on an engine

 

[NoddyPirate]

(had to snip, too long)

You're showing quite the degree of caution considering you were filling up various vessels with JET-A1 with a lit cigarette hanging out your gub

I'm the guy that was wiring the 110v engine test rigs bare handed knowing fine well a wee jolt will wake me up but not kill me.

I have the same disregard for safety in all walks of life....... leccy, fuel, fire...... I'm amazed I've made it to 40 to be honest. 1.6v on a CPU was barely even a consideration of danger.

However.... since we like to keep things mildly technical... consider what kills parts. It's the compound effect of voltage, current and time. Effectively...... power * time. Without getting into serious voltage territory, consider the dangers of how much power a motherboard can release to a CPU in a 50ms interval that would actually cause problems. It's basic concepts that are missed on the interwebs by very clever people. Your reading and digging around has no doubt highlighted a lot of these missing concepts and basis to some of their conclusions and arguments. It may seem that I actually throw caution to the wind but I don't, I'm just a little more calculated in my decision making than most.

I'll give a good analogy that's a true argument I made years ago...... with highly regarded experts.... when I told them they were wrong (went down a storm as you can no doubt imagine).......

Safe known (agreed) boost limit for a 2JZ-GTE JSpec TT 1.2bar. Anything more than this and you work the turbos too hard and they will generate too much heat thus making the system less effective. This was well regarded as being true and I would never argue against this particular part. The part I argued against was boost spikes. The theory goes that boost spikes kill turbos as they are working harder than they are designed to and with the known limit of 1.2bar being breached this was going to cause major issues. Now.... I'm not going to spoon feed here as I'm sure you will very much get the jist of where I'm coming from...... I argued that most boost spikes were due to the boost solenoid holding the wastegate closed that split second too long while generating the boost (basically the LLC). This meant that the boost came in strong, and hard.... which was brilliant, but often overshot to around 1.3 or 1.4 bar. The shock and horror from people when I explained I was happy with this ended up with the entire forum against me. I stood firm though as I explained that at 4000RPM the intake of the engine was around 50% capacity, ergo in order to produce 1.2bar at 4000RPM the airflow was SIGNIFCIANTLY less than 1.2bar at 8000RPM (The known safe limit). With all that in mind there was absolutely no issues with having 1.3/4/5/6BAR at those levels, as long as they tailed off to the already known safe limit of 1.2bar over the coming rpms. I showed many times that my spike was short lived and petered off to 1.2bar holding firm by around 5000rpm. Eventually a very experienced, and well respected mapper, jumped in and got on board with my point of view. He said that a lot of the experienced race teams would factor in a staggered boost control and that it was a very effective way of maximising performance and efficiency while maintaining the safety limits of the turbos at the ragged edge. Put a fair bit of gas at a peep that day I'll tell you.

Anyway, TL;DR........ LLC is exactly the same as staggered boost control on an engine

(Emojis not working again sadly - this post was full of them!!)

Love it! Thanks @Scott - that is a perfect anaolgy for me and makes perfect sense! Bravo!

There is no doubt my profession leaves me entirely risk-averse in all walks of life - so hence the difference between our starting points - but yes you will be so much more experienced and knowledeable in this area that I can understand how you can dive in happily.

Incidentally I used to own a Daihatsu Charade Petrol Turbo - the Diesel variants were common here but the Petrol was rare. It was a three cylinder 900cc monster - mostly because it was basically entirely made of tin foil and weighed nothing. (My mates used to annoy me by regularly lifting the rear wheels and turning the whole thing sideways in my driveway.)

One day the turbo seized - through the usual coking that results from not letting those old contraptions cool properly before you switch them off - and it became a normally aspirated dud with a massive restriction blocking the intake and exhaust . From that day onwards I had to check the wind direction before I headed for the motorway, because if I was into wind I couldn't get it over 50 mph and everyone would beep at me. Also on a trip to Sligo with some mates I had to eject them to be able to get the car up a shallow hill - and have them walk up to meet me at the top.

I finally managed to swap in a regular exhaust manifold from a scrapyard and seal off the oil supply line to the turbo and got about 50% of my power back. But it was never the same car to me in any way.

So to keep your analogies going - I guess I am just trying to be careful that I don't turn my CPU into a 1987 3 cylinder hatchback!

 

[NoddyPirate]

(EDIT - corrected the above - not a GTi but GT - as I remember now having the carburettor out a few times for tweaking too. Those were the days when you had proper mechanical parts that you could fiddle with! Not like today’s just-swap-it-out electronic rubbish.)

 

[Scott]

I've only ever cooked one CPU, was back in the 90s when you could hand solder a motherboard...... meaning there wasn't much space for safety mechanisms

Interesting side note. I've never ever known a CPU to actually just die. I've got a drawer full of CPUs and every single one of them work. I overclocked my old 2700k to the edge, ran it 24/7 for about 8 years and it never put a foot wrong.

They are so much harder to kill than people realise

 

[Scott]

(EDIT - corrected the above - not a GTi but GT - as I remember now having the carburettor out a few times for tweaking too. Those were the days when you had proper mechanical parts that you could fiddle with! Not like today’s just-swap-it-out electronic rubbish.)

Carburettor and a turbo.... winning combo for smells and sounds regardless of engine size/power