Wake-on-LAN from Sleep Versus Shutdown: Test Both

A PC that wakes from sleep is not automatically qualified to wake from shutdown. Test every power state required by the installation on the actual PC, firmware, network adapter and Windows release. Record whether standby power remains available. Wake-on-LAN is a hardware and operating system interaction, so one successful packet test cannot establish support for all states.

Name the state precisely

Operators often call a dark screen “off,” but the computer may be sleeping, hibernating, in hybrid shutdown or fully shut down. Microsoft's system power states reference distinguishes sleeping states from S5 shutdown. A loss of mains power adds another condition that must be evaluated independently.

Microsoft's WOL behavior article describes important Windows shutdown behavior for the releases it covers. Treat its version scope carefully and confirm current OEM guidance for the deployed Windows 11 or Windows 10 system; it does not certify every motherboard or adapter.

Establish a local baseline

Keep the sender on the same approved network segment for the first test. Confirm the target adapter's actual wired MAC address and documented wake settings. Record the firmware version, NIC driver and whether the Ethernet link remains present in the required state. A link indicator is helpful but does not prove that wake logic is armed.

Use Microsoft's powercfg reference for the available sleep and wake diagnostics:

powercfg /a
powercfg /devicequery wake_armed
powercfg /lastwake

Not all devices or power models expose identical information. Preserve the output rather than using an empty result as an automatic diagnosis. If no supported sleep state exists, do not invent one by applying undocumented registry changes.

Run the state matrix

• Save open work and confirm a safe maintenance window.

• Enter one documented state and wait for the PC to settle.

• Send the approved magic packet once, recording sender and time.

• Check physical wake, operating system readiness and application readiness separately.

• Repeat after returning to a known operating state.

• Move to the next required state, keeping the network path unchanged.

If sleep works and shutdown fails, investigate firmware, standby power, driver and shutdown behavior before changing routers. If neither works locally, a routed relay will not fix the target's inability to wake. Conversely, a state qualified locally can still fail across VLANs because the packet does not reach it.

Handover the supported workflow

For each trial, record the exact entry action, wait interval, packet sender, wake result and time of the first valid device response. Keep an unsuccessful trial in the same table. This prevents a later technician from mistaking desktop appearance for a fully recovered controller.

The accepted daily closing action should match the state that was actually tested. Do not instruct staff to use shutdown if the design only proves sleep resume. Record what happens after someone unplugs the PC, replaces its network adapter or updates firmware. A replacement PC needs its own acceptance run.

Accept the configuration when every required state reliably reaches the intended ready condition under the agreed repetitions and observation period. Keep unsuccessful states visible in the handover rather than describing WOL as a single yes or no capability.

Use Wake-on-LAN troubleshooting for general packet and configuration checks, and WOL across VLANs after local state behavior has been established.