A good developer is a productive developer. I try to cut unnecessary waste of time whenever and wherever I can. It implies utilizing a diverse tool set for improving routine processes.
The first thing I do when I arrive to work is turn on the computer. After waiting for about 3-4 minutes for Windows to boot up, I begin working. That means I spend 13 hours annually doing absolutely nothing. I thought about this and came up with an idea to reduce the wasteful time.
Many utilities claim to speed up the Windows start-up. A lot of articles have been written on this topic as well. In my experience, they are time consuming and not worth the time investment. Some of them are just plainly ineffective. However, I did find one simple approach that made complete sense.
The Windows start-up process automatically starts tens of services and numerous programs. When I turn the computer on, the first thing I do is open a browser and check my email. That is true in 99% of the cases.
Start-up services
Most services and programs that start automatically are irrelevant for browsing the internet. Here are all the services that start automatically:
It is safe to delay start-up for some of them until the browser has been loaded. The question is, what are those services and programs. I did a research to identify non-critical services. A good resource is www.blackviper.com. After learning about each service’s role, I did a trial and error testing by setting services start-up type to “Manual” and rebooting. I identified all the services that could be safely delayed and set their start-up type to “Manual”. The next step was starting the services manually after the browser has been loaded. This is where I “hit the wall”. I run windows with standard user credentials. A standard user does not have a privilege to start a service. It seemed that I would either have to run as an administrator, which was unacceptable, or leave the services default start-up settings. Luckily, since Windows Vista a new service start-up type called “Automatic (Delayed Start)” has been available. As its name suggests, the service starts delayed, depending on the availability of physical resources. The operating system determines when the service will be stared. The user has no control over it. Delayed start seemed to be a good compromise for non-critical services. I modified their start-up type as shown:
I timed the boot up time to see what effect if any it had made. Its improvement was small, which suggest that Windows services are well optimized. Having taken care of services, I moved on to address automatically started programs.
Start-up programs
Identifying programs was much easier. I could have used one of my favorite tools, Autoruns from Sysinternals. I decided to take a more direct approach. I looked into two registry locations:
- HKLM\Software\Microsoft\Windows\CurrentVersion\Run
- HKCU\Software\Microsoft\Windows\CurrentVersion\Run
These locations contain most programs loaded on start-up. They are also listed in “msconfig”, but without the start-up parameters. Unlike “msconfig”, the registry values contain the parameters. That was the reason I looked into the registry directly. Another location I checked was the “Startup” folder. It was empty. No need to worry about it.
Having identified all the programs loaded on start-up, I moved to the next step, delaying their load. Since I am a big fan of scripting, I created a batch file that starts each program sequential after specified time period. Actually, I did not write the script myself. I found it somewhere on the internet long time ago. I made few tweaks to it in order to accommodate my needs. Unfortunately, I cannot find the website in order to give the credit to the script author. The script consists of two files: “DelayedRun.cmd” and “RunApp.cmd”. The first is the main script that I put into the “Startup” folder so that it loads on the Windows start-up.
@echo off SET RUN_APP_CMD="C:\Startup\RunApp.cmd" @echo Starting Microsoft security essentials... call %RUN_APP_CMD% "C:\Program Files\Microsoft security essentials\" MSSECES "MSSECES -hide" 30 @echo Starting VirtualBox guest additions... call %RUN_APP_CMD% "C:\Windows\System32\" VBoxTray "VBoxTray" 15 @echo Starting Executor... call %RUN_APP_CMD% "C:\PortablePrograms\Executor\" Executor "Executor -s" 15
The script invokes synchronously in sequential order “RunApp.cmd” script for each program passing it: program path, process name, executable name with its parameters, and time to wait before invocation.
SET APP_PATH=%~1
SET APP_EXECUTABLE=%~2
SET APP_COMMAND=%~3
SET APP_SLEEP=%~4
"C:\PortablePrograms\Sysinternals\pslist.exe" | find /i "%APP_EXECUTABLE%" > nul
IF {%ERRORLEVEL%} == {0} GOTO skip_run
wait %APP_SLEEP%
PUSHD "%APP_PATH%"
start %APP_COMMAND%
POPD
goto end
:skip_run
echo ...already running...
:end
The script takes the four parameters passed and then checks if the process with the name of the second parameter (APP_EXECUTABLE) is already running. If it is, then it outputs “…already running…” and exits the script. If the process is not running, the script goes to sleep until the wait period specified by the fourth parameter (APP_SLEEP) has expired. Once the time period has expired, the executable with the parameters specified by the third parameter (APP_COMMAND) is invoked.
The script references two additional auxiliary utilities. One is “pslist.exe” from Sysinternals. It is a simple utility that lists running processes. The other utility is called “wait.exe”. I wrote this one myself because I was not satisfied with the existing ones out there. I used “sleep.exe” at first, but the antivirus software would flag it as a virus. Then I switched to using “ping.exe 1.1.1.1 -n 1 -w 60000 >nul”. This approached worked. My problem was the unpredictability of the delay due to ping’s response. On different networks, it would take different time periods to receive a negative response. Writing a simple executable that puts the executing thread to sleep seemed the best solution.
Having four files may seem an overkill considering that there are utilities such as “Startup Delayer” that perform the same functionality. One thing they lack is ability to start a service. My initial idea was to set some service to manual start-up type and then start them using the script. That was not possible due to standard Windows account restrictions. Another “Startup Delayer” or similar utilities drawback is their inflexibility. Scripts are more flexible and adaptable. They require minimum resources and have lower attack surface.
Conclusion
After several days of use, I can report a positive experience with the delayed start-up approach. The simple productivity trick has already saved me tens of minutes and made the boot up process less painful. I am looking forward to implementing it on my other machines as well.
All the necessary files are available for download here.
Next week
Next week, I will discuss exception handling pros and cons in “Error handling”.