12

In Windows 10, I would like to know how I can tell in a script whether the system booted because it was turned on by receiving a Wake-on-LAN (WoL) packet, or because it was turned on because of pushing the power button.

I did find the WakeUpType property of the Win32_ComputerSystem class. That is documented to return the "event that causes the system to power up". There are 9 possible return values, one of them being "5" (meaning "LAN Remote").

Unfortunately, on my system it always seems to return "6" (meaning "Power Switch"):

PS C:\WINDOWS\system32> echo $(Get-WmiObject -class win32_computersystem).wakeuptype
6

I noticed that after putting the system to sleep and waking it using WoL, Windows posts an event in the System eventlog with source "Power-Troubleshooter" and event ID 1, containing the text:

Wake Source: Device -Intel(R) 82579V Gigabit Network Connection

Also, powercfg /lastwake reports the NIC as the reason for waking up. So, at least when waking from sleep Windows is able to determine that it woke up because of a WoL packet, even though the WakeUpType property still returns "6" (Power Switch) in that case.

Unfortunately, when the system receives a WoL packet in S5 state it will properly power up and boot, but I can't tell that it booted because of WoL. powercfg /lastwake shows exactly the same output as it does when the system powers on from S5 because of pushing the power button:

C:\WINDOWS\system32>powercfg /lastwake
Wake History Count - 0

How can I reliably tell, from any power state (up to S5), that the system powered on/woke up because of WoL?

030
  • 5,731
  • 12
  • 61
  • 107
Jurjen
  • 373
  • 1
  • 3
  • 10
  • I'm afraid it's a network card driver issue. I've been hitting somewhat similar issue with Windows 10 - while the computer reacts to WoL perfectly fine when it's powered off, it doesn't react at all if it's put into hibernation, meaning that the network card driver code is not prepared for that. If you can find different (newer?) version of the driver, this might solve your issue. Apart from that, I'm afraid you're done for. – StanTastic Mar 04 '16 at 09:14

2 Answers2

2

My approach would be to use dmidecode which will read data from the BIOS, with something like

dmidecode | findstr /R /C:"Wake-up"

Similarly to feitingen's answer to this question

If that doesn't work then your hardware must not be properly recording that value.

Community
  • 1
fusorx
  • 121
  • 7
1

Maybe you can setup a script (or a software) to track the event on the PC that SEND the WOL packet.
This script could write something (the current date/time?) in a file somewhere (on a network share?) and then the just-woken-up computer could check this shared file, and determine if it has been powered up by a WOL packet.

Max
  • 153
  • 2
  • 7
  • Thanks for the -1, but a comment explaining why my (yet alternative) solution is bad, would be more useful... – Max Feb 17 '16 at 08:14
  • 1
    I don't know who gave the -1 (it wasn't me), but I can explain why your suggestion won't solve my problem: the device sending the WoL packet is a Steam Link. In other words: a device I have no further control over and cannot run scripts on, sends the WoL packet. – Jurjen Feb 18 '16 at 18:41
  • @Jurjen thanks for the explanation, as of today I can't imagine a simple and practical way to solve your issue... (teorically you could use my proposed solution with a second PC, that is only waked up via WOL, so that SteamLink wake up PC1, then PC1 take note somewhere on a shared drive (on a NAS?) then PC1 wake up PC2 (the PC of you question) then PC1 turn itself off, then PC2 check the shared drive to check if it has been waked up by WOL pachet from PC1 (and so from SteamLink)... it could work, but it's complex, and you need another PC... – Max Feb 18 '16 at 20:57