Why is it that a tool like sysinternals Autoruns might not know the location of a startup?

Question

From the help file for autoruns:

Note: before you send e-mail reporting what you believe to be an auto-start location that's overlooked by Autoruns, please make sure that Autoruns doesn't cover it and verify that the location actually works.

I understand that Autoruns is essentially a list of known startup locations, and this is how it is able to find the startup programs that it finds. What I don't understand is this: if a program starts at startup then Windows has to be aware that the file needs to be run at startup and MUST also know where the location of the startup file is, otherwise it couldn't possibly be run at startup. So why isn't it possible for a tool like this to know the location of startup files in Windows without relying on "known possible" locations? Why aren't ALL of the locations known on a given device?

My question is a "WHY does this work this way" not "HOW can I get around this" question. I have found plenty of the second kind, not the first.

Answer 1

The whole reason Autoruns exists is that there isn't just a single "run at startup" feature with several possible locations. Rather, the startup process has several stages¹ which start different kinds of things, all for different reasons, in their own environments.

For example, drivers are .sys files to be loaded into the OS kernel; services are .exe files to be started in a special way; their lists have to be managed completely differently than the app shortcuts you put in the "Startup" folder. (Not to mention each user has their own Startup folder while there's a single global list for services.)

In addition to this, many of the locations seen in Autoruns aren't even meant to run things on startup, but rather lists of modules used by seemingly unrelated Windows components that just happen to be invoked during startup as well.

• For example, an audio codec .dll file is not something you would consider to be a "run on startup" location – unless Windows is told to play a sound on startup and has to invoke that codec.
• A toolbar addon for MSIE web browser isn't a "run on startup" location – but Windows Explorer used to literally be MSIE in the past, so the addon would load every time you opened a local folder as well.

As a result there are many methods to cause different parts of Windows to run something at various times during the startup process, and there is no single method to ask Windows to produce a list of all of them at once. Autoruns just tries to gather together a lot of lists that have nothing in common with each other (except that they somehow point to some file, which might not necessarily even be an .exe file).

Basically, Autoruns is a malware finder more than it is a startup manager.

Unfortunately, even though it's nowadays found on the Microsoft website, Autoruns is still developed independently from Windows. If there is a new location or feature within Windows that could be used (or abused) to launch something at startup, Autoruns doesn't know this automatically.

---

¹ As a pedantic side note to the "several stages", the most commonly used 'shell:startup' location is not even used during Windows startup as such, it is used during user login – which might even occur hours or days after the OS has finished booting.

Answer 2

The program could have been run by another program. Or could be launched from a scheduled task. It could have been run by a dll loaded by another startup program.

Autoruns can only catalogue "standard" locations for running a program. If the program is then launched by a proxy program or some other tool or system action then Autoruns will have no idea.

Essentially Autoruns only knows about the places that Windows uses to launch programs. If one of those programs installs something that launches the program another way then Autoruns will have no idea.