Repairing VC++ default paths in VS2010 RRS feed

  • Question

  • When I try to build a C++ project (even a new Win32 application freshly created via "New Project"), I get the following error:

    TRACKER : error TRK0005: Failed to locate: "CL.exe". The system cannot find the file specified.

    Some research on the web indicates that my problem may be due to installing VS2010 on a machine that already had VS2005 on it.  I un-installed VS2005.  I tried the "repair" option in the VS2010 installer.  I tried un-installing VS2010 and re-installing it.  The problem with the default paths persists.

    Is the default path information stored somewhere on my machine (i.e. in the registry) where I can edit it or delete it before re-installing VS2010?

    • Edited by kw720 Tuesday, October 25, 2011 4:00 AM link "research on the web" to Stack Overflow post
    Saturday, October 22, 2011 1:09 AM


All replies

  • When you create a C++ project, Visual Studio manages an "Executable directories" list. It uses this list when it searches for binary files. You can see this list in your project's properties (menu Project/Properties), VC++ directories tab.

    The Executable directories list should start by $(VCInstallDir)bin. $(VCInstallDir) is the path where Visual C++ is installed, it is generally <program files>\Microsoft Visual Studio 10\VC.

    And in the <program files>\Microsoft Visual Studio 10\VC\bin folder, you should see CL.EXE.

    Which of the above is not true for you?

    Also, installing VS2005 and VS2010 on the same PC is OK. Not sure this is the cause of your problem.


    Saturday, October 22, 2011 2:03 AM

    I have $(VCInstallDir)bin in the list of "Inherited values", but it is not at the top.  I found CL.EXE under the following path:

    C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin

    Here is the complete list of Executable Directories inherited values:

    C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin
    C:\Program Files (X86)\Microsoft Speech Sdk 5.1\Bin
    $(WindowsSdkDir)bin\NETFX 4.0 Tools
    $(ProgramFiles)\HTML Help Workshop

    I checked the value of $(VCInstallDir).  It is "c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\"

    It certainly looks like it should be able to find CL.EXE.

    ... but, ... I wonder if this is an issue, ... I checked the paths above $(VCInstallDir)bin in the list, ... this one doesn't exist on my machine:

    C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin
    • Edited by kw720 Saturday, October 22, 2011 2:40 AM add comment about missing path
    Saturday, October 22, 2011 2:19 AM
  • It's strange that platform sdk is installed inside VC. How did that happen?

    On line 2 of your path list, a ) is missing, maybe a copy/paste error? or this might be a problem?

    Can you run dependency walker on CL.EXE?

    Saturday, October 22, 2011 1:38 PM
  • PlatformSDK isn't actually installed under VC, that path is non-existent.  I have no idea where that inherited path came from.

    Line 2 isn't a copy/paste error, here is a screenshot of the property dialog:

    Running dependency walker on cl.exe produced interesting results:

    Simply trying to run cl.exe from the command prompt produced an error dialog complaining about MSPDB100.DLL.  I found an answer for that problem:


    After running VCVARS32.BAT, that problem went away and I can run cl.exe from the command prompt.  Dependency walker still complains about GPSVC.DLL and IESHIMS.DLL.  I don't know if these are something I should be concerned about or not.  CL.EXE seems to run from the command prompt, and the stack overflow discussion indicates that it runs in a different context through Visual Studio's IDE anyway.

    Lines 1 through 4 of my path list (and perhaps more) are non-existent paths.  Line 2 has a syntax problem (missing closing parenthesis and an extra backslash).  The list of inherited paths is definitely messed up.

    Where does Visual Studio get this path list from?  Is there a place in the registry where I can edit it or remove it in preparation for a fresh install of VS2010?  As a last-resort, I suppose I could wipe my hard-disk and re-install Windows 7, but if there is some way to get rid of the lingering data, that would be much nicer.

    • Edited by kw720 Sunday, October 23, 2011 2:06 AM link-ify a link, replace a picture with a smaller one that will hopefully show up, fix whitespace issues, use clearer wording
    Sunday, October 23, 2011 12:10 AM
  • You can run CL.EXE from the command line, but your C++ folders seem to
    contain some crap. Have you tried to remove the first lines, before
    ($VCInstallDir)bin ?
    Sunday, October 23, 2011 2:28 PM
  • I haven't a clue where it is getting these paths from, but I would sure like to know.

    My guess is, when a platform SDK is installed, this information is stored somewhere, and Visual Studio knows how to get it.


    Sunday, October 23, 2011 2:35 PM
  • You can run CL.EXE from the command line, but your C++ folders seem to
    contain some crap. Have you tried to remove the first lines, before
    ($VCInstallDir)bin ?

    I would love to remove those lines, but they are read-only in the GUI:

    If I un-tick the "Inherit from parent ..." checkbox and manually enter executable directories paths in the editbox area, I can get projects to build.  The problem is that we have many projects and it is very time-consuming to manually set the paths for each one, ... plus then my path edits would become part of the project file in our source control repository.

    So, ... my conundrum is this:  How can I delete those paths?  They come back no matter what I try.  I un-installed VisualStudio and all of the SDK's.  When I re-installed VS2010, those default paths magically showed up again.  I just want to get rid of them and have VS2010 set them to the correct defaults.

    Sunday, October 23, 2011 9:35 PM
  • Project setting defaults are created from property sheets, see
    The property sheet file which may interest you is
    Microsoft.Cpp.Win32.user.props in
    <localappdata>\microsoft\msbuild\v4.0, where <localappdata> is
    c:\users\username\appdata\local under win7.
    • Marked as answer by kw720 Monday, October 24, 2011 3:35 AM
    Monday, October 24, 2011 1:45 AM
  • Thank you!

    That was where the bad paths were.  I just copied a clean version from a different machine, and that solved all my problems.

    Thanks again.


    Monday, October 24, 2011 3:38 AM