Windows 10 Desktop wakes from sleep to hibernate even when disabled

A strange occurrence has recently been annoying me: I usually put my computer into sleep mode rather than shutting it down, but Windows has started deciding I really want to hibernate instead. Between 1 and 10 minutes after sleeping, the computer wakes up and hibernates. It only wakes very briefly and it seems impossible to prevent it from going into hibernation, but input is nevertheless registered.

In Event Viewer the reason for the wake is the infamous "S4 Doze to Hibernate" as the Wake Reason.

By my understanding the setting governing this behaviour is the "Hibernate After" setting listed under Sleep in the settings of the current power plan. Most people seem to be able to alter this behaviour by changing this setting to a high number or to zero, disabling it. However, this setting is already zero, i.e. "Never," yet the phenomenon still occurs. I tried changing it to a very large number (999999) but the computer still wakes up. In this situation, though, it seems like the computer wakes up, attempts to hibernate and fails to do so: subsequently booting up doesn't succeed properly and the computer reboots itself.

This is pretty bizarre behaviour because it seems like it should only occur with a computer on battery power anyway. What else governs this behaviour, and how can I disable it - without also disabling some other useful feature (e.g. disabling wake timers, disabling hibernate, that kind of thing)?

Answer

I believe I've found the answer to this particular problem thanks to this page.

The problem was caused by the service AdaptiveSleepServices which was included in some update to AMD drivers. I have disabled the service and switched it to not automatically start as per the page's suggestion and this seems to have fixed the problem (my computer hasn't woken up to hibernate, and it should have done by now.)

It's worth noting that, though this service is from AMD, I've switched my graphics card to an nVidia one so have no AMD hardware running any more and have completely deleted AMD drivers using Driver Sweeper. This did not get rid of the service.

Why on earth AMD includes this trash in its drivers when there is a perfectly serviceable API for performing the same function is, unfortunately, plainly obvious: incompetence.