The short answer
Windows is obeying its own power settings. USB selective suspend and the per-hub “turn off this device to save power” flag cut power to ports during sleep, and if the device fails to re-enumerate on wake the port stays dead until you replug. The fix is to disable those flags, then retest the same sleep cycle.
What we measured on our unit
We only publish first-hand results for the machine on our bench: a Beelink EQi12 with an Intel Core i3-1215U.
| Test | Starting state | Result on our unit |
|---|---|---|
| Shutdown wake (S5) | Full shutdown | 5/5 passed |
| Sleep wake (S3) | Sleep (suspend to RAM) | 4/5 passed — one cycle required the power button |
| Automatic boot after AC restore (G3) | Mains power removed, then restored | 3/3 returned to the previous state |
The interesting result is the sleep one. Four out of five is not a pass; an intermittent wake is a real signal, and it is exactly the kind of intermittency that a single successful test hides. The shutdown result also matters for a different reason: it proves the wired adapter receives and acts on a magic packet after a full shutdown, which means any failure in the sleep path is specific to resume, not to the adapter’s wake capability in general.
This page does not claim a measured USB dropout rate on our unit, because a USB dropout is defined by a device failing to return, and that depends on which device is attached. What the measurements do establish is that resume is the less reliable path on this hardware, and that is the path worth hardening.
Why resume is a different problem from shutdown
A sleep cycle is not a short shutdown. In S3 the system keeps memory powered and suspends devices; on resume, every suspended device must be reinitialised by its driver in sequence. Shutdown is a full stop that ends in a fresh boot with full device initialisation. This is why the same adapter can pass shutdown Wake-on-LAN five times and then fail one sleep wake in five: the sleep path adds a re-initialisation step that the shutdown path never performs.
The mini PC adds two wrinkles worth knowing:
- The EQi12 pulls air from its base, so a unit on a soft surface can also run warmer during resume bursts. Temperature is not the cause of a dropout, but it is a reason not to stack unrelated changes.
- Port choice matters. The unit exposes USB 3.2 ports, a single USB 2.0 port and a USB-C data port. A device that works on one port and fails on another is telling you about the port’s controller or power budget, not about the device.
The causes, in the order worth checking
| # | Reported cause | Symptom shape | Fix |
|---|---|---|---|
| 1 | USB selective suspend enabled | Devices vanish after sleep and return after replug; affects several devices at once | Power Options → advanced → USB settings → disabled |
| 2 | USB Root Hub power management flag | Same, but often only some ports; a device on a specific root hub dies | Device Manager → each USB Root Hub → Power Management → untick |
| 3 | Network adapter power management flag | The NIC is missing or link-less after wake; sleep Wake-on-LAN is intermittent | Adapter → Power Management → untick, and keep it awake for WOL |
| 4 | Fast Startup enabled | Devices missing after an apparent shutdown rather than after sleep; only a restart clears it | Disable Fast Startup in Power Options |
| 5 | Bus-powered hub over budget | Only when several devices are attached, or only the power-hungry one (an external drive) fails | Move the drive to a direct port or use a powered hub |
| 6 | Stale chipset or USB controller driver | Started after a Windows update; several unrelated devices fail together | Update chipset driver, or roll back the controller driver |
| 7 | Firmware not maintaining USB standby power | Ports are dead even before the OS loads its driver stack | This is a firmware behaviour; the OS flags do not fix it |
Two of these are worth stating plainly because they send people down the wrong path. Rank 5 looks like a driver problem and is a power-budget problem. And rank 7 looks like a Windows problem and is not: if a port has no power during sleep, no operating-system setting will bring it back, and the honest conclusion is that the port cannot be relied on across sleep.
Decision tree: where did the device go?
The fixes, step by step
1. USB selective suspend
Control Panel → Hardware and Sound → Power Options → Change plan settings → Change advanced power settings → expand USB settings → USB selective suspend setting → set to Disabled. On a machine with both battery and mains entries, change both. The cost on a desktop or always-on mini PC is negligible.
2. USB Root Hub power management
Device Manager → expand Universal Serial Bus controllers → for each entry named USB Root Hub, USB Root Hub (USB 3.0) or Generic USB Hub: right-click → Properties → Power Management → untick Allow the computer to turn off this device to save power → OK. There are usually several root hubs, and unticking only one changes nothing. If the Power Management tab is missing on an entry, skip it and continue.
3. Network adapter power management
Device Manager → Network adapters → your Ethernet adapter → Properties → Power Management → untick Allow the computer to turn off this device to save power. This is essential if you rely on sleep wake, because the adapter must stay armed to receive the magic packet.
4. Fast Startup
Control Panel → Power Options → Choose what the power buttons do → Change settings that are currently unavailable → untick Turn on fast startup → Save. Then perform a full restart, not a shutdown, and retest.
5. Hub power budget
Move the failing device to a direct port, ideally a rear USB 3.x port. If it needs a hub, use one with its own power supply. A bus-powered hub divides one port’s current budget across every attached device, so the failure appears only when demand peaks — which is often during resume, when several devices reinitialise together.
6. Drivers, last
Update the chipset driver from the machine vendor first. If the problem began immediately after a Windows update, use Roll Back Driver on the USB host controller before reaching for third-party driver utilities; a rollback is reversible, and most third-party “driver updaters” are not worth the risk.
What is genuinely not fixable
- A port with no standby power in sleep. If the port is dead before the operating system loads its driver stack, the firmware is not maintaining power and no Windows setting will change that. Choose a different port, or do not rely on that device surviving sleep.
- A device that exceeds the port’s current budget. A high-draw external drive on a USB 2.0 port specified at 500 mA may simply never be reliable there.
- Sleep reliability below 100 % on this class of hardware. Our own unit woke from sleep four times out of five. Where startup must be dependable, shutdown wake and AC-restore recovery are the two paths our measurements support without qualification — see the AC power recovery guide and the S5 wake source comparison.
Where to go next
- Wake-on-LAN not working: 12 causes — the probability-ordered checklist this page’s network section feeds into.
- WOL works from shutdown but fails from sleep — the S3-specific path, including what our 4/5 result means in practice.
- Realtek r8169 driver troubleshooting — when the adapter itself, rather than its power management, is the problem.
- USB SSD limited to about 40 MB/s — the throughput-side companion when a USB path is slow rather than absent.
- Beelink EQi12 BIOS settings for a home server — firmware-side sleep and USB behaviour on this platform.
Sources
Measured on our unit
- Beelink EQi12 (i3-1215U) — shutdown WOL 5/5, sleep wake 4/5 with one cycle requiring the power button, AC-restore recovery 3/3. Source:
/lab/beelink-eqi12-12-hour-stability/and/hardware/beelink-eqi12-review/. - Rear I/O layout as photographed on the bench unit (two USB 3.2, one USB 2.0, one USB-C data, dual Gigabit Ethernet).
Third-party guides and support knowledge-bases (reported, not measured here)
- Rescue PC Repairs — “How to Fix USB Devices Not Recognized After Sleep or Restart on Windows” (symptom list, selective suspend, root-hub flags, Fast Startup, controller driver paths).
- UMA Technology — USB device descriptor failure after sleep (selective suspend and hub power settings, Fast Startup as a state-preserving cause).
- TechBloat — USB device not recognized (power-saving settings, explicit note that high-current devices should connect directly or through a powered hub).
- RebootDoctor — USB not recognized on Windows 11 (port current budgets: USB 2.0 at 500 mA, USB 3.0 at 900 mA, and 2.5-inch drives needing 600–900 mA; driver rollback after an update).
- CleverFiles — USB device not recognized (selective suspend and per-hub power management, and the recommendation to avoid third-party driver-updater tools).
Every threshold and settings path attributed to Windows comes from the sources above. The wake reliability figures are our own measurements and are labelled by test count rather than described as a general product rating.