My startup script ran at logon and silently did nothing

What I expected

In August my scheduled publishing jobs were running late or not at all, because the laptop they ran on fell into Windows’ Modern Standby whenever the screen turned off. The full story of that night is in another note. One evening job started 38 minutes late, the next never started, and a morning job started three hours late.

The fix was a small PowerShell helper that tells Windows the system is in use while the laptop is on mains power, the way a video player does, without keeping the screen on. It has to be running all the time, so it has to start by itself at every logon.

I wanted a scheduled task with a logon trigger. Creating one needed administrator rights and was refused with “Access is denied”. So I used the simpler route: a tiny launcher script in the user’s Startup folder, which Windows runs at every logon. The launcher’s only job is to start the helper with no window. I expected that to be the end of it.

What actually happened

The launcher ran and did nothing. There was no window, which was intended, and no error message, which was not. The helper was simply not running.

That is the worst kind of failure for this job. The helper exists so that other jobs run on time. If it silently does not start, the laptop goes back to exactly the state that delayed them, and the first sign is the next late or missing run.

Why: the file was saved in the wrong encoding

The launcher is a VBScript file, run by Windows Script Host. The helper lives in a folder whose name contains non-English characters, so the launcher contains that path.

Windows Script Host decides how to read a script file from its first bytes. If the file starts with a byte-order mark for UTF-16, it reads it as Unicode. If there is no mark, it reads the file in the system’s legacy code page. My launcher was saved as UTF-8 without a mark, which is what most modern editors and tools produce by default. Read in the legacy code page, the non-English part of the path turned into different characters. The launcher then tried to start a file at a path that did not exist, and failed without saying so.

A second trap sits right next to it. The helper itself is a PowerShell script, and Windows PowerShell 5.1 also reads a file without a byte-order mark in the legacy code page, which garbles non-English text inside it. But the encoding it wants is different:

File	Runs in	Without a byte-order mark, it reads	Save it as
Launcher (.vbs)	Windows Script Host	Legacy code page	UTF-16LE with BOM
Helper (.ps1)	Windows PowerShell 5.1	Legacy code page	UTF-8 with BOM

If you save both with one rule, one of them breaks. That is the warning I left in the helper’s documentation: check the encoding every time either file is edited, because the failure is silent and easy to miss.

What I changed

• The launcher is saved as UTF-16LE with a byte-order mark, and the helper as UTF-8 with a byte-order mark. The documentation next to the scripts says which is which, and why.
• The log is the check. The helper writes a line when it starts and when mains power is connected or disconnected, so a healthy day is one or two lines. After a logon, the first thing to look for is a new “started” line.
• Only one start method. A scheduled task with an administrator shell would also work, but running both would start two copies. The Startup folder launcher is the one in use, and removing that file is how to turn it off.

While writing the same helper, I hit three more traps worth passing on: a parse check reported the script as fine when a line break between a closing brace and else still broke it at run time; a large hexadecimal constant was read as a negative number; and a command meant to stop the helper by matching its command line also matched, and stopped, the shell running that command. Those three at least failed loudly. The encoding one did not, which is why it gets its own note.

What this has to do with hiring someone

If a freelancer builds anything that runs on your own Windows machine, such as a helper, a watcher or a local script started by the scheduler, this incident suggests three things for the brief and the acceptance test.

Test the real trigger. Double-clicking the launcher proves the script works when you start it. It does not prove Windows starts it at logon. Ask for a real restart and logon as part of acceptance, which is check 2 in the acceptance checklist for unattended jobs.

Make “nothing happened” visible. A start-up line in a log costs nothing and turns a silent failure into an obvious one. The maintenance guide asks for a readable log for the same reason.

Ask about encoding when names are not plain English. Folder names, user names and text in other scripts are common outside English-speaking countries. A builder who has seen this will know the answer right away. Put it in the acceptance section of the workflow automation brief.