Windows Hard lock on resume from low power states
16 October, 2021 at 10:51 am #4596
I’ve got a bit of an issue that I *believe* is caused by DesktopInfo. For a good while now, I’ve been experiencing a very bizarre issue. Every day or two, when I would wake my PC from a low power state (be it the machine having just gone idle, disabled displays & hard disks, or a full
S3sleep state,) my machine will completely lock up. If I had my workstation locked, It’d make it back to the sign-in screen. If it wasn’t locked, it’d show the desktop and everything. I’d know what time it froze (say if it woke in the middle of the night), because the top of my desktop info display is the current time 🙂
The bizarre part is, everything would just be stuck, in the same way I can remember machines doing from decades ago. The display wouldn’t change, input did nothing, and the only option I have is to use the physical reset button (or hold down the power button.)
I’ve tried to track this behavior down for months now, to no avail. There’d never be anything in the event logs, no messages anywhere, no bluescreen dumps, nothing as to why things would just stop. I thought it to be a hardware issue, because I recall the issue starting around the time I replaced my processor. But now I realize that is also when I started using desktop info on this machine (excited to call attention to my shiny new chip.) I digress.
Last week, I needed to close Desktop Info for some reason. I have it start on login, and thought “oh I’ll just let it start next time I reboot or my system freezes.”
It’s been over a week now and I haven’t experienced the freeze. The only thing I can tell is different this time is just that I don’t have desktop info running.
I’m wondering if you’ve come across anything similar to this? I’ve attached my DesktopInfo.ini to see if you see anything that might stand out to you as a potential cause for some sort of deadlock. It’s a decently large ini, so I’m thinking the refresh coming out of the low power state might be causing a race condition with the kernel waking everything back up from low power?
I’d appreciate any guidance you may have.
16 October, 2021 at 10:59 am #4597
I see it didn’t like the attaching of the ini directly, I’ve zipped it and attached it.
As well, I thought perhaps it pertinent to provide some information about the hardware I’m experiencing this on:
ASUS TUF Gaming X570-Plus (Wi-Fi)
Ryzen 5950X (Running at standard clock speed, no PBO.)
32 GB RAM @ 3200 MHz (Standard XMP profile.)
GeForce 2080 Ti (Standard clocks. Resizable BAR is enabled.)
UEFI Boot, Virtualization enabled, currently running Win 11 21H2 22000.258
19 October, 2021 at 8:35 pm #4614GlennKeymaster
I haven’t seen this. A couple of times DTI would lock up inside the debugger which I presume is a bug in the debugger but I can’t be absolutely certain. But it’s never locked up the entire PC. Given that it’s set to low priority, i can’t see that it can ever totally take over a computer.
I see computers go into meltdown when an application runs away but even at 100% cpu there’s always some sign of life even if it takes several minutes to get Task Manager on the screen.
I see computers go into total lockup when there’s a hardware issue, say a failing HDD, RAM module or something like that. Maybe some incompatibility with new hardware that doesn’t manifest itself right away, say RAM timings, bus speeds etc.
Have you done any serious stress testing with the new CPU?
- This reply was modified 1 month, 1 week ago by Glenn.
- This reply was modified 1 month, 1 week ago by Glenn.
20 October, 2021 at 11:03 pm #4624
I appreciate the thoughts!
I’ll touch on in it in a minute, but yeah I doubt it’s actually DesktopInfo that’s causing the lockup itself, given the nature of how it stops *everything*. It presents like a bug from something running in kernel space. AFAIK nothing running in user space has been able to cause a hard lock like this since the win 6.0 driver model.
“Serious” stress testing not really, but definitely some benchmarking. (Cinebench, Passmark, Geekbench, those sorts of things.) I also do a fair bit of development on this machine, so its cores get worked out by compiles and the sort. I’m coming up on a year of running this CPU now and haven’t run into any other issues that come to mind anyways.
I will say I’ve updated the UEFI & Chipset drivers a handful of times over the year, and I think (could very well be perception bias) that has reduced the frequency with which I saw the issue.
I just hit 10 days of uptime since disabling DesktopInfo, which I certainly hadn’t managed to do in the past year. I’m due for a reboot for Windows updates, so I think I’ll start experimenting some: I’ll disable basically everything in my .ini, and every few days I don’t experience the issue, I’ll re-enable a chunk and see if I can narrow down where I may be having the problem from.
Anyways, back to my kernel guess — If it’s not hardware related, my gut instinct is a race condition in the kernel with either the network interfaces section (due to me having several ‘virtual’ interfaces due to vmware workstation that don’t behave like typical hardware) or some of the WMI calls (of which I have several that update at
interval:0, so they’d only run on a hard refresh like seems to happen on resuming from low power states, whatever happens to trigger it then.
21 October, 2021 at 6:46 am #4626GlennKeymaster
Sounds like a plan. Of course you’ll never know for sure unless you can positively reproduce the problem on demand.
I’m curious to know if it locks up on coming back from sleep only or also hibernate?
- You must be logged in to reply to this topic.