Windows Hard lock on resume from low power states

Forums Desktop Info Windows Hard lock on resume from low power states

Viewing 6 reply threads
  • Author
    • #4596

      Hello again!

      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 S3 sleep 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.


    • #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

    • #4614

      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 11 months, 1 week ago by GlennGlenn.
      • This reply was modified 11 months, 1 week ago by GlennGlenn.
    • #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.

    • #4626

      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?

    • #4848

      Hi Glen!

      First I didn’t see your response, so sorry for the very late reply: I haven’t caught it happening from a hibernate (but the only hibernate I use on my system is the “built in” one that comes as a part of fast startup.)

      The *good* news is: I reproduced the issue *without* DesktopInfo!

      (Feel free to stop reading here, the rest is more of just me rubber ducking, but you can rest assured that I’m pretty confident it’s not any issue in or around DesktopInfo)

      Bad news is, I reproduced the issue without DesktopInfo 😂. It does seem to happen more often when DesktopInfo is running, so now that’s at least helping me try and track down what’s causing it.

      In the last month I did a repair install (e.g.: “in place upgrade”) of Windows on a whim, hoping that would help, but it’s still happening, so I think that it’s got to be some software I’ve got going (or hardware in general.)

      This morning I had it happen in a way that was a little different than before. The event log kept going after the hard lock, and there was actually a relevant event when it happened.

      Now if I can just figure out what those session IDs mean and why that means all the I/O stops 🙂

      I appreciate you putting up with me and for all your help, Glenn!

      Hope you’re well.

    • #4849

      I’m going with the race condition in the kernel. You mention you have Fast Startup enabled. I know many techs will tell you to switch that off as it causes issues, I just can’t remember the details but something to research. I switch it off on every machine that touches my bench as a matter of course. I notice that event comes from Microsoft-Windows-Kernel-Power…

      It’s not something basic like an inadequate power supply buckling under the startup load?

Viewing 6 reply threads
  • You must be logged in to reply to this topic.
Glenn's Page