Mailbag: How to perform a silent install of the Visual C++ 2008 redistributable packages

發行項
03/27/2009

Question:

You previously posted a list of command line switches to perform silent and unattended installations of the Visual C++ 2005 runtime redistributable packages. How can I perform silent and unattended installations of the Visual C++ 2008 runtime redistributable packages?

Answer:

The Visual C++ 2008 redistributable packages (vcredist_x86.exe, vcredist_x64.exe and vcredist_ia64.exe) support the following command line installation options.

The same command lines are valid for the VC++ 2008 redistributable packages and the VC++ 2008 SP1 redistributable packages.

The examples below use the file named vcredist_x86.exe, but you can substitute the 64-bit versions of the EXEs with equivalent command lines to achieve the same behavior for them as well.

Unattended install

This option will run setup and display a progress dialog but requires no user interaction.

<full path>\vcredist_x86.exe /qb

For example, if you download vcredist_x86.exe to a folder named c:\vc2008redist, then the command line would look like this:

c:\vc2008redist\vcredist_x86.exe /qb

Unattended install with no cancel button

This option is the same as the previous option, except that the user will not have the option to press cancel during installation.

<full path>\vcredist_x86.exe /qb!

For example, if you download vcredist_x86.exe to a folder named c:\vc2008redist, then the command line would look like this:

c:\vc2008redist\vcredist_x86.exe /qb!

Silent install

This option will suppress all UI during installation.

<full path>\vcredist_x86.exe /q

For example, if you download vcredist_x86.exe to a folder named c:\vc2008redist, then the command line would look like this:

c:\vc2008redist\vcredist_x86.exe /q

Related links:

<update date="7/7/2009"> Added information to indicate that you must provide the full path to the file vcredist_x86.exe when running the silent install command lines or they will display UI. </update>

Comments

Anonymous
December 08, 2009
hi Aaron i tried this vcredist_x86.exe /q option its installing silently but the msiexec.exe created is not finishing properly. help me in this thanks
Anonymous
December 09, 2009
Hi Funjay - Do you have any log files from the failing install on your computer? The logs should be named %temp%dd_vcredist*. If you can gather those files, zip them, post them to a file server (such as http://skydrive.live.com) and then reply here with a link, I can download them and take a look to see if I can figure out what is causing the installation failure on your computer.
Anonymous
January 17, 2010
The comment has been removed
Anonymous
January 18, 2010
Hi Thanatos83 - I tried using the same command lines as the ones listed above, except I substituted vcredist_x64.exe instead of vcredist_x86.exe and it behaved as expected for both silent and unattended install. Can you give that a try and see if it works for you as well? Unattended install: vcredist_x64.exe /qb Silent install: vcredist_x64.exe /qn
Anonymous
January 18, 2010
The comment has been removed
Anonymous
January 18, 2010
The comment has been removed
Anonymous
January 18, 2010
The comment has been removed
Anonymous
January 19, 2010
The comment has been removed
Anonymous
January 20, 2010
I am calling "vcredist.exe /q". All is working corectly, but there are some unpacked files in the C: root folder - is this correct can I avoid this(other directory or something else)?
Anonymous
January 21, 2010
Hi Timjenssen - What exact files do you see in the root of the C drive? Those files should be cleaned up when the setup process exits. If you need to avoid having the files go to the root of the drive during installation, you will have to run 2 steps - one to manually unpack to a directory of your choice, and the other to install. For example, if you want to unpack to a directory named c:vcredist, you would run these commands: vcredist_x86.exe /x:c:vcredist /q c:vcredistinstall.exe /q
Anonymous
January 21, 2010
I found an article about the bug: http://support.microsoft.com/kb/950683 But I am using vcredist from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en Is there a newer version without this bug?
Anonymous
January 21, 2010
c:vcredistinstall.exe /q ^^ this step is producing the files in C:
Anonymous
January 22, 2010
Hi Timjenssen - Interesting, I wasn't aware of that bug. It looks like there's not a way for you to avoid having this installer create these files at the root of your drive like that. The installer for the VC++ 2008 SP1 Redistributable has a fix for this issue, so you may be able to install that instead unless your application depends on the versions of the VC++ runtime files that are delivered in the original VC++ 2008 redistributable package.
Anonymous
February 09, 2010
Hi Aaron - why does running "vcredist_x86.exe /q" always require a reboot, even if the same version is already installed? Each time it is run, we see 3 or 4 PendingFileRenameOperations, such as "c:Config.Msi658bd.rbf". Is there a way to prevent this? It is causing an unnecessary reboot in our installer. We could add a check to our installer to see if the expected version is already installed first, but this would be major headache since we have many different release branches we would have to maintain.
Anonymous
February 10, 2010
Hi Gmiller - I haven't seen the VC++ 2008 Redistributable request a reboot in the scenarios where I've tried to install it in the past. Reboots happen because files are in use that the installer needs to update. I'm not sure that the RBF files are the cause of the reboot though - it is more reliable to look in the verbose MSI log file to determine the cause. For the VC++ 2008 Redistributable, the verbose logs will be named %temp%dd_vcredist*. The way to avoid files in use is to make sure that running processes that are using any of the files being installed by the package are shut down before installing. In your case, you could also check to see if the VC++ 2008 Redistributable is already installed and skip running it if so to prevent at least some of the cases where a reboot might be requested.
Anonymous
February 11, 2010
Hi Aaron - the reboot is definitely triggered by vcredist. I just ran a simple test - I made sure that c:config.msi and the PendingFileRenameOperations registry key didn't exist and cleared out my %temp% folder. I rebooted, and then killed all non-essential processes in task manager. I then ran vcredist_x86.exe /q. I saw two log files created. One log contained the following: [02/11/10,13:53:02] Process returning code 3010 [02/11/10,13:53:02] Pending Reboot Table state : Logging start [02/11/10,13:53:02] _________________________________________ [02/11/10,13:53:02] (MSVCM90.DLL, MSVCM90.DLL) c:Config.Msi7d116.rbf ( 9.00.30729.4148 ) ( Sun Jul 12 00:05:16 2009 ) Delete [02/11/10,13:53:02] (MSVCR90.DLL, MSVCR90.DLL) c:Config.Msi7d118.rbf ( 9.00.30729.4148 ) ( Sun Jul 12 00:02:02 2009 ) Delete [02/11/10,13:53:02] Pending Reboot Table state : Logging end The other contained the following: MSI (s) (5C:2C) [13:53:01:968]: Note: 1: 1321 2: c:Config.Msi7d116.rbf MSI (s) (5C:2C) [13:53:01:968]: Verifying accessibility of file: 7d116.rbf Info 1903.Scheduling reboot operation: Deleting file c:Config.Msi7d116.rbf. Must reboot to complete operation. MSI (s) (5C:2C) [13:53:01:984]: Note: 1: 1321 2: c:Config.Msi7d118.rbf MSI (s) (5C:2C) [13:53:01:984]: Verifying accessibility of file: 7d118.rbf Info 1903.Scheduling reboot operation: Deleting file c:Config.Msi7d118.rbf. Must reboot to complete operation.
Anonymous
February 11, 2010
Hi Gmiller - Did this happen on a machine that already has this VC++ Redistributable package installed, or on a machine that didn't have it? Also, do you have a full copy of the verbose MSI log file that you could post to a file server (such as http://skydrive.live.com) and then reply back here with a link so I can take a look?
Anonymous
February 12, 2010
Hi Aaron - here is the log. This machine already has vcredist installed. We see this problem over and over on our QA and developement machines. http://tinyurl.com/ygkjsra
Anonymous
February 15, 2010
Hi Gmiller - The logs you attached show that that version of the VC++ Redistributable was already installed, so it was launched in repair mode. It also shows that the reboot was caused by the following 3 files being in use: Info 1603.The file c:WINDOWSwinsxsx86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.4148_x-ww_d495ac4emsvcr90.dll is being held in use by the following process: Name: explorer, Id: 2364, Window Title: '(not determined yet)'. Close that application and retry. Info 1603.The file c:WINDOWSwinsxsx86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.4148_x-ww_d495ac4emsvcp90.dll is being held in use by the following process: Name: explorer, Id: 2364, Window Title: '(not determined yet)'. Close that application and retry. Info 1603.The file c:WINDOWSwinsxsx86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.4148_x-ww_d495ac4emsvcm90.dll is being held in use. Close that application and retry. In other words, the Windows shell is using some of the VC++ runtime files, and the repair of the product is triggering a reboot request because those files are already installed and are in use. For a first time install where this version of the VC++ redistributable is not yet installed, you shouldn't see those files being held in use. However, I don't see how you can avoid it if the product is already installed (because it is Windows itself that is using the files) unless you add detection logic to your installer and skip trying to install it if it is already installed.
Anonymous
February 15, 2010
The comment has been removed
Anonymous
February 15, 2010
Hi Gmiller - The Windows shell uses the VC++ runtime files, so it will end up loading them whenever it is running. That is why the files are in use during this install process. In your scenario, the product is already installed, and when you re-run the installer, it is running a repair with REINSTALLMODE=emusc. The "e" flag in the REINSTALLMODE property means that Windows Installer will repair files in the package if if the file is missing or an equal or older version is installed. In your case, an equal version is installed, so it is attempting to repair the files, and since they're in use by the OS, you're seeing a reboot prompt.
Anonymous
February 17, 2010
Thanks for all the info. It would be nice to have an option on vcredist_x86.exe to skip repair mode, or at the least use the default repair option "o" ("if file is missing or an older version is installed") instead of "e". Looks like I'll have to extract the .msi and .cab, and launch msiexec.exe with my own parameters.
Anonymous
February 17, 2010
The comment has been removed
Anonymous
February 20, 2010
Hi Aaron ! If i perform /qb then work fine but this extract all files inside self-extracting, and not delete it when installed. I use only /qb for unattended but how i do to delete all files automatically when vcredist is installed? thanks.
Anonymous
February 21, 2010
Hi Thanatos83 - It sounds like you might be running into the issue described at http://support.microsoft.com/kb/950683. Can you take a look and see if this sounds like the same thing as you are seeing? If so, you can manually delete the files after installing if needed, or you can just leave the files there because they won't hurt anything. Also, the installer for the VC++ 2008 SP1 Redistributable has a fix for this issue, so you may be able to install that instead unless your application depends on the versions of the VC++ runtime files that are delivered in the original VC++ 2008 redistributable package.
Anonymous
April 07, 2010
Hi, thanks for this blog entry! What do you think of the following strategy to prevent unnecessary restarts:

extract: vcredist.exe /x:PATH_TO_A_TEMP_FOLDER /q (I do not know if this is the correct way to extract the files, because it is not documented. I have just tested some flags and this combination worked for me...)
install: msiexec /fc PATH_TO_A_TEMP_FOLDERvc_red.msi /passive and if that fails (because the package is not installed, for example): msiexec /i PATH_TO_A_TEMP_FOLDERvc_red.msi /passive
cleanup: delete PATH_TO_A_TEMP_FOLDER (if the computer has to be restarted to finish the installation, can I delete the folder before the reboot?) Does the /fc flag guarantee that corrupted files / older files are always repaired / updated? Should I use the /norestart switch, too?

Anonymous
April 07, 2010
The comment has been removed
Anonymous
April 08, 2010
Thanks for your fast reply. What happens if an installed dll is neither missing nor older, but if it is just corrupted. Will this be detected by /fomus or do I have to use something like /fcomus ?
Anonymous
April 08, 2010
Hi Ulrich - I'm not sure about corrupt files. The /c switch will allow the repair to detect files that have mismatched checksums, but that only works for files marked with valid checksums in the original MSI. It would definitely be safer to include the /c switch for the repair scenario I think, but I don't know if that will cover you in 100% of the scenarios where a file installed by the VC redistributable somehow ends up corrupted on the target system.
Anonymous
April 08, 2010
Hi Aaron, I will use this approach now and have implemented it in my installation script. But something is quite interesting: If my script does a fresh install of the package, no files are created under c:, but if it does an install in repair mode, all files are copied to c:, too.
Anonymous
April 08, 2010
Hi Ulrich - I think you're running into the issue described at http://support.microsoft.com/kb/950683. That issue should be fixed in the VC++ 2008 SP1 redistributable. I'm not sure why it would only be happening in a repair though - I see it happen during initial install as well on my system.
Anonymous
September 03, 2010
Hey Aaron... I see your comments above with Gmiller about the reboots. I'm seeing the same thing where my machines are rebooting (mostly Win7) and instead of extracting the .msi and .cab and then running them separately, is there not a /norestart switch that can be used? Is there any way that I can prevent reboots 100% of the time regardless if the 2008 VC++ files are installed or not installed? Is it possible to pass the REBOOT=ReallySuppress option to the .msi in some way? Thanks!
Anonymous
September 03, 2010
Hi James - It doesn't look like the /norestart switch is supported for the VC++ 2008 redistributable. Instead, you would need to use the 2 step approach described in one of my previous comments:

Extract the package by running vcredist_x86.exe /x:c:vc2008redist /q Note - you can change the path c:vc2008redist to whatever folder you want
Run the MSI directly by runnning msiexec /i c:vs2008redistvc_red.msi /q REBOOT=ReallySuppress Reboots occure when files are in use. There is no way I know of to 100% guarantee that files will never be in use, especially in repair cases where the product is already installed. Passing REBOOT=ReallySuppress will cause setup to not automatically reboot, but if files are in use, it will return exit code 3010, and in that scenario, it is the responsibility of the application that is installing the VC++ redistributable to honor that exit code and request a reboot at the end of the overall application installation process.

Anonymous
October 05, 2010
Hi Aaron -- I work in Product Tech Support and we need the redistributables in place for our particular software package. We've got a case with one of our users who needs to push the redist packages out via Active Directory -- and so he says they can't use the .exe with the associated switches and has to go directly with the .msi. He's asserting that the silent push of the 2008 package is failing because it still requires a manual confirmation of the EULA. Any possible guidance?
Anonymous
October 06, 2010
The comment has been removed
Anonymous
October 17, 2010
Hi Aaron - is there any info available on installing the VS2010 redistributable?
Anonymous
October 18, 2010
Hi Sandybo - I posted information about how to detect the VC++ 2010 Redistributable at blogs.msdn.com/.../10008146.aspx. However, it doesn't look like I've posted something about the silent install switches yet. I'll write a separate blog post about that soon. For now, here are commands you can use: Silent install - vcredist_x86.exe /q /norestart Unattended install - vcredist_x86.exe /passive /norestart You can swap in the x64 and ia64 version of the VC++ redistributable in the above command lines as well.
Anonymous
October 18, 2010
Hi Aaron - That's great, just what I'm looking for. Thanks
Anonymous
February 01, 2011
Hi Aaron, One of the posts here (starts 15 Feb 2010) mentions unwarranted restarts from vcredist. I have an issue with the merge modules containing VS 2008 runtime that trigger an unwarranted (my opinion) restart. One way to get rid of the unwanted restarts with vcredist run when it is already installed is to switch to MSMs and author your own MSI that merges VC merge modules present in %PROGRAM FILES%Common FilesMerge Modules. This seems to be the recommended way on MSDN. We install a separate MSI that merges VS 2008 runtime modules. On most machines MSI reports success. On some Windows 7 Home Editions we see it report a success but needs restart because "the assembly is in use". This seems to be an expected scenario since a specific error string is assigned to for it. However I do not understand why the restart since the machine has build 21022.8 and we install 30729.4148? Is there a way to avoid that? Why only on Windows 7 Home Edition? What could be the link? We already ruled out antivirus software or registry permissions issues. Thanks
Anonymous
February 02, 2011
Hi Tudor - The verbose MSI log file from the VC++ redistributable install process will show exactly what is in use by what other processes that is triggering the process to request a reboot when it completes. For the VC++ 2008 redistributable, the log files will be named %temp%dd_vcredist*. If you can find those logs on your computer, zip them, upload the zip file to a file server (such as http://skydrive.live.com) and reply back here with a link to the logs, I can help take a look and determine what is causing the reboot request. Please note that MSI files will not request a reboot unless there is a specific reason for it to need to (something is in use that it is trying to update).
Anonymous
February 02, 2011
The comment has been removed
Anonymous
February 02, 2011
"no progress" - in a multi-package install our bootstrapper runs packages hidden to have maximum control over the course of the installation. You realize why we vcredist.exe was not our first choice.
Anonymous
February 03, 2011
Hi Tudor - I would need to see a verbose MSI log file from an MSI that has the VC++ merge modules included and that requested a reboot. As I said in my previous reply, the exact files that are in use and by what processes will be listed in the verbose MSI log.
Anonymous
February 03, 2011
Thanks for the reply. Here is a link to the installer log file: cid-7093e07d98664f80.skydrive.live.com/redir.aspx I know for sure that 30729.4148 is NOT installed on that machine (log at 16:23:22:939 supports that) but at 16:23:30:068 the assembly is in use. What gives? Yes we also include the policies since we saw no harm in that - and we would also support Msfts strategy of using the most up-to-date runtime as much as possible. -Tudor
Anonymous
February 04, 2011
The comment has been removed
Anonymous
February 10, 2011
I did not save CBS.log the first time so I had to wait to reproduce it again. Here is a fresh pair: lrcu6a.blu.livefilestore.com/.../VC90_x86.log and lrcu6a.blu.livefilestore.com/.../CBS.log There is a log going on in the CBS log and I cannot clearly figure out why the reboot is required for certain sessions occurring at the time of the installation (15:57:+).
Anonymous
February 10, 2011
Sorry for the bad links: here is the public link: cid-7093e07d98664f80.skydrive.live.com/redir.aspx
Anonymous
February 11, 2011
Hi Tudor - This link takes me to a page that says that the My Documents folder might not be shared with me. Can you please check the permissions when you get a chance?
Anonymous
February 13, 2011
Hi, I am just learning the ropes with SkyDrive. As usual, Msft tools fail to provide a smooth learning curve. This must work: cid-7093e07d98664f80.skydrive.live.com/redir.aspx
Anonymous
February 14, 2011
Hi Tudor - I'm able to download your CBS log from this latest link, thanks for uploading it again. I can see the log entries where it is installing the VC++ assemblies that are being reported as being in use in your MSI log. However, I don't see any data in the CBS log to indicate what other process(es) are holding those files in use like I was hoping to see. I think you'll need to use a tool like Process Monitor (technet.microsoft.com/.../bb896645) to narrow down the cause of this reboot request further. I'm sorry for the hassles.
Anonymous
February 14, 2011
Thanks Aaron for investing your time in this. Just as I have suspected all along, this particular set of machines that has this problems has a problem with the installed VC runtimes, perhaps something to do with the installer product it was part of. It might also be the case this set of machines is simply not up-to-date. We could not investigate further since we found a workaround and we no longer need the runtime libraries during install. If I'd have to put my money on it, I would guess that ensuring your Windows is up-to-date removes 50% of this kind of issues. If our customer care program would enforce this policy we would have to spend more time on the real issues. Thanks again.
Anonymous
June 22, 2011
Hi Aaron - We just updated our installs with the latest VC2008 redistributables (9.0.30729.6161). We use "vcredist_x86.exe /q" in our InstallScript installs, and the x86 merge modules in our MSI packages. The first problem I noticed was that the new merge modules were not installing the files (or, were installing them later in the sequence which was now after we launch our application which requires the VC runtime resulting in error - I'm not sure because of the next problem). To start my testing over, I removed all the vc90 folders from under WinSxS. After that, neither vcredist_x86.exe nor the merge modules installed any of the vc90 files or folders under WinSxS. No matter what I do now, I cannot get the files to install! I have also received reports from users in other departments that our application doesn't run using the InstallScript install - in one case running vcredist_x86.exe manually fixed it up. It seems things are really messed up with the latest installers - is anyone else having these problems? More importantly, how can we resolve this with confidence that when our installers are out in the field they will reliably install the necessary VC runtime files?
Anonymous
June 24, 2011
Hi Gmiller - If you are having sequencing problems with the merge modules, you can always schedule the launch of your application to happen later in the install process. I'm not sure that it is safe to manually remove folders under WinSxS like you describe. Do you have backup copies that you can put back there? For the failing installs of the VC++ redistributable, do you have a verbose MSI log file that you could upload to a share (such as http://skydrive.live.com) and then post a link here so I could take a closer look?
Anonymous
June 27, 2011
Hi Aaron - I'm not exactly sure what the problem is with the merge module - but I think there is more going on than just a sequencing issue. I'm 99% sure I saw one instance where the merge module installed (at least installed all the expected files under WinSxS), but our application did not run until also running vcredist_x86.exe. How can I completely remove all traces of the VC redistributable (merge module and vcredist_x86.exe) so I can start my testing fresh? I see the files in the merge module are not marked as 'permanent' yet they do not uninstall when our application is uninstalled. Here is the log from vcredist_x86.exe: http://tinyurl.com/3p4hwgx (I see the log indicates success, and the entry appears in Add/Remove Programs yet none of the files are installed under the WinSxS folder)
Anonymous
July 21, 2011
Hi Gmiller - Sorry it has taken me so long to get back to you. I can't get to the log file anymore because it says that the download has expired. When your application does not run, what is the exact error message you see, and is there any information in the application event log to indicate what the issue is? Is it possible that you are installing some but not all of the dependencies that your application has? In order to fully uninstall the VC runtime files, you need to uninstall all products that include references to it from your computer. If there are multiple products installed, they will each hold a reference count on the files, and uninstall will not remove the files until the reference count reaches zero.
Anonymous
September 21, 2011
Hi Aaron - previously (Feb 2010) you said that REINSTALLMODE=emusc for a repair install. Can you confirm what REINSTALLMODE is used for repair mode in the latest vcredist_x86.exe? We have since switched from running the MSI with our own parameters (at one point we received an error when attempting to run the MSI directly so we had to switch back to the .exe). However, I'm no longer seeing the reboot needed when the runtime is already installed so I'm wondering if the options have changed or if it's something else. I've been asked whether it will re-install the runtime files if the same version is already installed.
Anonymous
September 21, 2011
Hi Gmiller - You should be able to look in the verbose MSI log file to figure out which exact values are being set for the REINSTALLMODE property in your scenarios. Also, if you need it, there are definitions for the allowed values in the MSDN topic at msdn.microsoft.com/.../aa371182.aspx. A reboot is needed when the installer tries to update files that are in use during the install process. It might be possible that you don't have any files in use if you aren't seeing a reboot in your scenarios.
Anonymous
September 21, 2011
You're right - the log file does contain this info. I swear I looked before but didn't see it! :) Thank you.
Anonymous
October 17, 2011
Hi Aaron - Do you know why we can no longer use vc_red.msi directly (starting with the April 2011 release)? It gives the error "To install this product, please run Setup.exe". We've had various issues (unnecessary reboots, long delays) using vcredist_x86.exe which have all been resolved by using the MSI - it's unfortunate that option has been taken away from us.
Anonymous
October 18, 2011
The comment has been removed
Anonymous
October 18, 2011
Thanks Aaron - that's extremely helpful to know!
Anonymous
November 05, 2012
The comment has been removed
Anonymous
November 06, 2012
Hi Dev - In general, it is safest to reboot if a setup program asks you to. Reboots happen because a file that setup needs to update is in use by another process. If you suppress the reboot, the older version of the file that needs to be updated will be used until you reboot. Depending on what functionality you try to use in the file, you might not notice, or you might run into crashes.
Anonymous
November 06, 2012
we faced some java applications crashing or not working properly. this reboot issue may be the reason as the systems are not rebooted and the binaries marked for deletion were still being used. and causing some mismatch with the updated binaries. Now if I simply reboot the system will those applications work properly?
Anonymous
November 06, 2012
Hi Dev - If the Java installer requested a reboot and the reboot was skipped, then I think it would help to reboot the computer. I don't know if that will solve all of the issues that you're seeing though.
Anonymous
March 20, 2013
What is the method to extract vc_red.msi from the VS2012 redistributable? The method above, which worked for VS2008 and VS2010, does not seem to work for VS2012. We are upgrading from VS2010 to VS2012 and I think we really want to keep the same approach in our installs for installing the VC runtime.
Anonymous
March 22, 2013
Hi gmiller - There isn't a way to extract the .msi in the VC++ 2012 redistributable like there was in previous releases. There shouldn't be any need to do so though. You can install in silent mode by running the VC++ 2012 redistributable setup executable (such as vcredist_x86.exe) with the /quiet /norestart switches.

共用方式為

Mailbag: How to perform a silent install of the Visual C++ 2008 redistributable packages

Comments

其他資源