VC++ 2005 redistributable (vcredist_x86.exe etc.)


  • Hi there,

    I noticed that the Beta 2 redistributable is hosted on the Microsoft download library, but the final ones seems not to be. Will it be hosted on (or is it already somewhere?).

    Also, it has been reported to me that on Windows 2000 the (RTM) redistributal gives an unuseful error message if Windows Installer 3.1 is not installed. The message is
    error 1723. "A DLL required for this install to complete could not be run."
    . It would be a lot more helpful to my users if this was a more informative error message - the solution of installing Windows Installer 3.1 was only found by trial and error.

    Monday, November 28, 2005 7:35 PM


All replies

  • In my installation, I found the such file under 
    Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86

    I believe that is the .net framework SDK.

    Hope this helps!

      Ayman Shoukry
      VC++ Team

    Monday, November 28, 2005 7:55 PM
  • Hi,

    Thanks for the reply, but I am of course aware of that and it does not quite answer my question or my other comment :)

    I know the libraries are included in the .NET framework 2.0 which is hosted on microsoft's website, but that is a larger download and some users seem to not like installing it either..
    Monday, November 28, 2005 10:49 PM
  • There are several issues mixed in this post. I will try to address them one by one

    1) It is planned to have vcredist_*.exe available on the website. I do not have an ETA for this now, but it is going to be announced when available.

    2) MSI 3.1 is required. Agree that error message should be more informative.  Pleaser report a suggestion on

    3) vcredist_*.exe is installed by Visual Studio as a bootstrapper package inside .Net SDK folder. If you do not see it on the hard drive, go back to VS install and select Redistribution packages under list of components.

    4) Using vcredist_*.exe in your application does not introduce dependency on .Net SDK itself.

    Tuesday, November 29, 2005 12:16 AM
  • Thanks, the awnsers to 1) and 2) is what I wanted to know :) I've filed a suggestion now.
    Tuesday, November 29, 2005 9:25 AM
  • Actually, the vcredist_x86.exe isn't part of the Net Framework package (neither the redistributable nor the SDK contain it). I have Visual C++ Express, and .Net v2 SDK installed on my machine, and neither installed that file. I had to pull that redist from a Visual Studio Professional machine.

    It looks like that redistributable is specific to Visual Studio Professional.

    On the MSI front, I'm wondering what feature required MSI 3.1 to be installed and why it required MSI 3.1.
    Tuesday, November 29, 2005 12:21 PM
  • Re: MSI 3.1 - I'm wondering the same thing.  I think it's some advanced WinSxS policy support stuff they needed.

    For VC Express: you can make your own MSI redistributable using the MSM files that are available at: \Program Files\common files\Merge Modules

    using the method mentioned here:

    He has a typo in step 8, it should be:

    a >cd d:\WiX
    b. >candle.exe vccrt.wxs -out vccrt.wixobj
    c. >light.exe vccrt.wixobj -out vccrt.msi

    The funny (ironic) thing is that he has a troubleshooting secton that mentions this exact typo! (troubleshooting step 1)
    Tuesday, November 29, 2005 6:54 PM
  • My original statement that MSI v3.1 is requirement is incorrect. The redistributable only requires MSI v3.0 (ie. if you have MSI 3.0 you won't get the 1723).

    However, even using WiX, I still got the 1723 error on systems without MSI 3.0. In the VCCRT.wxs file, I noticed that the Package element included the following attribute:

    <!-- meaning: We won't install if MSI is not 3.0 (btw, this was how I discovered that MSI 3.0 is the real requirement) -->

    which means that my custom MSI will refuse to install on anything less than XP SP2. That shouldn't be a problem--Just fix that attribute so that the minimum Installer version is 2.0, and it should run quite happily.

    Or so I thought.

    The MSI 3.0 requirement seems to be embedded in the MSM files themselves. I took a look at the Msievent.logs and noticed that the 1723 occurred at step SXSInstallCA. Eager to discover what this step did, I decompiled the Microsoft_VC80_CRT_x86.MSM with msi2xml ( The SXSInstallCA (and also the SXSUninstallCA) step called into a custom DLL called MSMCustomAction.dll. I knew I was homing in on the source of the problem.

    Seeing how the problem was caused by an outdated Windows Installer, I opened up MSMCustomAction.dll with Dependency Walker ( and found the two APIs that caused the 1723.

    They are MsiEnumProductsEx() and MsiQueryComponentState(). Unless these two functions are located in MSI.dll, then the entire install will fail with a 1723.

    This means:

    a. All VC++2005 programs that rely on the multi-threaded DLL (that's the default) CRT will not work on Windows 2000SP3, XPSP1, or Server 2003, unless they obtain a patch to update Windows Installer. (did I forget to mention that the patch REQUIRES A REBOOT?)
    b. It doesn't matter if you use the vcredist_x86 or author your own setup from the MSMs. I've also checked a machine with VS2005 Pro (the same problem with those MSMs).
    c. An end user may be required to download 300Mb of patches (and reboot, and then reinstall Windows when the patch fails) just so they can install your application.
    d. Fixing requires a change to the prepackaged MSMs themselves. There's nothing I can do from the setup side to workaround it.

    Given a dialup connection and the choice of a 500k statically-linked app (whose CRT may or may not have security bugs), and a 20k app that requires 300Mb of extra downloads (which doesn't have security bugs, just reliability bugs), I know which one an end user will choose.

    Saturday, December 03, 2005 3:44 PM
  • OShah - great analysis, excellent post.  This finally gets to the bottom of why this is happening.

    1) I think that you may be able to include MSI 3.1 redist with your app

    2) There are also some files here that may help you for redist:

    \Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\WindowsInstaller3_1

    Not sure of the ins and outs of the bootstrapper mechanism yet.

    You might be able to call into these new APIs without immediate reboot (i.e. so-called delayed reboot) but I haven't yet found out whether it is possible (something similar was possible with MSI 2.0)

    3) There is also the method of not using the redist or MSI at all, and just install applocal.  See other my posts relating to this e.g.

    I've decided to go this route for my apps.
    Monday, December 05, 2005 6:21 PM
  • Thanks.

    When I discovered that this problem would affect every customer of Visual Studio 2005 (whether they install the Express Edition or Team Suite), it made me believe that Microsoft was conducting a conspiracy to monopolise the setup market and get us to install MSI 3.1 (maybe because they hated the fact KB898268 was preventing anyone from installing it--sounds stupid, but so does every conspiracy theory).

    I'm not sure if I want to use the custom manifest... mostly because of the reasons Ayman mentioned. I liked the way Visual C++ Beta 2 worked: you could place msvcr80.dll in your app directory, and if the user had the WinSXS version, it would load the WinSXS version.

    Have you taken a look at MsiEnumProductsEx and MsiQueryComponentState? I'm no expert at Windows Installer, but MsiEnumProductsEx seems to be a filtered version of MsiEnumProducts, and MsiQueryComponentState seems to be a filtered version of MsiQueryProductState. So if the MSMs fallback to these older APIs we can eliminate the dependence on Windows Installer 3.0!

    Using a bootstrapper is a good idea, but I'm not sure how it works in MSI. If it's a self-contained native app that does version checking on the MSI DLLs, I'd rather write my own app. If it relies on Windows Installer 1.0 being installed, I'm definitely writing my own app.
    Tuesday, December 06, 2005 1:05 PM
  • I agree, in a perfect world Microsoft would revisit this and eliminate the possibly unnecessary dependence on MSI 3.x.    There might be other reasons why they moved to MSI 3.x other than just those functions. 

    Note: I asked Microsoft whether this was a bug or by design, and they said by design.  Look here:

    Yes, I agree it is nice that it chose the ones WinSxS folder first in older versions, this is one of the major disadvantages of the new method, but I've got to weigh the benefits.

    For installing applocal, you mentioned a custom manifest, actually no changes to the default generated manifest are necessary.  You simply need to copy the Microsoft.VC80.CRT folder into your program folder. 
    I tried this:

    1) On a machine with Visual Studio 2005, build a release app that is dependent on msvcr80.dll etc.

    2) Find an XP machine that has no trace of 2005 or the framework 2.0 (virgin machine), i.e. no copies of any of the new CRT DLLs.

    3) Copy the release executable built in step 1 to the virgin machine. 

    4) Copy the folder \program files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT to a subfolder of the location of the executable copied in step 3.

    5) Double click on the executable.  It just works!  No custom manifest necessary.
    Tuesday, December 06, 2005 1:32 PM
  •  Ted. wrote:
    He has a typo in step 8

    Thanks. :-) I have corrected it. Agree, it is ironic. :-)

    But it is not MSI pulls it MSI3.0, but rather customaction.dll inside MSMs. It was by design decision acros VS and VC had to follow it. As I said on the newsgroups, you may contact developer support and request assistance if this is a "showstopper" for your product. 

    Tuesday, December 06, 2005 11:36 PM
  •  Nikola Dudar wrote:

    But it is not MSI pulls it MSI3.0, but rather customaction.dll inside MSMs. 

    Yes, this is what OShah discovered above already in his analysis, not MSI engine but the custom action which calls two functions only available in MSI 3.1  (MsiEnumProductsEx and MsiQueryComponentState)

    It was by design decision across VS and VC had to follow it.

    But it can hardly be faulted for us that we're curious as to why this is the case (i.e. why the 3.1 targeting design decision unless the MSI 3.1 gives you some functionality that your custom action absolutely requires)   In OShah's analysis, he concluded that the "downlevel" functions MsiEnumProducts and MsiQueryProductState could have possibly been used instead.   This may not even be the case, but we cannot know unless we see the actual source code of the custom action.  It's interesting for us to hear some of the "inside" shop talk of the "why's" in some cases, even if it's normally considered confidential. 

    Wednesday, December 07, 2005 3:22 AM
  • Nikola.

    I spent the last two days making my own bootstrapper application (which includes and installs MSI3.1 if necessary). This bootstrap app may be the final solution for me. About your offer of a QFE--it sounds like you've already come up with a fix, but need extra support from our side to get it released. Forgive me if I'm mistaken.
    When you chose that design decision, did anyone mention the possibility that it could lead to DLL Hell, The Sequel (impacting both developers and end users)?

    Ted, Why I labelled Microsoft.VC80.CRT.manifest a custom manifest? Visual C++ Express doesn't have a Microsoft.VC80.CRT.manifest in its folder (it has no VC\redist folder whatsoever, it just has the MSMs from common files). Fortunately, I managed to recreate that manifest from other sources. Hence why I called it a "custom" manifest. Hope that clears up any confusion.

    Hopefully, when my custom bootstrapper is finished, I'll be rid of these problems.

    Thursday, December 08, 2005 2:39 PM
  • Thanks OShah for your valuable comments - I keep forgetting about that fact that VC Express only has the MSM files.   I think they should have at least included those custom manifests as a minimum.    Now there is no obvious way to deploy apps applocal using VC Express. 

    I'd be interested to hear about your bootstrapper once you get it done.  In fact, I think that Microsoft should release a modified vcredist that installs the Windows Installer 3.1 as well as the libraries.   This will save a lot of pain for people.
    Thursday, December 08, 2005 9:47 PM
  • I agree with Ted.  This whole deployment procedure is a joke!  I built a dll (which is designed to be called from Java via JNI) under VC++ Express and want to deploy it on another machine and is seems so difficult to do.  Can't do app local since there is no application just a dll. I guess I'll have to try Nikola's procedure consisting of getting this, changing that, standing on your head, spinning around, etc.
    Wednesday, December 21, 2005 1:52 PM
  • hathawa, for applocal for DLLs you can just have the msvcr80.dll in the same folder as the DLL you built.  This is different from EXEs where you need a Microsoft.VC80.CRT subfolder.  This works for activex controls as well (where you can put the msvcr80.dll in the cab file).  This is according to Martyn at Microsoft, whom I asked via email. 
    Wednesday, December 21, 2005 2:57 PM
  • Ted, I just tried that and the dll still fails to load.  I must mention that the dll is being called from Java via JNI.  The actual error is "UnsatisfiedLinkerError" which comes from java.lang.ClassLoader$NativeLibrary.load(Native Method).
    Wednesday, December 21, 2005 7:42 PM
  • I'm going to work on it later tonight when I get access to my clean XP machine.   I'll let you know.
    Wednesday, December 21, 2005 8:03 PM
  • On the other topic of this discussion, I wrote an article at Codeproject about my experiences with Vc2005 redistribution. It's available here. (end shameless spam )


    Wednesday, December 21, 2005 8:57 PM
  • OShah very nice article I really enjoyed it.   Here's another little tidbit I just discovered for Hathawa's situation (see below)

    Hathawa, I discovered the "Trick".  All you need to do to get the DLL to load is copy msvcr80.dll AND the Microsoft.VC80.CRT.manifest to the same folder as the DLL.  The missing part of the puzzle was that you also need the manifest.  Normallly for an EXE these files (the manifest and the msvcr80.dll) are a subfolder named Microsoft.VC80.CRT.   But for DLLs they should be in the same folder.

    If you only want msvcr80.dll and not msvcp80.dll nor msvcm80.dll just edit the Microsoft.VC80.CRT.manifest by hand and only have a reference to file name msvcr80.dll. 

    I just tried this on a clean XP machine:

    1) Create a Win32 DLL (e.g mydll.dll) and call some function in the CRT (e.g. _getcwd)

    2) Create a small Win32 console application in Visual Studio .NET 2003 that simply does a LoadLibrary of the DLL created in step 1 and prints a message box if it succeeds. 

    3) Test it: 1) with only the msvcr80.dll in the same folder as mydll.dll.  then 2) with both the msvcr80.dll and an edited version of Microsoft.VC80.CRT.manifest (only listing msvcr80.dll).   Wow, it works!


    EDIT: actually I discovered later that no editing of the manifest file is necessary at all, even if you only copy just the msvcr80.DLL.  It seems to work even if some DLLs are listed there that can't be found.

    Thursday, December 22, 2005 5:15 AM
  • I'm still not having any luck.  I think the difference is that my dll is being invoked from Java via JNI.  Must be java.lang.ClassLoader$NativeLibrary.load works differently and is not finding the other dlls even though my dll has an embedded manifest.
    Friday, December 23, 2005 2:06 AM
  • There are two levels of manifest here: the embedded one, and the one I mentioned.  Do you have both?    Also can you write a small test app that does a LoadLibrary as I mentioned and see if it loads on a clean machine (with no stuff in WinSxS)



    Friday, December 23, 2005 3:24 AM
  • I may have the answer for you. I ran into the same problem, and it turns out the solution is to embed the manifest into the DLL as a post-build step, using the mt tool. Richard Grimes has a nice explanation here.

    This worked for me, anyway.



    Saturday, December 31, 2005 10:09 PM
  • Which manifest? I think the DLL (a standard wizard generated one) already has a manifest.  Can you post the content of your embedded manifest?
    Saturday, December 31, 2005 10:28 PM
  • I am compiling from the command-line, and the linker by default creates a manifest file which is exactly like the one shown in Grimes' article for lib.dll. This identifies the dependency on msvcr80.dll. However, the presence of the file was not enough; it had to be embedded using mt.

    In your case the wizard has generated and embedded a manifest already. However, I'd have thought it was worth having a close look at its contents and checking that it correctly identifies the dependency (complete with publicKeyToken).

    In my version of Visual Studio 2005 you can inspect the manifest either by opening the DLL directly, or looking at the generated file which has a .manifest extension.


    Saturday, December 31, 2005 11:10 PM
  • The bug was finally updated:

    "We have already built a hotfix for this issue and removed dependency of MSMs on MSI 3.1. It is now depends on MSI 2.0. You may contact developer support team to get this hotfix. This fix is also scheduled for release in VS2005 SP1."

    Still no news on the redistributables being hosted in the microsoft download library however ?
    Wednesday, April 12, 2006 10:07 AM
  • VCRedist can be downloaded now.

    X86 –

    X64 -

    IA64 -

    Just remember, that vcredist.exe deploys all VC libraries. So if your app depends on CRT only, if you use vcredist instead of MSMs, you are wasting several megs of hard disk on the target computer. See post on my blog for more details,





    Friday, April 14, 2006 6:04 PM
  • Thanks! :)
    Saturday, April 15, 2006 12:08 AM
  • Can anybody give me a clue on how can I get those updated MSMs?

    Wednesday, May 31, 2006 5:09 PM
  • I'm trying to find out the KB id of the MSM hotfix for you - I'll update this thread if I find anything out.
    Wednesday, May 31, 2006 6:55 PM
  •  Ted. wrote:
    I'm trying to find out the KB id of the MSM hotfix for you - I'll update this thread if I find anything out.

    Thanks, Ted.
    Friday, June 02, 2006 10:04 AM
  • Any luck finding that hotfix?
    Tuesday, June 06, 2006 3:02 AM
  • I've heard that since there were problems with the original hotfix, there will be a new hotfix that rolls up all known issues with the redistributables and MSM files.  But it's not quite ready yet, so for now the best thing you can do is contact Microsoft PSS at and then the Developer support team can provide an ETA on when it will be available (and help with installing, etc)
    Tuesday, June 06, 2006 3:10 PM
  • Important news: the hotfix has been released: KB id is 919280

    It can be requested from Microsoft PSS.


    Monday, June 12, 2006 6:58 PM
  • Hi Nikola,

    This 4/14 post points to a webpage with vcredist_x86.exe.  That website indicates that the offered version of vcredist_x86.exe depends on MSI 3.0

    Your 4/7 post states that the new vcredist_x86.exe depends on MSI 2.0

    Also, your 4/7 post indicates says "You may contact developer support team to get this hotfix"   How do I contact developer support to get the version that depends on MSI 2.0?






    Thursday, July 06, 2006 6:13 AM
  • The hotfix KB ids for the redistributable itself:

    x86 -  919588

    x64 -  920854

    ia64 - 920855

    Important note: these are patches, not full redistributables, i.e. the original redistributable must be installed first on the end user's machine, and then the appropriate patch must be run on the machine (i.e. the patch only updates WinSxS and only when finds the original installed DLLs in WinSxS)

    I do not know the hotfix IDs of the vcredist redistributables themselves that are changed so they only rely on MSI 2.0.  They are definitely not the above. 

    Thursday, July 06, 2006 2:41 PM
  •  Vince Harron wrote:

    This 4/14 post points to a webpage with vcredist_x86.exe.  That website indicates that the offered version of vcredist_x86.exe depends on MSI 3.0 Your 4/7 post states that the new vcredist_x86.exe depends on MSI 2.0

    Also, your 4/7 post indicates says "You may contact developer support team to get this hotfix"   How do I contact developer support to get the version that depends on MSI 2.0?


    Hi Vince,

    On 4/14 the RTM version of vcredist_x86.exe has been released as download from the web page. It is absolutely the same MSI as it is in RTM. The EXE that wraps the MSI is different in one thing - RTM version does not show an EULA, when version that can be downloaded from the webpage does show an EULA.

    To get hotfix for MSI 2.0, you need to contact Developer support using one of methods described here, 



    Thursday, July 06, 2006 3:58 PM
  • Hi OShah,

    You posted: "Visual C++ Express doesn't have a Microsoft.VC80.CRT.manifest in its folder (it has no VC\redist folder whatsoever, it just has the MSMs from common files). Fortunately, I managed to recreate that manifest from other sources. Hence why I called it a "custom" manifest. Hope that clears up any confusion."

    I'm banging my head against the same desk on this. I'm really struggling to figure assemblies out, but I understand that I need to package the VC++ 2005 runtime DLLs as a private assembly. As you mentioned. the Express edition doesn't include them. Can you give me any pointers on how you created your "custom" private assembly? Did you simply take the msvcr80.dll/etc. files, then alter the shared-assembly manifest somehow and re-embed that new manifest in the DLLs? If I'm on the right track, where can I learn about what I need to do to create the private assembly manifest?

    Thanks in advance, and thanks to all other posters. This thread has really helped me out a lot, and I feel like I'm on the homestretch. Cheers!
    Thursday, August 03, 2006 8:10 PM
  • Does anyone know the hotfix ID that I need to give the Developer support people?  When I called the support hotline she is looking for a 6 digit number that reference the hotfix.  The article is saying to call the QFE to get the hotfix but without the hotfix number being available in the post I cannot get it.  Please help!!!
    Monday, August 28, 2006 4:04 PM
  • I contacted Microsoft and this is the response I received regarding this issue with the VC++ redistributable.

    1.  Q919280 will work with msi2.0, use the msm, don't have to use the vcredist.exe

    2.  Q919588 is a fix to applies on top of a vcredist.exe install, so have to install vcredist.exe then install this fix

    3.  The best deployment method is to use msm, it will install with MSI2.0 and Q919280 updates the msm

    4.  So you can deploy with MSM that is best practice.

    5.  But if you want to deploy using vcredist, you will need to deploy Q919588 on top of it 

    6.  To install VCRedist we require below mentioned softwares with respect to OS.

    7.  If you don’t have required service pack then Q919588 should be installed on top.




    Required service pack

    Other software

    Windows 3.x/NT/95




    Windows 98/ME


    Internet Explorer 5.0 required (included in Win98SE/ME)

    Windows Installer 2.0 required

    Windows 2000


    Service Pack 3 required (includes Windows Installer 2.0)

    Windows Installer 3.0 required

    Windows XP


    Service Pack 2 recommended

    Windows Installer 3.0 required (included in Service Pack 2)

    Windows Server 2003


    Service Pack 1 recommended

    Windows Installer 3.0 required (Windows Installer 3.1 included in Service pack 1)

    Windows Vista




    I hope this helps. 

    Tuesday, September 19, 2006 1:07 PM
  • Hi, I received the hotfix from MSFT (919280) but I still get an error when trying to use the new merge module on a Win2K system without MSI 3... I'm just supposed to use the updated merge module (Microsoft_VC80_CRT_x86.msm and policy_8_0_Microsoft_VC80_CRT_x86.msm) from Program Files\Common Files, right?
    Monday, October 16, 2006 6:31 PM
  • Yes you should use the merge modules in the Program Files\Common Files and the merge modules should have a date stamp of 6/5/2006, this is what I end up after installing the hotfix.  Note that you will need to have the vredist_86.exe installed on your machine prior to running the hotfix (919280).  What I end up doing is create my own installer that will use the updated merge modules.   I hope this helps.
    Monday, October 16, 2006 6:57 PM
  • If I wait until Visual Studio 2005 service pack 1 is released, can I use vcredist_86.exe to support Windows 98, ME, 2000, and XP? (I need a technique that works with an older installer, which is not MSI based.)



    Friday, November 10, 2006 4:29 PM
  •  preclick wrote:
    Hi, I received the hotfix from MSFT (919280) but I still get an error when trying to use the new merge module on a Win2K system without MSI 3... I'm just supposed to use the updated merge module (Microsoft_VC80_CRT_x86.msm and policy_8_0_Microsoft_VC80_CRT_x86.msm) from Program Files\Common Files, right?

    Hi preclick,

    Did you ever get Microsoft_VC80_CRT_x86.msm and policy_8_0_Microsoft_VC80_CRT_x86.msm with 919280 to install on a Win2K system without MSI 3?


    Thursday, November 30, 2006 2:21 AM
  • Hi!
    I have some other problems when installing Vc++ 2005.
    During installation it says:
    Command line option syntax error. Type Command /? for Help.

    Can anyone help me?

    Wednesday, May 16, 2007 2:41 PM
  • I have some other problem with Visual C++ 2005.
    During installation it says:
    Command line option syntax error. Type command /? for Help.
    I have Windows XP SP2, and have NET framework 2.0 already installed. Can anyone help me?
    Wednesday, May 16, 2007 2:43 PM
  • @OShah

    intersting articel, although Im not a developernor a programmer. Seems this thread is outdated, but yesterday I run in an "error: 1723" situation.
    Tried to install vmware 4.5.2 on WinNT4SP6a server. Got this error.
    ok. Old box. Maybe the registry got garbled a bit.

    Today I tried it on two different WinNT4SP6a workstations. Worked on both.
    wth ???
    Due to some older applications, we have to keep the NT boxes running.
    Will examine the issue next week.

    Thursday, September 20, 2007 10:27 PM