Autoruns for Windows Demonstrates Startup Process Is Broken
I stumbled across an update for Autoruns for Windows, Microsoft’s sysinternals utility for viewing which processes are executed at startup. It claims the “most comprehensive” knowledge of auto-starting locations of any utility. It then goes on to say
Autoruns‘ Hide Signed Microsoft Entries option helps you to zoom in on third-party auto-starting images that have been added to your system and it has support for looking at the auto-starting images configured for other accounts configured on a system. Also included in the download package is a command-line equivalent that can output in CSV format, Autorunsc.
You’ll probably be surprised at how many executables are launched automatically!
Microsoft Auto-Starting Process Is Broken
Ironically, the existence of this utility, and the three statements made by the developers which are supposed to shine a good light on their utility actually shine a very bright light on a growing and already giant problem with Microsoft operation systems like Windows XP and Windows Vista and one that isn’t likely to get any better under Windows 7.
Every one of these executables and processes that gets launched at startup both slows down your boot time and wastes resources by sucking away memory and threads that could be used by applications the user actually wants to be running. These vampire processes sap your computer of power that it could be using for real work instead of wasting them while waiting for Seaport.exe to find an update to a search program that no one is using!
There are so many nooks and crannies where a developer can hide their auto-starting processes that no user can hope to know them all. From the Startup folder, to registry keys, to Automatic processes, and numerous other places, software that decides it wants to run at startup can find a place to hide from users so that they cannot be stopped from running at startup. This is a major flaw.
The fact that this utility can brag about the “most comprehensive knowledge of auto-starting locations” demonstrates the problem. There are too many auto-start places and some of them are little known. As a user, I should get to decide what does and does not run at any time on my computer, including start-up. Maybe Microsoft wouldn’t have to endure so many horror stories about how long Vista takes to boot or how much longer Windows takes to startup than other operating systems if it didn’t let everyone and their dog (including themselves) throw any process they want to into a users startup process.
If I have a simple task to do on my computer and just need to login and do it quickly, I still have to endure all manner of software pre-loading itself on my computer either to camouflage how slow it is (Adobe Acrobat Reader) or because someone insists it is essential regardless of whether or not I’m actually using it. I’m looking at you Seaport and GrooveMonitor, both Microsoft processes that they have decided MUST run at startup regardless of what I am going to be doing on my computer. Killing Seaport is a pain in the neck that users shouldn’t even have to go through if the software did the right thing at install and asked you if you even wanted it.
The second problem is Microsoft’s continuing insistence on jamming more and more junk into the startup sequence for whatever marketing goal or end reason they can come up with. Things like Seaport and Groove Monitor are just the beginning. Dozens of services are set to automatic despite the fact that they will never be used by certain users. Just shutting down all the extra service MS runs on your home PC as automatic can speed up your start time and computer speed by a lot.
The most laughable part is that we might be surprised at how many executables are launched automatically and the tool provides a way for us to not show Microsoft’s auto-starting executables so that we can see all of those OTHER processes. Either this is a big denial of reality or stunning ignorance. Microsoft is one of the worst offenders of this whole auto-start mess. Which also tells you why, there won’t be a reasonable solution coming from Redmond in the near future.