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


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 (67)

  1. funjay says:

    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

  2. astebner says:

    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.

  3. thanatos83 says:

    Hi Aaron!

    if i use vcredist_x64 through aplication to install it. how is the full command line to extract and install this package ???

  4. astebner says:

    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

  5. thanatos83 says:

    Hi astebner!

    yep, if you extract the package MANUALLY for example with winrar and then install the MSI file through these comand lines, work perfect.

    but if you use, for example the comand line as in visual c++ 2005 sp1 to extract the package in %temp% folder or c: and then install it, then when i execute the installer the program run wizard and not install automatically.

    vcredist_x64.exe /q:a /c:"VCREDI~3.EXE /q:a /c:""msiexec /i vc_red.msi /qb!"" "

    what is the full comand line to extract the package automatically and then install it with for example: /qb ???

    I forget mention that i use an installer like (NSIS) and need to install this package through NSIS installer.

    Another question is:

    The return codes of visual c++ 2005 sp1, these are the same codes as visual c++ 2008 ???

    if a boot is required, in visual c++ 2005 sp1:

    return codes: 3010,8192,1641,1046

    thanks…

  6. astebner says:

    Hi Thanatos83 – I’m afraid I don’t understand your question.  When I tried this scenario out on my computer this afternoon, I used the exact command line vcredist_x64.exe /qn to automatically extract + install the VC++ 2008 Redistributable (x64) in silent mode.  Are you seeing different behavior than this on your systems?

    There is no need to use the complicated command line switches that were used in the VC++ 2005 Redistributable because the 2008 versions use a different technology for the self-extracting functionality.

    The return codes will be the same for the 2005 and 2008 versions because both are packaged as MSI files inside the self-extracting packages.

  7. thanatos83 says:

    Ah ,ok. Finally work to me with these comand line :)

    So there’s no problem and only i use /qn go silent and /qb for unattended.

    I use in my installation other MSI package installation like (G4WL and PhysX), the command lines for these are practically the same.

    1) So, windows intaller MSI use the same

    method?.

    2) Some aplications need to install visual c++ 2005 or 2008 redistributable and then include with their product this redis. And only include (vcredist_x86) package.

    In x64 systems, it is necessary install the package (vcredist_x86, as visual c++ 2005 or 2008) ???. Sometimes, an aplications is required to me to install this package and always i use the x64 system and then install (vcredist_x86 package).

    So there’s no problem???

    thanks Aaron.

  8. astebner says:

    Hi Thanatos83 – For your first question, yes, the command line syntax happens to be the same for the VC++ 2008 Redistributable EXEs as they are for standard MSIs.  The chainer that installs the VC++ 2008 Redistributable (install.exe) passes the /qn and /qb settings through to msiexec.exe when it installs the MSIs.

    For your second question, the vcredist_x64 package only contains 64-bit versions of the Visual C++ runtime files.  If you plan to run a 32-bit application on a 64-bit version of Windows, then you’ll also need to install vcredist_x86 onto your 64-bit version of Windows.

    This packaging is different than the .NET Framework.  The 64-bit version of the .NET Framework includes both 32-bit and 64-bit payload, so you only have to install the 64-bit version of the .NET Framework on a 64-bit OS (and in fact, the 32-bit version of the .NET Framework will block if you try to install it on a 64-bit OS).

  9. timos2000@gmx.de says:

    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)?

  10. astebner says:

    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

  11. timos2000@gmx.de says:

    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?

  12. timos2000@gmx.de says:

    c:vcredistinstall.exe /q

    ^^ this step is producing the files in C:

  13. astebner says:

    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.

  14. gmiller says:

    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.

  15. astebner says:

    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.

  16. gmiller says:

    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.

  17. astebner says:

    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?

  18. gmiller says:

    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

  19. astebner says:

    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.

  20. gmiller says:

    Hi Aaron – I don’t understand why Windows is locking these files, but why does it matter since the correct version is already installed? Why is it trying to update them? For other files, I see from the log that it is smart enough to know they don’t need to be updated. For example:

    MSI (s) (40:B4) [10:16:48:325]: File: c:WINDOWSwinsxsx86_Microsoft.VC90.ATL_1fc8b3b9a1e18e3b_9.0.30729.4148_x-ww_353599c2atl90.dll; Overwrite; Won’t patch; Existing file is of an equal version

    MSI (s) (40:B4) [10:16:48:343]: File: c:WINDOWSwinsxsManifestsx86_Microsoft.VC90.ATL_1fc8b3b9a1e18e3b_9.0.30729.4148_x-ww_353599c2.cat; Overwrite; Won’t patch; Existing file is unversioned and unmodified – hash matches source file

    I see similar entries in the log for a lot of other files. Why is the version check not performed for these particular files?

  21. astebner says:

    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.

  22. gmiller says:

    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.

  23. astebner says:

    Hi Gmiller – An omus repair won’t fix files that are present with equal version but are corrupted somehow.  It also won’t replace registry values associated with any components whose files are already present with equal version.  Those are the main reasons that this package runs an emus repair instead.

    You do have an option other than extracting the .msi and .cab and running with msiexec – you can check to see if the .msi is already installed and skip running it if so.  This is what most setup chainers do for their prerequisites during first-time install.

  24. thanatos83 says:

    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.

  25. astebner says:

    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.

  26. ulrich says:

    Hi, thanks for this blog entry! What do you think of the following strategy to prevent unnecessary restarts:

    1. 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…)

    2. 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

    3. 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?

  27. astebner says:

    Hi Ulrich – These steps seem reasonable to me.  The /x switch in step 1 is the correct way to extract the payload from the vcredist.exe package for the VC++ 2008 runtime files.  That command won’t work for the VC++ 2005 runtime files though because it uses a different self-extracting technology.

    In step 2, I’d suggest using /fomus instead of /fc.  That should cause a repair to happen for older files and missing files, but not files that are of an equal version.  That should help avoid files in use problems if it is already installed.  Just to be safe, you can also pass REBOOT=ReallySuppress in this command line.

    You should be able to delete the folder in step 3 before a reboot as long as the setup process has already exited.

  28. ulrich says:

    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 ?

  29. astebner says:

    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.

  30. ulrich says:

    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.

  31. astebner says:

    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.

  32. James says:

    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!

  33. astebner says:

    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:

    1.  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

    2.  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.

  34. Doug says:

    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?

  35. astebner says:

    Hi Doug – My understanding is that Active Directory deployment requires using the MSI directly instead of using the self-extracting EXE.  It should be possible to deploy the MSI for the Visual C++ Redistributable in silent mode without displaying the EULA or any other setup UI.  Do you know what the exact command line is that your customer is using when they try to deploy in this way?  Also, do you have a verbose MSI log file from the installation where they are seeing the EULA displayed that you could share?

  36. sandybo says:

    Hi Aaron – is there any info available on installing the VS2010 redistributable?

  37. astebner says:

    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.

  38. sandybo says:

    Hi Aaron – That's great, just what I'm looking for. Thanks

  39. Tudor says:

    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

  40. astebner says:

    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).

  41. Tudor says:

    Thanks for the reply.

    As indicated we had to give up vcredist executable because of many disadvantages: no progress, difficult to verify and support cancel in a multi-package install, no checks if it is already installed (in which case you might get a reboot (see above) and there is nothing no one can do about it. We use Msft's merge modules in an MSI package. The message I get clearly in the installation log is that the assembly (not the file) is in use and a restart will complete the operation.

    I would expect that at least one service/application on Windows 7 Home Edition is built dynamically linked to VC9 runtime so I don't find unnatural the assembly (x86, VC90, CRT, etc.) is in use but why adding a new version of it would cause a restart? Why does this not happen on the rest of the machines if it is by design?

    There are many expected situation where MSI needs a restart and we have ruled the standard ones out. With the information I have now this seems to be an expected functionality. But again, if this is by design, why doesn't it happen on the rest of the machines? We have done thousands of installs, on Windows 7 Home Editions as well but only one, installed by some testing team in China, was able to reproduce an issue occurring to some 3000 users from a few millions that use the software daily.

    Anyway, we will try some kind of workaround(to be read: hack) to get around this problem.

  42. Tudor says:

    "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.

  43. astebner says:

    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.

  44. Tudor says:

    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

  45. astebner says:

    Hi Tudor – That's strange, I haven't seen that type of syntax used for files in use in an MSI log file before.  Here is what is in there:

    MSI (s) (E8:20) [16:23:30:068]: Product: MSVC90_x86. The assembly 'Microsoft.VC90.MFC,version="9.0.30729.4148",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86",type="win32"' for component '{AFA31654-361E-33B5-9ED5-049A6889325C}' is in use. You must restart to update the assembly.

    Typically, I'm used to seeing more detailed logging that lists the process name/ID of the process holding the file in use.  

    This is a Win32 assembly, and your OS is Windows Vista according to the log file, so in that case, the installation of the assembly is managed by the Windows component install infrastructure and that may be why the MSI log doesn't have very useful information in it.  There may be more detailed logging in the file %windir%logscbscbs.log to help explain the reboot request.  Would it be possible for you to make a copy of that log on your computer, zip it, and upload it to your Skydrive share as well so I can take a further look?

  46. Tudor says:

    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:+).

  47. Tudor says:

    Sorry for the bad links: here is the public link:  cid-7093e07d98664f80.skydrive.live.com/redir.aspx

  48. astebner says:

    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?

  49. Tudor says:

    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

  50. astebner says:

    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.

  51. Tudor says:

    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.

  52. gmiller says:

    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?

  53. astebner says:

    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?

  54. gmiller says:

    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)

  55. astebner says:

    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.

  56. gmiller says:

    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.

  57. astebner says:

    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.

  58. gmiller says:

    You're right – the log file does contain this info. I swear I looked before but didn't see it! :) Thank you.

  59. gmiller says:

    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.

  60. astebner says:

    Hi Gmiller – There is a custom action in this installer to try to encourage people to use the setup.exe bootstrapper instead of running the MSI directly.  You can bypass that custom action by passing the property USING_EXUIH=1 on your msiexec command line.

    I'm not sure why this custom action was added in this servicing release when it wasn't present in the original release of this redistributable though.  I'm sorry for the hassles.

  61. gmiller says:

    Thanks Aaron – that's extremely helpful to know!

  62. Dev says:

    Hi Aaron, these are the lines of the log generated during jre installation. some of the log line shows info:1903 and it requires reboot to complete the operation. now my question is If we don't reboot the system, then what will be the outcome. will the installed jre behave normally or I may face some issues ? Also the return code of the windows installer is 3010 (which means Restart required).

    MSI (s) (28:8C) [10:03:50:897]: Verifying accessibility of file: jce.jar

    MSI (s) (28:8C) [10:03:50:944]: Executing op: FileRemove(,FileName=jsse.jar,,)

    Info 1903.Scheduling reboot operation: Deleting file C:Program FilesJavajre6libjce.jar. Must reboot to complete operation.

    MSI (s) (28:8C) [10:03:50:944]: Verifying accessibility of file: jsse.jar

    MSI (s) (28:8C) [10:03:50:944]: Verifying accessibility of file: jsse.jar

    MSI (s) (28:8C) [10:03:50:944]: Using source file security for destination.

    MSI (s) (28:8C) [10:03:51:038]: Note: 1: 2329 2: 32 3: C:Program FilesJavajre6libjsse.jar

    MSI (s) (28:8C) [10:03:51:038]: Verifying accessibility of file: jsse.jar

    MSI (s) (28:8C) [10:03:51:038]: Executing op: FileRemove(,FileName=jvm.hprof.txt,,)

    Info 1903.Scheduling reboot operation: Deleting file C:Program FilesJavajre6libjsse.jar. Must reboot to complete operation.

    MSI (s) (28:8C) [10:03:51:038]: Verifying accessibility of file: jvm.hprof.txt

    MSI (s) (28:8C) [10:03:51:038]: Executing op: FileRemove(,FileName=logging.properties,,)

  63. astebner says:

    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.

  64. Dev says:

    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?

  65. astebner says:

    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.

  66. gmiller says:

    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.

  67. astebner says:

    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.