You shut the desktop down after dinner, open a wake app from the couch, and the machine stays dark. Ten minutes earlier the same PC came back from Sleep on the first try. The cable never moved. The switch lights still blink. Wake on LAN from Windows looks broken, but you never touched the adapter settings.
Sleep and Shut down are not the same electrical condition. One leaves the network card armed. The other, especially with Fast Startup, often does not. The useful path is the power state first, then firmware, then the packet, instead of flipping the same checkbox again.
How Wake on LAN Gets a Sleeping PC Back Online
That couch test is more informative than another trip through Device Manager. If the PC answers from Sleep and ignores Shut down, Windows is not sitting there waiting for a request. The Ethernet adapter stays on a trickle of power and watches frames for a pattern called a magic packet.
AMD and Hewlett-Packard built that idea as Magic Packet technology in the mid-1990s. AMD's proposal, from November 1995, described a networked PC that stayed attached to the LAN in a low-power state while the adapter watched incoming traffic for a distinctive wake pattern. A remote computer could start the machine without anyone at the power button. Wake-on-LAN's documented history still defines the pattern that matters: it begins with 6 bytes of hexadecimal FF, then 16 consecutive repetitions of the target adapter's MAC address. A MAC address is 6 bytes, so the repeated field occupies 96 bytes, and the identifying pattern is 102 bytes before any extra frame data.
Why firmware still does the listening
Industry pickup followed fast. IBM and Intel created the Advanced Manageability Alliance in October 1996, and the alliance adopted Wake-on-LAN in April 1997. Magic Packet technology debuted in the PCnet-PCI II Ethernet controller and was folded into Microsoft's OnNow networking and power-management work. Its place in the mid-1998 release of Windows 98 moved remote PC access into ordinary hardware.
Current Windows machines still depend on adapter firmware and motherboard power circuitry, not a Windows process that stays running. If the board cuts standby power, no phone app can invent a listener.
A machine that never reaches a powered network port is a different failure from a card that is listening and ignoring you. MacBook power problems and repair options is a useful contrast when a computer looks dead before any packet is involved, because a dead power path and an unarmed NIC are not the same job.
Check power before settings: If Sleep works and Shut down does not, name the power state before you edit the driver again.
Start with three checks:
- Link power: Watch the NIC LEDs after Sleep and again after Shut down.
- Firmware arming: Confirm the UEFI wake option, and look for a deep-sleep mode that kills the port.
- Same LAN: Keep the sender and the target on one switch until local wake is proven.
Checking Hardware and Recording Your MAC Address
Wired Ethernet is the predictable path. Wireless wake is hardware- and driver-dependent, and it fails in ways that look like a bad packet. Plug the target into a switch port you can see, then write down the MAC of that exact adapter before you change a single setting. The magic packet is built from that address. A Wi-Fi radio, an old USB dongle, or yesterday's dock will send a perfect packet to the wrong piece of silicon.
Walk the cable before you trust the address
Power the PC on and look at the port. You want a link LED on the computer and a matching LED on the switch. Shut the machine down, or put it to sleep, and look again. A dark port means the card has no standby power, so later software tests are wasted.
Docks and USB Ethernet adapters sit in the middle of this path and change the address on the wire. A laptop that wakes on the desk cable can go silent on a USB-C dock because the dock presents its own MAC, or because that USB path drops wake power. If you test both, record both addresses and label which cable they belong to.
The switch matters for the same reason. A managed switch that isolates ports, or a VLAN you forgot about, keeps a broadcast from the sender even when both LEDs look healthy. For the first evening, use one small unmanaged switch or two ports you know share a broadcast domain.
Keep the address where the sender is
Open a command prompt on the target and run getmac /v, or read the MAC from the Ethernet adapter's status page. Copy it with the colons intact.
Then put it on a sticky note next to the laptop or phone you will send from. Every trial needs that same string, and hunting through adapter properties while the target is asleep is how people test the wrong NIC for twenty minutes.
Write the MAC, the switch port, and whether the machine is on a dock. Those three lines solve more "it used to work" cases than a new wake app.
Enabling Wake Settings in UEFI and Device Manager
Wake on LAN from Windows is a stack, not a checkbox. Firmware has to leave the adapter powered. The driver has to arm magic-packet detection. Windows has to allow that device to wake the computer. Intel's Ethernet support notes also flag BIOS, the operating system, firewall and antivirus software, and the router as things that can block an otherwise correct setup.
Firmware first, then the driver
Restart into UEFI or BIOS. Vendor names differ: Wake on LAN, Power On by PCI-E, Resume by LAN, or a similar line under power management. Enable it, and disable any ErP or deep-sleep option that removes standby power from the onboard NIC. Save and boot back to Windows. If this layer is off, Device Manager cannot talk the motherboard into listening.
A short walkthrough of the Windows side is easier to follow on screen than as a list of tab names.
In Device Manager, open the Ethernet adapter, not the Wi-Fi radio.
- Advanced. Set Wake on Magic Packet to Enabled. If the driver offers Shutdown Wake Up or a similarly named option, enable that too. It is the control that tries to keep the link armed after the machine leaves Windows, and not every NIC exposes it.
- Power Management. Enable Allow this device to wake the computer. Prefer Only allow a magic packet to wake the computer when that box exists. Microsoft's guidance supports that restriction so ordinary traffic does not pull the PC out of sleep at 3 a.m.
- Leave directed-packet wake off unless you have a specific reason. A directed packet is a different trigger from the magic pattern, and turning it on widens what can wake the machine.
What each layer actually controls
UEFI decides whether the board feeds the NIC when the operating system is gone. The Advanced tab tells the driver which pattern to honor. Power Management tells Windows that this device is allowed to raise a wake event. A firewall rarely blocks a same-LAN broadcast the card reads in hardware, but security software that disables the adapter in low-power states will. Change one layer, then test Sleep, before you touch the next.
Which Power States Support Wake on LAN in Windows
Identical adapter settings produce opposite results because the machine is not in the same state. Microsoft's network-driver documentation treats Wake-on-LAN as the adapter detecting a special Ethernet packet and raising a wake event. Standard driver support looks for a magic packet with 16 contiguous copies of the adapter's Ethernet address, 96 bytes of repeated MAC data. The same documentation lists S3 sleep and S4 hibernate as supported states, and states that Wake-on-LAN is not supported from Fast Startup or the S5 soft-off state.
On Windows 10 the default shutdown path is hybrid shutdown, also called Fast Startup. That path places devices into the D3 power state. A desktop that wakes from Sleep can therefore ignore every packet after you choose Shut down, even though the screen looks equally black.
Modern Standby is a different map
Microsoft's client troubleshooting notes add the machines that never use classic S1 through S3. Modern Standby systems stay in a connected low-power mode, and Microsoft says that mode natively supports magic-packet wake. USB-attached wired LAN devices can still lose wake capability during a Device-S4 transition, which is why a dock that works at the desk fails after a long sleep.
Do not keep re-enabling Wake on Magic Packet when the underlying variable is Fast Startup, a USB Ethernet dongle, or a dock. Identify the state, then test it.
| Power state | Wake on LAN support | What to check |
| S3 sleep | Supported when the NIC is armed | Link LED stays on, magic-packet wake enabled |
| S4 hibernate | Supported in some configurations | Hibernate was chosen on purpose, not via Fast Startup |
| Fast Startup | Not supported, adapter often not armed | Hybrid shutdown is the default Shut down path on Windows 10 |
| S5 soft-off | Not supported by standard Windows WoL | Only test if firmware exposes its own wake-from-off path |
| Modern Standby | Native magic-packet wake, platform-specific | AC power, and whether the LAN path is USB or a dock |
A green "Allow this device to wake the computer" box does not arm a card that Windows already placed in D3.
Sending and Verifying a Magic Packet on Your LAN
Configuration only counts after a packet you can see produces a wake you can count. Put the sender on the same switch as the target. Routing, VLANs, and phone apps that "work over the internet" will confuse the first test.
Microsoft's adapter power-management reference describes the pattern Windows drivers match: the hardware address repeated so the card can recognize itself with no IP address and no application message inside. You already have that 102-byte layout. The sender only has to wrap it and put it on the wire toward the local broadcast.
A staged test, not one lucky click
- Sleep first. Confirm the link LED, send one packet, and wait. A wake here means the MAC, the driver, and the same-LAN path are good.
- Repeat before you trust it. Run at least 10 attempts for that state. Log wakes and misses. Vendor docs describe requirements and failure modes, not a universal success rate, so your own tally is the only honest number.
- Hibernate as its own row. Do not mix those results with Sleep.
- Shut down last, and only if firmware and the adapter expose wake-from-power-off. If Sleep is 10 for 10 and Shut down is 0 for 10, you have a power-state result, not a bad app.
Separate a silent sender from a deaf target
If nothing wakes, do not change UEFI yet. Capture on a third machine on that switch, or check whether the switch still lists the target's MAC after sleep. A missing frame means the sender, the utility, or the port. A frame that arrives while the PC stays down means the target is unpowered or unarmed.
Intel's adapter wake options split Wake on Magic Packet from Wake on Directed Packet, and warn that turning both off while Reduce speed during standby is active can remove power from the adapter. That combination looks like a network failure but is a power policy.
Keep the first ten trials on one switch. Once those numbers are written down, you know whether a later failure belongs to the PC or to the path between rooms.
Comparing Native Ethernet and UDP Wake Methods
Two transports carry the same payload, and they fail in different places. MikroTik's Wake-on-LAN utility notes describe a native Ethernet frame that uses EtherType 0x0842 and the broadcast destination FF:FF:FF:FF:FF:FF. They also describe a UDP alternative sent to 255.255.255.255 on port 9 when you do not name a specific interface. The Windows sender and the receiving gear do not need the same utility. They do need a broadcast method both sides can deliver, plus the right interface or port.
What you are choosing
Native Ethernet stays inside the Layer 2 segment. The card is matching a frame, not opening a socket, so this is the cleanest way to prove the target. You will not cross a router with it. That limitation is the point during the first evening.
UDP to the local broadcast is what most phone apps and small Windows utilities send. Port 9 is a convention for the sender and for anything that filters UDP. The sleeping NIC is still looking for the FF pattern and the repeated MAC, not for a listening service. UDP becomes attractive only after local Ethernet wake is already proven and you need a tool that cannot emit a raw frame.
How to pick for the network in front of you
Use the native frame when both machines share a switch and you can choose the interface. Name that interface. A laptop with Wi-Fi and Ethernet will happily transmit on the wrong one while you stare at the desktop.
Use UDP on port 9 when the only sender you have is an app that wraps the payload that way, and keep the target on the same broadcast domain. If a router sits between them, UDP does not magically become reliable. Directed broadcasts are often disabled, and a consumer router will drop 255.255.255.255 at the WAN side.
The sender and the network have to agree. A tool aimed at port 7, a firewall that drops outbound UDP, or an app bound to Wi-Fi while the target is on Ethernet, all produce a quiet PC and a confident "packet sent" message.
NeoTeo's practical tutorials and tool write-ups are one place to compare wake utilities and follow a structured test, next to the vendor docs for your NIC, rather than treating any single app as the fix.
Remote Wake Limits and Your Next Practical Step
People fold three jobs into one phrase. Same-LAN wake is the test you just ran. Wake across routed subnets needs a relay or a router that will turn a directed broadcast into a local one, and many home routers will not. Internet-triggered wake adds address translation, a changing public address, and a machine that must stay electrically alive with no one home. Those are not the same feature with a longer cable.
Wireless makes the gap wider. The adapter has to stay associated and powered, and that support varies by card and driver. Microsoft's platform notes on Wake on LAN) state that Wake on LAN depends on hardware, driver, and platform-specific low-power capabilities, and that Surface wake from Modern Standby requires AC power plus a Surface Ethernet adapter or dock on a wired network. A laptop on battery and Wi-Fi is not that setup, no matter what the app promises.
Why port forwarding is the wrong default
A magic packet is not an authenticated login. Forwarding a UDP port from the internet toward your LAN publishes a broadcast that any sender who learns the MAC can emit. Carrier-grade NAT, a firewall that drops unsolicited inbound traffic, and a MAC-to-port table that ages out while the PC sleeps all make that path flaky as well as loose.
Prefer a machine you already trust on the LAN, or a VPN that lands you inside the broadcast domain, and send the packet from there. Test that relay with the same ten-shot log you used locally. If Sleep is solid and Shut down is not, a VPN will not repair Fast Startup.
Run the local Sleep log tonight, then the shutdown log, and write both down. Only a PC that already wakes on your own switch deserves a remote path, and only through a relay you can turn off.
NeoTeo publishes practical technology tutorials, tool notes, and step-by-step guides for PC and network problems like Wake on LAN from Windows, including the power-state and testing details that checkbox lists skip. If you want more hands-on hardware and networking walkthroughs in the same style, visit NeoTeo and browse the latest tutorials.
