Msconfig

[scissorhands7]

"Never use MSConfig to disable startup programs no matter what others have recommended. MSConfig is for troubleshooting purposes only. If you use it to disable startups and then run the program, you may cause what is known as a memory leak which does all sorts of strange things to your system. And disabling programs and services with it can get you into trouble that only a repair install can get you out of. Please note the warning found on the Microsoft site concerning MSConfig.. Instead, use one of the following startup managers."

This quote was posted in a forum that had been locked up above. I do have an issue with this.

This possibly has to be one of the most bogus paragraphs I have ever heard.

Msconfig is an excellent tool for startup programs. It's very reliable. If worst comes to worst and you turn off a program that is essential to your login. (there are very few if ever any of these) then simply go to safe mode and turn it back on using the same method.

You won't get a "memory leak"

You don't need to clog your system with a program that does what windows essentially already does.

[Matt]

If you would be so kind as to support your claim, I'd be happy to reconsider the post.

[scissorhands7]

I have to ask you to do the same as it is your bizarre claim that is being constantly cited on the internet forums as proof.

XP is an extremely stable operating system and most if not all of its problems are well documented with workarounds on the Windows site.

Please post an article from the site confirming your claims.

Do tell where you got your info that msconfig causes "memory leaks" and please go onto define "memory leaks"

Msconfig isn't some random utility. It just maps string values from the following registry keys which are nothing more than shortcuts to the program. I should know I've managed to magically make my own entries and there haven't been even the slightest memory leaks on my system. Additionally I don't even fully understand what you are implying by "memory leaks"

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

And it maps shortcuts from the following folder:

C:\Documents and Settings\USER NAME\Start Menu\Programs\Startup

The mistake you are making is thinking there is some magical complex process to starting applications on startup which is ridiculous (unless I'm completely wrong and there's Microsoft Data on this but I've done a lot of looking for those articles but haven't been able to find anything of the sort)

[Pete_C]

Calling it a memory leak was a misnomer; but it was often the easiest way to get beginners to visualize the potential of creating a problem.

Why you should not use MSCONFIG to control startup entries in XP

http://forums.majorgeeks.com/showthread.php?t=149804

If you have been using MSConfig as a startup manager please read this.

http://support.microsoft.com/kb/310560

The first method you should always try is to see if the application itself has an entry under edit / preferences or tools / options or a similar location to control its startup behaviour. The software author knows his product better than anyone else; and he went to a lot of extra effort to include these entries if they are there. You must therefore consider that he may know what he is doing (if not why do you use his product) and included these for a specific reason (rather than just a note in the readme.txt file or help file telling you to type msconfig and uncheck the entry there).

Back in the days of DOS, you had to add a line in say the autoexec.bat file to launch something on startup. You could just rem out that line and it would not start ; or delete it since you probably knew what it was and could add it back if you wanted.

But gradually windows became more complex. Win95; 98 ; and ME not only use the autoexec.bat , and files like config.sys and system.ini but primarily use a registry consisting of two files user.dat and system.dat. This makes controlling startup entries more complex; but since most programs just put in one run entry in the registry ; disabling that with a startup manger or msconfig generally was enough (although some you really should also check the system ini files and autoexec.bat especially with things like antivirus and firewall applications). Just unchecking the msconfig entry leaves the possibility of overlooking components which continue to run invisibly , eating up resources and often not allowing the resources of the associated program to be released and reused if you open the program and then close it ( a Memory Leak, or at least one variety ).

But Windows continued to get more and more complex. XP does not use just two files to save and open the registry. The XP registry is built from scratch each time you boot based on five or more hive (.hiv) files ; of which the msconfig startup entry HKLM_run is just one of many places an application may load components. In fact; generally an application loading at startup loads different components at different times during the boot sequence based on which hive the entry is in. Some may load before you log in , some after. In addition there are many other places (Services, SSODL entries , etc) where a program may include startup entries which may not show in your registry; but will nonetheless load components of the application . Thus it is not adviseable to use simple techniques like unchecking MSCONFIG entries ; you may not have disabled as much as you think.

Startup managers; like codestuff starter tend to be more "complete" in their dealing with an application and its "dependencies" but you should still check first to see if the author included control options in his application. (Tip, with Code Stuff Starter, you can "edit" startup entries to move them from the Current User- which loads after you login - to All Users which loads before to speed up how quickly you can use things after the desktop loads).

Yes, there are still programs out there which do not really install. You could just copy their folder to a removable drive and run it from there on any computer; and there are still programs out there which only have the single registry entry. Generally you can recognize them because they have no option in the program itself to control startup (big surprise that if the author does not think there is a need to include this extra work you generally can just uncheck the entry). And yes; it is not always disasterous to incorrectly disable a programs startup. But if you are trying to improve performance; it is best to do things correctly.

In XP I strongly advise against disabling anything using MSCONFIG. While in older versions of windows there was a single registry used by all users and the startup entries were just one location which you could check and uncheck in msconfig with relative safety ; this is no longer so.

IN XP the registry is built from scratch each time you start up based on five or more files called hives which load at different times during startup. Some do not load until you login with your username and password. The MSCONFIG entry is just a single place where a program may enter startup entries. It could have appinit dlls, ssodl entries, windows service entries, scheduled tasks, and several other startup entries ; all designed to load different portions of the application at specific points during windows bootup. MSCONFIG disables just one of these. This can lead to far worse problems than the one you are attempting to combat. So please unless specifically told to do so as part of a trouble shooting proceedure by someone who actually knows what they are doing do not disable anything with msconfig.

The proper way to disable startup entries , whenever present , is to use the applications own edit/ preferences or tools/ options. The author went to a lot of extra effort to include these entries and did so for a specific reason.

So the best thing to do is to look in the system tray at lower right.

Any of the programs running there at startup? Check to see if they have an edit/preferences or tools/ options entry or other method included in them to control their startup behavior. If so , use it.

You can also check in the start/ programs / startup folder

If you find an entry there for something which does not include a method of controlling startup within the program itself, go and move them out of it by dragging and dropping them into their own folder.

Now, I know that there are thousands of people out there who have disabled thousands of startup entries using MSCONFIG without ever noticing any performance hit, startup delays etc.

However, often those who use MSCONFIG as a startup control refuse to even acknowledge the possibility that they could be making a mistake and when they experience problems later on attribute it to "bitrot" or "the normal need to reinstall windows every year" rather than conceed that it is possible that they themselves contributed to the bitrot and degredation of windows by only partially disabling a program they thought they had disabled by unchecking the last entry in its loading sequence or maybe the first.

The bottom line is that you can no longer depend on MSCONFIG to completely disable an application startup. While you may not notice any problems, you may none the less be causing them.

[scissorhands7]

I really appreciate those links Pete.

However I still have some issues with what is said on the MajorGeeks article and how it is very misleading.

1. In both WIndows Article cited, it does not say that msconfig causes memory leaks at all. In fact it states something of the former. In this article that was cited it says:

"Method 2: Use a registry key to modify the list of programs that run when a Windows XP Home Edition-based computer starts

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 (http://support.microsoft.com/kb/322756/ ) How to back up and restore the registry in Windows

If you want to modify only the list of legacy programs that run at Startup, use Registry Editor. To do this, follow these steps:

Start Registry Editor, and then locate one of the following registry keys:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

If you do not want a program to run at Startup, find that particular program, and then delete its entry from one of these registry keys.

You can add entries here also. But we recommend that you use the Windows Run at Startup policy setting to add programs that you want to run at Startup."

http://support.microsoft.com/kb/270035/

2. Msconfig does list all startup entries. As I said previously it maps the following registry keys listed above and the following file system folder. A program can't startup in Windows without being either in those two windows registry entries or on the startup folder (or the runonce startup entries that are right next to those in the registry).

3. "from scratch each time you boot based on five or more hive (.hiv) files ; of which the msconfig startup entry HKLM_run is just one of many places an application may load components. In fact; generally an application loading at startup loads different components at different times during the boot sequence based on which hive the entry is in. Some may load before you log in , some after. In addition there are many other places (Services, SSODL entries , etc) where a program may include startup entries which may not show in your registry; but will nonetheless load components of the application . Thus it is not adviseable to use simple techniques like unchecking MSCONFIG entries ; you may not have disabled as much as you think."

I acknowledged all entries where programs run from these are only the HKLM and the HKCU hives. Microsoft advocates a simple thing as deleteing a string value. So I did test. I created my own string value in the startup registry for a notepad program. I then opened the msconfig utlility to find notepad exe listed as the registry value I had just put in. I unclicked it and clicked "Apply". I then went to the startup registry entry to find that the notepad.exe string had been deleted.

If you clearly look at the MSCONFIG startup tab you should notice that each entry has a registry value listed next to it. This is self indicative that using msconfig is simply a shortcut to the registry entries and startup folder I mentioned.

4. "MSCONFIG entry is just a single place where a program may enter startup entries."

Then you are absolutely completely mistaken. Msconfig only mirrors Registry values that I mentioned and the startup folder. Its ridiculous to suggest that its just a separate entry. If you need me to I can show you screencap by screencap how this isn't so.

[Matt]

I'm leaving this up to Pete_C. He has the authority to edit that post if he so wishes. As of right now, he's got a stronger argument in my opinion. Convince him, not me.

[Pete_C]

You can lead a horse to water but you should not feed a troll.

Some people just do not listen or read or pay attention and just want to argue.

[flashh4]

Hey guys, i would sure like to see scissorhands7 post this on a bunch of the HJT sites that clean

comps of Malware. Sure would make for some interesting reading !

Any for what its worth, i agree with Pete !!!!!

Chuck

[shanenin]

I use msconfig out of laziness. I don't feel it causes much for problems. With that said their are better ways of doing it.

[Pete_C]

I agree that in most cases there will be no problems.

But anyone who actually spends time dealing with malware infections soon realizes that there are so many more places that applications place startup entries that they must question the consequences of just unchecking the one program start entry in MSCONFIG when there are startup entries from the same application in many other locations.

If the applications author did not take into account the likelihood that users would not read the help file and would not follow the proper methods laid out in tools/ options or edit / preferences of the application , and have entries located in other locations check in with the components present in msconfig then you could have issues.

Lets say you have an automatic updater component which runs independently of the application itself (say as a scheduled task, or a service) , you disable the application but not the updater.

Now the updater launches and it tries to access a component of the application which is not loaded? Does it have authority to launch the application? Or does it freeze and run up your svchost.exe cpu usage? (common problem , svchost.exe running at 100% cpu usage because of an updater jammed in this manner) .

Or it tries to update the database, but the database is protected unless the application is running?

Many scenarios exist where this causes big problems.

The old "memory leak" was a misonomer used to simplify the explanation of the limits of memory management in DOS based versions of windows where there was a single 64KB page of RAM used for keeping track of input and another for keeping track of output (system resources and user resources). When either of these pages got filled, you were given an out of memory error. Occasionally if you disabled something in msconfig; you could have an instance where the entry was still active in the resouce page taking up memory, and if you tried to launch the application it was granted another entry. Once in a rare while, this could multiply when you repeatedly opened and closed the same application until it filled the page and you had to reboot the computer to recover your resources. While not truly a memory leak, that was the common term used to refer to this problem.

Now, the NT based memory manager in XP and Vista is far more advanced than the old DOS based two page model used in Win95, 98, ME.

Here, each and every application and device is allowed to think it has a full 4GB of RAM addresses all to itself; the windows memory manager remaps those on the fly to actual RAM and swap file addresses and is not limited to a single 64KB page of memory to keep track of input and output.

The bottom line is that because it could create problems which have actually occurred and been traced to such methods; it would be unethical to recommend that people routinely use msconfig as a startup manager.

Now if they choose to take the risk themselves; all you can do is tell them that you do not recommend this approach; that there are reasons behind your decision to consider it risky and that they should remember that if they experience problems that they should consider that this may be the cause and should be thoroughly investigated as part of the fix.

[shanenin]

Lets say you have an automatic updater component which runs independently of the application itself (say as a scheduled task, or a service) , you disable the application but not the updater.

Now the updater launches and it tries to access a component of the application which is not loaded? Does it have authority to launch the application? Or does it freeze and run up your svchost.exe cpu usage? (common problem , svchost.exe running at 100% cpu usage because of an updater jammed in this manner) .

Or it tries to update the database, but the database is protected unless the application is running?

Many scenarios exist where this causes big problems.

Being a novice programmer/scripter(I have not done any in a couple of years), I can appreciate unexpected consequences(bugs). The point you make is a good one. With that said, won't any third party startup manager cause those same problems? Short of doing it from within the authors program, I think all other methods would cause odd bugs.

[jcl]

Being a novice programmer/scripter(I have not done any in a couple of years), I can appreciate unexpected consequences(bugs). The point you make is a good one. With that said, won't any third party startup manager cause those same problems? Short of doing it from within the authors program, I think all other methods would cause odd bugs.

True, and you'd be working around bugs in a program that shouldn't exist in the first place.

[Pete_C]

Being a novice programmer/scripter(I have not done any in a couple of years), I can appreciate unexpected consequences(bugs). The point you make is a good one. With that said, won't any third party startup manager cause those same problems? Short of doing it from within the authors program, I think all other methods would cause odd bugs.

True, and you'd be working around bugs in a program that shouldn't exist in the first place.

So true indeed; but unfortunately the bugs do exist and all to often are ignored.