I've encountered a strange issue - I can't launch Visual Studio, nor run simple commands from command prompt, seemingly due to my PATH variable being too long. Now that I look at it, I see that many companies have added their install directories to the PATH variable.

I was wondering why these companies added their folders to the path (perhaps to make it simpler to execute their programs?), and which are necessary and which I can delete. If I delete some of them, will I not be able to launch the programs? (Here's what currently exists in the path)

  • 1
    I really don't feel like that's a particularly long PATH... What leads you to suspect that it's too long? Is VS throwing down some sort of error? Also, what version of Windows are you running?
    – bosco
    Aug 22, 2013 at 2:06
  • @bosco I suspect it's too long because command prompt can't find simple commands such as ping. Also, it seems that this isn't uncommon with visual studio. It was also mentioned here that the limit for the PATH using command line is around 2000.
    – CC Inc
    Aug 22, 2013 at 2:11
  • Visual studio 2012 throws the error "Exception has been thrown by target of an invocation" on startup. And when I looked in the ActivityLog.xml, it told me The type initializer for 'Microsoft.VisualStudio.Platform.WindowManagement.WindowManagerService' threw an exception.
    – CC Inc
    Aug 22, 2013 at 2:12
  • 2
    All sorts of hacks and solutions in the accepted answer of Stack Overflow question #4405091 :)
    – bosco
    Aug 22, 2013 at 18:31

3 Answers 3


it is possible to reduce the excessive quantity of paths in the environment variables PATH , just save the whole line out to a notepad, as a backup and remove some and test.

Most of them are there so if a shortcut does not have a full path set for the "Target", If the "Start In" is not set in the shortcut correctly or a launch is done oddly their program and its parts and pieces are always found. It is a Failsafe in most situations. You would still want to test fully any use of any program that you removed its paths.
It is also very usefull to the people who type commands into the CMDprompt, even without a CD, the computer will scan each location, until a program by that name is found and run. Or any other command of the same name :-)

That set of paths WAS (anchient) limited to less than 255(or260) charachters , that changed to 1024 some time long ago, then was patched back in server'03 era to handle 2048 , and supposedly could handle 8096 on some systems , even long ago.

The real limitations discovered today that people run into, is in the CMDprompt which has a limit on the length of the command string, which includes the expanding of the variables and paths.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682653(v=vs.85).aspx here Microsoft says:

"The maximum size of a user-defined environment variable is 32,767 characters. There is no technical limitation on the size of the environment block. However, there are practical limits depending on the mechanism used to access the block. For example, a batch file cannot set a variable that is longer than the maximum command line length."

At that location ^ they point to the registry location that contains the system paths HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment Must read the rest of it there.

The CMDprompt and batch limitation is 2048 charachters once expanded, and is said to be 4x that for the newer systems (needs citation because people are not seeing that)

Also see http://support.microsoft.com/kb/830473, which discusses the command prompt and batch length for older systems.

To make sure that the entries are correct in there, The wiki has this to say:

%PATH% This variable contains a semicolon-delimited (do not put spaces in between) list of directories in which the command interpreter will search for an executable file that matches the given command. Environment variables that represent paths may be nested within the PATH variable but only at one level of indirection. If this subpath environment variable itself contains an environment variable representing a path, PATH will not expand properly in the variable substitution.

Having all the extra paths in there slows certain things down by quite a bit, because it is then forced to look in all those places, before it gives up. Using full paths whenever calling file items will always be faster, even when batching or using the CMDprompt.

Using old DOSlike 8.3 conventions is one way to shrink the size, this Batch https://stackoverflow.com/a/20362922 works well. be sure (again) to backup the orginal string. See also the other possible solutions at that question.

Here is how mine looks, it has been worse.
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\QuickTime\QTSystem\

I would toss out quicktime in a heartbeat, and AMDs programs have put an extended path in there before, tossed it, Adobee had one, none of these mattered for standard GUI shortcut/icon methods. Many things can be removed, then test all functions. If you call up things by typing in the CMD prompt , then removing those paths will not work.

  • So you are saying that the applications will not fail if I remove the paths?
    – CC Inc
    Aug 22, 2013 at 2:15
  • Windows 7 64-bit
    – CC Inc
    Aug 22, 2013 at 2:21
  • Is there anything in there you know is already uninstalled? Take out Qt, AMd And Nividia, (after you backed it up) mabey and see if it is short enough then? I posted mine, it is about 140 characters.
    – Psycogeek
    Aug 22, 2013 at 2:30
  • Okay, I'll see..
    – CC Inc
    Aug 22, 2013 at 2:31
  • 3
    The limitation appears to be 2048 characters. After that point, I can't input any more characters into the Environment Variables GUI. Sep 22, 2015 at 2:44

I have several software development related environment variables on my path, all of which are important.

Above solution wouldn't work for me, so I went for directory junctions:

  • Select some of the longest paths in my PATH (Like C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\)
  • Create a small folder to store my junctions: C:\d\
  • Create short junctions for long paths:
mklink /j C:\d\sql "C:\Program Files (x86)\Microsoft SQL

Doing that on 15 paths reduced my PATH from 2045 to 1285 characters.

It may be a problem when you finally uninstall stuff from your machine as junctions will remain there in the path and you'll have to clean them up manually.

  • 1
    I have a fairly typical dev enviroment, latest VS + several older versions and SQL server installed. This, so far has been the best solution. The accepted answer to toss paths out is ridiculous.
    – Mesh
    Feb 17, 2015 at 10:23
  • What did you change the registry path entry for C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\ to? c:\d\sql ?
    – OutOFTouch
    Dec 14, 2015 at 20:13
  • If you mean the PATH environment variable then yes. I didn't mess with any other references to SQL Server's directories.
    – Juliano
    Dec 14, 2015 at 20:35
  • Here's a nice little tutorial on hard links: howtogeek.com/howto/16226/… Mar 31, 2017 at 10:59

While the maximum allowable in the path is much longer, I have found on Stack Overflow authoritative answers on this topic (and Microsoft references) that state that a maximum expanded path value of 2048 bytes will work, and anything longer than that will cause problems. By "expanded" I mean that any variables denoted with % delimiters will have their values inserted to become the expanded value, and the total expanded length must not exceed 2048 bytes. I have noticed that the types of problems it causes (as of Windows 7) are:

  • Does not recognize paths at the end of the value
  • Installation of software or patches that modify the PATH value cause the runtime value to become NULL, thus causing all kinds of issues running Windows, like all your Start Menu, Desktop, and Task Bar icons lose their images, and simple command prompt commands like "ping" or "ipconfig" show command not recognized errors
  • Application programs relying on PATH values fail

Personally, I recommend other operating systems besides Windows, but if you are stuck on it, then you have to spend your hours removing path entries, testing to make sure it doesn't break anything, and get the path value down to 2048 bytes.

  • 1
    It isn't clear how this answer the author's question, at least more, then the existing answers do, which provide actual evidence to backup their statements.
    – Ramhound
    Jul 22, 2015 at 15:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .