Why does my macro stop working when Windows is locked/logged out?
Despite our FAQs we get asked a version of the following question at least once a week:
"I just wrote my first macro with Macro Scheduler and it works great but if I lock Windows it stops working, is this a limitation of the trial version".
My most recent answer to this was as follows:
No, it's a limitation of how Windows works. I assume that your script needs to simulate a user (i.e. send keystrokes and/or mouse events and needs to "see" windows).
When Windows is locked or logged out *windows cease to exist* and *there is no input console*. Ergo you cannot simulate a user when Windows is locked or logged out. There is nothing anyone can do about this as that is simply the way Windows works.
A more detailed and technical explanation of this can be found here:
- Why do UI macros fail when I disconnect or minimize the Remote Desktop/Terminal Services session?
- Can I send keystrokes / mouse events when Windows is locked?
Think about it for a second - can YOU use Windows when it is locked or logged out? Of course not. But most people don't realise that when you lock or log out of Windows the user's "window station" literally no longer exists, and applications no longer have UIs. While a process may exist, it has no windows and UI objects simply aren't there. So there's nothing to interact with. Furthermore the only thing that has keyboard/mouse focus is the security console. So you cannot send mouse/keyboard events.
So in short you cannot automate user interfaces when Windows is locked or logged out.
Command line tasks, and tasks that do not need to access a user interface (interact with windows) may still be possible assuming they do not require logged on credentials.
The only solutions are:
- Leave Windows logged in
- If you are running Vista/Windows7/Windows8/Windows8.1/Windows10/2008 Server you can use Macro Scheduler's AutoLogon system. See under Macro Properties. This will log Windows back in on schedule, run the macro, and then log out again.