| Downloads |
|---|
| 41663.zip |
I love the Windows system tray. It displays icons of programs that run in the background, such as my antivirus program and Windows Update. I like knowing that these applications are running. But lately I've noticed that more and more icons are unexpectedly appearing in my system tray. These icons represent programs that seem to monitor my CD-ROM and DVD drives, prevent browser pop-up ads, and magically manage my downloads. I don't remember installing these applications, so what other applications might I have unwittingly installed that don't display icons in the system tray?
I expect an application to launch only when I manually start it, when I add it to my startup directory, or when it asks me whether I want it to start automatically. However, some programs start without my knowledge because their installation programs added them to a registry key that works like a startup directory. You can view the startup directories, but you can't easily see programs that have been configured to start up through the registry. To help manage this madness, I wrote a Perl script that lets you easily manage all applications that run when a user logs on.
The Startup Directories
Users who want a program to run every time they log on to their machines can place a shortcut to the application or a copy of the application in their personal startup directories. Administrators who want a particular application to run for any user who logs on to the machine can place a shortcut or copy of the application in each user's personal startup directory or in the All Users startup directory. These applications can be any type of executable file, such as a program, a batch file, or a script.
When a user logs on to a Windows computer, the OS runs all the applications that are stored in the startup directories. To display a list of these applications, select Start, All Programs (or Start, Programs for older OSs), Startup. The list includes the items in the startup directory for the logged-on user and in the common startup directory for All Users. Typically, you'll find a user's personal list of startup applications in %USERPROFILE%\start menu\programs\startup and the All Users startup applications in %ALLUSERSPROFILE%\start menu\programs\startup.
Startup Applications in the Registry
Some vendors choose instead to add their applications to a registry subkey. Vendors use this approach for several reasons, but in my opinion such applications simply appear to be hiding the fact that they run automatically. Furthermore, spyware often uses this method to install itself on systems.
Several registry subkeys can run programs automatically. (For a list of those subkeys, see Top 10, "Windows Program Startup Locations," December 2002, http://www.winnetmag.com, InstantDoc ID 27100.) However, programs most commonly use the Run or RunOnce subkey, each of which has two versions: one for a specific user and one for All Users. The Run subkey contains a list of programs that run every time a user logs on. The RunOnce subkey contains a list of programs that run only the next time the user logs on. After a program in the RunOnce subkey runs, it's automatically removed from the list; hence, the program runs only once. The RunOnce subkey is used primarily by setup routines that reboot the machine and continue setup after the user has logged back on. The Run subkey for a specific user is HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run, and the user's RunOnce subkey is HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce. The All Users subkeys are HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce.
DumpStartups.pl
DumpStartups.pl helps you manage all the applications that run when a user logs on. The script queries the disk directories and the Run and RunOnce registry subkeys, then displays the programs that are configured to run at start-up and lets the user selectively remove entries. The script relies on several modules and extensions (all of which are free) that might not be installed by default with all Win32 Perl packages. Table 1 lists these modules and extensions, as well how you can obtain them. You can download and install ActiveState's ActivePerl for free at http://www.activestate.com.
Because of space constraints, Listing 1 contains only the callout excerpts. To view the full script, see Web Listing 1 (http://www.winnetmag.com, InstantDoc ID 41663). You can download the script, DumpStartups.pl, from http://www.winnetmag.com. (Enter 41663 in the InstantDoc ID text box, click the Download the Code link, and download the 41663.zip file.)
The code at callout A in Listing 1 loads the Shell32.dll library and exposes the SHGetFolderPath() function, which discovers the startup path both for the current user and for All Users. This code also defines some variables that the SHGetFolderPath() function will use later in the script.
Newer versions of Windows (i.e., Windows Server 2003, Windows XP, Windows 2000, and even Windows NT 4.0 in some cases) have an environment variable called pathext that contains a list of extensions for executable files (with the exception of .pif and .lnk). The code at callout B first determines whether the pathext environment variable exists. If the variable doesn't exist, the script creates a temporary variable and uses default values for the .bat, .cmd, .com, and .vbs file extensions. The code then splits the list of extensions into an array of strings (one string per file extension) and reassembles the strings into one string that contains a pipe character (|) between the extensions. A subroutine later in the script uses the resulting string in a regular expression to determine whether a file is an executable file.
The code at callout C obtains the startup items from the registry and the system disk. The code at callout D then either removes startup items or simply displays the list, depending on which parameters the user specifies on the command line when running the script.
The ProcessKey() subroutine enumerates each value in a specified registry subkey and creates an anonymous hash that contains the value (and other associated information), as the code at callout E shows. The hash is then pushed to the @ValueList array. This array of anonymous hashes is returned at the end of the subroutine.
The ProcessDir() subroutine performs the same function for a startup directory that ProcessKey() performs for a registry subkey—it enumerates each file in a specified directory and all its subdirectories. The script passes the paths to the current user and the All Users startup directories to this subroutine. If the subroutine finds a shortcut file in the directory, the code at callout F uses the Win32::Shortcut extension to discover the shortcut's properties. The script then attempts to discover the shortcut's path (also known as the shortcut's target) and extract the target file's description. When the description is available, the script will display it; otherwise; the script will display the shortcut's filename. Finally, the script pushes an anonymous hash to a lexically scoped temporary array called @ValueList and returns the array to the caller. When the ProcessDir() subroutine finds an executable file (according to the file's extension), the subroutine attempts to extract file information using the same method it used for shortcut files, as the code at callout G shows.
When the user specifies a startup item to be removed, the script calls the Remove() subroutine. This subroutine determines whether the specified startup item is in the registry or is a file on a hard disk, as the code at callout H shows. When the entry is in the registry (as a subkey value), the script removes it from the registry. When the entry is a file, the script deletes it from the system disk. These removals and deletions are permanent. Neither deleted startup files nor deleted registry values go into the Recycle Bin.
The GetSpecialDirectory() subroutine returns the path to a specified (i.e., special) directory. For example, the My Documents directory can be on a local drive or can point to a shared directory on a remote server. This subroutine will discover exactly where this directory is. The subroutine in the code at callout I accepts a CSIDL value. CSIDL values identify Windows special folders (e.g., My Documents, Temporary Internet Items). You can find a list of CSIDL values in the Windows software development kit (SDK) shlobj.h header file. The GetSpecialDirectory() subroutine calls the SHGetFolderPath() function that the script loaded earlier. The script's GetSpecialDirectory() function first allocates a buffer—the $pszPath variable—to hold the path. The path that the function returns is in Unicode format. The script attempts to clean up the buffer by removing all NUL characters (\x00), essentially converting the string to ANSI format.
This pseudo conversion from Unicode to ANSI is a wicked hack for several reasons. If your directory path contains Unicode characters, the subroutine will mangle the path by removing all NUL characters, causing the subroutine to treat the string as ANSI and further processing of the path to fail. The script uses this hack when you're using a version of Perl, such as version 5.8 or version 5.6, that can't handle Unicode and UTF-8 character strings. If you need to support Unicode characters, rewrite this subroutine to support Perl's newer Unicode support.
Running the Script
DumpStartups.pl is easy to run. If you run it without specifying switches, the script simply displays a list of all startup items, each with an index number. To remove a particular startup item, you use the /r switch followed by the item's index number. For example, if you want to remove the third and eighth startup items in the list, you'd type
perl DumpStartups.pl /r 3 /r 8
After the script removes an entry, the indexes might change, so you should rerun the script without parameters to display an up-to-date index list.
The Joy of Control
I typically write scripts to solve problems that I encounter every day. I wrote the DumpStartups.pl script out of frustration and a desire to gain back control of my machines. I run this script every time I install a new software application or component.
