When using a USB sound card, you might encounter issues with Windows no longer being able to enter sleep mode automatically. It seems there are issues with what Windows seems to call a “Legacy Kernel Caller”, a system component that’s apparently needed for at least some of the USB sound cards. I’ve been specifically encountering these issues using a Sound Blaster Omni cards/module. The issues for me are also accentuated by using an otherwise great piece of software called Voicemeeter, basically a virtual soundboard. While without Voicemeeter, my system is still sometimes able to auto-sleep despite the Legacy Kernel Caller issues, using Voicemeeter, it is pretty much never able to auto-sleep anymore (but to be fair to Voicemeeter, it seems this happens even with other options of re-routing sound device output to another device, like when using the Windows Listen feature, so it’s not really a Voicemeeter-exclusive issue). This is possibly because it somehow keeps the sound card “active” – I’ve noticed that the Legacy Kernel Caller power request block goes away at times while using the sound card on its own, it never goes away while using Voicemeeter. Why that is I can not tell you (but as far as Voicemeeter is concerned, it seems to do this with other sound cards as well, it’s just that you can whitelist them, unlike the Legacy Kernel Caller). But what I can tell you is that the system is still definitely able to enter sleep mode normally if activated manually, it’s just that the timer for entering it automatically seems to never start, so the system just stays on all the time.
Thankfully, there seems to be a kind of workaround for this, and it took me a while to find (in fact I’ve combined several separate partial solutions into one), so I though I might share it with whoever finds it useful. I can tell you there’s quite a few people asking about a solution to exactly this issue with the Legacy Kernel Caller system component.
Windows does offer very little when it comes to actually giving you tools to troubleshoot sleep related issues. There’s the command that can tell you the reason your PC woke up the last time:
powercfg -lastwake
Sadly, that’s completely useless when it comes to any issues with your PC not going to sleep, because your PC obviously first has to go to sleep to have any data on why it woke up. So if it never goes to sleep, it will not give you anything to work with.
A bit more useful is the list of devices or processes that keep your PC awake. You can once again get that using the powercfg command:
powercfg -requests
You will get a list like this:
DISPLAY:
None.
SYSTEM:
[DRIVER] Creative X-Fi Audio Processor (WDM) (PCI\VEN_1102&DEV_000B&SUBSYS_00621102&REV_03\FFFFFFFFFFFFFFFF00)
An audio stream is currently in use.
[DRIVER] Legacy Kernel Caller
AWAYMODE:
None.
EXECUTION:
None.
PERFBOOST:
None.
ACTIVELOCKSCREEN:
None.
This is what it looks like on my system if I use Voicemeeter with my SB Omni as an output device and one of my X-Fi Titanium HD’s inputs as one of the input devices. Note that this is at “idle”, as in no sound is currently played back, otherwise you’d see more here, including the application sending the audio stream).
Ideally, I would just whitelist the two devices for the system to ignore those requests. Like this:
powercfg -requestsoverride DRIVER "Creative X-Fi Audio Processor (WDM) (PCI\VEN_1102&DEV_000B&SUBSYS_00621102&REV_03\FFFFFFFFFFFFFFFF00)" SYSTEM
Which tells the system to ignore the specified request of the DRIVER type in the SYSTEM section. You might not need to include the whole (PCI\VEN…and so on) part, I’m still not quite sure about it, sorry. Personally, I just add every iteration to be sure.
You can also list the overrides you have already defined on your system by doing just:
powercfg -requestsoverride
(Yes, I have a few soundcards in my PC, and it’s not even all of them listed here.)
This would all be great and fairly easy, but the problem here is that even if you define an override for the “Legacy Kernel Caller” driver, it doesn’t seem to do anything. The driver will be added to your overrides list and show up, but your system will still not enter sleep mode on its own as if the override didn’t exist at all. Apparently this might be a long standing bug in Windows, but then again there might also be some reason as to why Microsoft didn’t resolve this (because they’re clearly familiar with the issue). Who knows. But that’s where the workaround comes in.
Thing is, despite the system not starting up its own sleep timer, it can still go to sleep perfectly fine if you do it manually, for example by issuing this command:
Rundll32.exe Powrprof.dll,SetSuspendState Sleep
Also, screensaver does trigger just fine (yes, there are still screensavers in Windows 10, even though they are quite hidden away). So…hint, hint…we can use screensaver to work around this issue.
Surprisingly enough, you can do this with tools that are available in Windows. The only exception to this is the fact we need to edit the local group policy options to do this, and apparently it isn’t included in all Windows versions, namely the Home edition. It can be fairly easily added back even in Windows Home. Though it’s obviously up to you whether or not are you willing to do this, as it involves using a third party tool to install what is basically a system component, so it’s a potential security risk. I believe it is absolutely safe to do so at least from this source, but my beliefs are my own and you should obviously draw your own conclusions.
Anyway, provided you have the Local Group Policy editor available, you need to start it:
gpedit.msc
Once the editor opens, we need to navigate to:
Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration / System Audit Policies – Local Group Policy Object / Logon/Logoff
Here, we need to configure the “Audit Other Logon/Logoff Events” (it’s in a “Not Configured” state by default) and set it to audit both Success and Failure states (check both checkboxes, in other words). And obviously click Apply and/or OK. That’s all we need to do in Group Policy. The system will now log an event whenever a screensaver is triggered.
Now we will move over to Task Scheduler to configure how the system should respond to such an event.
We will create a new Task with whatever name you like. It’s up to you whether you want it to only run when you’re logged in or regardless of whether you’re logged in (largely depends on how you run your system). We will add a new Trigger for the task – the task will be run On an event, select Custom event, click the button for New Event Filter, switch to the XML tab, check Edit query manually and paste this as the query in question:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[(Level=4 or Level=0) and (EventID=4802)]]</Select>
</Query>
</QueryList>
That’s all for the Trigger tab. All we have to do now is set the action that is supposed to take place, so head over to the Actions tab and click New. Select the option Run a program (it should be pre-selected by default anyway). Enter this into the Program/script field:
rundll32.exe
and then this into the Add arguments (optional) field:
powrprof.dll,SetSuspendState Standby
Click OK and you’re basically done.
All that should be needed at this point is setting up your screensaver. As mentioned, the screensaver options are kinda hidden in Windows 10 as it seems you’re not expected to be using screensavers anymore, but they’re still there. You need to get into the Personalization screen in your Control Panel (one way to go there directly is just right click on your desktop and select Personalize at the bottom of the menu), and switch to the Lock Screen tab (yes, really, the Lock Screen). There you need to scroll down a bit, which also can be somewhat counterintuitive as it might not even look like there’s more content available if you scroll, but there is – there should be a Screens saver settings link at the very bottom. Click that and you can finally select your screensaver (doesn’t really matter which one) and the timeout when your computer should trigger it (so, in our case, when the computer should go to sleep).
One thing I should mention is that it seems like the option to turn off the screen in the Power options can sometimes interfere with the screensaver, so you might want to disable turning the screen off there.
And that should basically be it. Your PC should now be able to go to sleep even with the Legacy Kernel Caller blocking the automatic sleep, because the screensaver still triggers regardless and we have created a scheduled task that manually sets a sleep state for the system.
There are sadly still some things to note.
First, apparently no matter if you use SetSuspendState Standby or Sleep, the PC will always hibernate if you have hibernation enabled. So for the PC to sleep instead of hibernate with the above workaround, you need to disable hibernation completely:
powercfg -H off
If you want to keep hibernation enabled and still use the above workaround for putting your system to sleep, you can do it, but it requires you to use an external utility called PsShutdown. In that case, you need to adjust the scheduled task so that it runs PsShutdown instead of rundll32. Which means you’d enter this into the Program/script field (this assumes the utility is installed in one of the folders reachable via the system’s PATH settings, otherwise you’d obviously have to include a full path to the .exe file):
psshutdown.exe
and then this into the Add arguments (optional) field:
-d -t 0 -accepteula
which tells the utility to auto-accept the EULA it shows you when you run it and then to immediately suspend the PC. Or, if you prefer, you can replace the -d parameter with the -h option, which makes the PC enter hibernation instead.
Hope this is of some use to someone. I do use the rundll way of doing it, and it works perfectly fine.
