Windows Fast Startup and Wake-on-LAN: Was Your Shutdown Really S5?

The short answer

On a Windows mini PC, clicking Shutdown does not always produce a true S5 soft-off. With Fast Startup enabled, Windows saves kernel and session state to disk and the next boot resumes from it — an S4 hybrid, not a clean shutdown. Wake-on-LAN behaves differently across those states, so a WOL test result is meaningless until you know which state your machine actually entered. Here is how to verify it with commands and event logs, using our measured five-cycle S5 and S3 results as the reference.

Fast Startup is documented by Microsoft as a hybrid of cold boot and hibernate: at “shutdown” the user sessions are logged off, but the kernel and driver state is written to the hibernation file and the machine enters S4, not S5. Most WOL troubleshooting lists Fast Startup as one checkbox among many; this page goes deeper on the verification side, because the hardest part is not toggling the checkbox — it is proving which power state your machine was actually in when the magic packet arrived.

Why the S4/S5 distinction decides your WOL test

Wake-on-LAN is not one mechanism. It is a chain: the NIC must retain standby power, the firmware must honor the wake signal for the state the machine is in, and the driver must have armed the device correctly for that path. S3 (sleep), S4 (hibernate and hiberboot) and S5 (soft off) each arm the adapter differently. That is why the same machine, on the same LAN, can wake fine from one state and ignore packets from another — and why the symptom “WOL works from shutdown but fails from sleep” (or the reverse) almost always hides a state-mixing mistake in the test protocol itself.

If you have not yet mapped the full state table, read Wake from S5: What PME, RTC Alarm and Wake-on-LAN Actually Do first — it compares S3, S4, S5 and G3 across every wake source. The rest of this page assumes you know the states and focuses on the Windows-specific trap: the button labeled Shutdown may not enter the state it claims.

What we measured: S5 and S3 behave differently, and Windows admits it

We ran two five-cycle test series on a Beelink EQi12 mini PC (Windows, Realtek gigabit Ethernet) on 2026-07-12, plus a three-cycle AC-restore series. All raw logs and event captures are published in the EQi12 Measurement Data repository under CC BY 4.0.

Fact block — measured wake and recovery behavior (source: eqi12-measurement-data, files EQi12_S5_WOL_5cycles.log, EQi12_S3_WOL_5cycles.log, EQi12_S3_WOL_Windows_Events.txt, test date 2026-07-12):

Three conclusions fall out of that table, and each one is a practical verification technique:

1. powercfg /lastwake is a state discriminator, not a WOL validator. After an S3 resume it names the wake source. After a true S5 wake it reports nothing — Windows considers the machine freshly booted, not woken. In our S5 log every cycle recorded Wake History Count - 0. If lastwake reports a source after what you believed was a shutdown, your “shutdown” was actually hibernate or hiberboot — the test told you which state you were in, even though it did not tell you whether WOL works.

2. The event log separates resume from boot. Our S3 captures show the clean pair: Kernel-Power event 42 (“The system is entering sleep”, reason Application API) before the packet, event 107 (“The system has resumed from sleep”) right after the magic packet landed. A hiberboot resume also looks like a resume in the log; a true S5 boot does not produce a resume event at all. Checking for event 107 around the wake timestamp is the fastest way to catch a Fast Startup masquerading as a shutdown.

3. Recovery time is the practical stake. Sleep resume had Docker and Jellyfin back in under four seconds; the full S5 boot cycle averaged 42 seconds before the media server answered HTTP. Neither is “better” — S5 is the right choice for unattended machines that must not sit powered on, sleep is the right choice for fast turnaround — but if you design your automation around one, measure with that state, not with whichever one your shutdown button happened to perform.

For the complementary symptom — shutdown wake works but sleep wake fails — see WOL Works from Shutdown but Fails from Sleep, which walks the Realtek driver arming path in detail.

The verification workflow, in order

Run these in an elevated terminal. The goal is to establish three facts before you send a single magic packet: which states Windows supports, what your “shutdown” does, and what Windows recorded after the wake.

Step 1 — Enumerate supported states

powercfg /a

Read two things from the output: whether Standby (S3) or Modern Standby (S0 Low Power Idle) is active, and whether Hibernation is available. If hibernation is available, Fast Startup can be active, and your Shutdown button is untrustworthy for S5 testing. This is the same first check our 12-cause WOL checklist uses, and it catches the most common wrong assumption in one command.

Step 2 — Establish the baseline state of the adapter

powercfg /devicequery wake_armed

The NIC must be listed, or no state will wake it. On the EQi12 the Realtek controller is the only wake-armed device. If your adapter is missing here, fix the driver arming first — see Realtek RTL8111 Wake-on-LAN setup for Windows — because state-mixing tests are pointless without an armed adapter.

Step 3 — Force an unambiguous S5 and test it

Two ways, pick per situation:

:: One-off full shutdown, bypassing Fast Startup for this cycle
shutdown /s /full /t 0

:: Or remove the ambiguity permanently (also disables hibernate)
powercfg /h off

shutdown /s /full requests a full shutdown for that one cycle and is ideal for A/B testing: run one cycle with it, one with the ordinary Shutdown button, and compare what the logs record. Turning hibernation off with powercfg /h off removes Fast Startup from the equation on every future boot — the cleaner choice for a headless home server, at the cost of losing hibernate.

Step 4 — Wake it, then ask Windows what happened

powercfg /lastwake

Interpret the three possible outcomes like this:

Step 5 — Confirm with the event log

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Kernel-Power'; Id=42,107} -MaxEvents 10

A sleep-resume pair (42 then 107) bracketing your test window means the machine never left the resume path. Their absence around a “shutdown” wake confirms a true soft-off boot. In our S3 capture the pair is unambiguous: event 42 at 06:08:08 (reason: Application API), event 107 at 06:08:14, and the network stack verified up 3.56 seconds after the packet arrived.

Why this matters more on mini PCs than desktops

Three mini-PC-specific factors stack the deck toward state confusion:

• OEM Windows images ship Fast Startup enabled by default. Most Beelink/Minisforum-class machines arrive with hiberboot on, so an out-of-the-box “shutdown” is S4 from day one. Our 12-cause checklist ranks Fast Startup as cause #2 for exactly this reason.
• The BIOS side has its own state table. Options like Power on from S5 by PME or RTC alarm apply to specific ACPI states; if the OS side is in S4 while you configure the S5 side, both layers can be “correct” and the packet still goes nowhere. The state-by-state matrix is in the S5 wake sources guide.
• S5 and G3 are easy to confuse on wall-wart-powered boxes. A smart plug that cuts AC puts the machine in G3, where nothing wakes it — except, on machines that support it, AC power recovery. Our G3 test confirmed 3/3 automatic restarts on power restore, which is the fallback when WOL is not an option.

If you are debugging interactively, the WOL Troubleshooter tool walks this same order — state, adapter arming, driver, network path — and tells you which step to repeat.

The test protocol we use (and you can copy)

Every WOL article on this site uses the same five-run protocol, and the S4/S5 check is step zero:

1. Record the intended state and how it was entered (shutdown command used, Fast Startup setting, BIOS options). A test without this record cannot be reproduced.
2. Send magic packets continuously from a second device (we used UDP ports 7 and 9 every 15 seconds), so a delayed arming does not read as a failure.
3. Run 5 cycles minimum. Our first S3 series produced 4/5 in early runs; only the fifth cycle exposed the slow-resume outlier (4 min 53 s instead of ~31 s). Single-run results are noise.
4. Capture both machine-side evidence and an external physical record. We pair the command output with phone video of the power LED; when lastwake reports nothing (as in every S5 cycle), the external record is what proves the wake happened.
5. Verify the workload, not the ping. A wake is only useful if the service is back. Hence the 42-second Jellyfin recovery figure for S5 and the 3.6-second figure for sleep — measured on the same machine, same container, same network.

The raw cycle-by-cycle logs — including boot timestamps, lastwake outputs and per-cycle container start times — are in EQi12_S5_WOL_5cycles.log and EQi12_S3_WOL_5cycles.log. Both files can be cited freely under CC BY 4.0.

Common failure patterns this explains

Where this fits in the cluster

• State definitions and BIOS-side wake sources: Wake from S5: PME, RTC Alarm and Wake-on-LAN
• Every other cause of WOL failure, ranked: WOL Not Working: 12 Causes
• The reverse symptom and Realtek driver arming: WOL Works from Shutdown but Fails from Sleep
• Full Windows-side WOL setup: Realtek Wake-on-LAN for Windows
• Planning the whole Windows home-server stack: Windows Mini PC Home Server Roadmap