Visual Studio 2013 continuously repairs producing many small log files

If you have Microsoft Visual Studio 2013 Professional, Premium, or Ultimate editions installed and are finding many small MSI*.log files in your %TEMP% directory, you may find you are running low on disk space because of how many of these files are created. While they may only be about 3MB, what causes these files to be produced can do so often enough that it may not take long to fill up the drive where %TEMP% resides.

Workaround

We are consistently seeing this issue caused by a missing directory, C:\Windows\Microsoft.NET\Framework\URTInstall_GAC (or %SystemRoot%\Microsoft.NET\Framework\URTInstall_GAC).

To work around this issue,

1. Open an elevated command prompt.
2. Type: mkdir %SystemRoot%\Microsoft.NET\Framework\URTInstall_GAC

In PowerShell, use $env:SystemRoot instead of %SystemRoot%.

Description

This problem is similar to a previous one that was caused by a different directory, only in this case it typically only happens after an OS upgrade. The .NET Framework created %SystemRoot%\Microsoft.NET\Framework\URTInstall_GAC as a staging directory for installing assemblies into the GAC (since the .NET Framework may be installing managed fusion for the first time, it can’t use built-in support). When Visual Studio 2013 is installed on Windows 7 the .NET Framework is installed via Windows Installer. Later OS upgrades migrate the .NET Framework to the Windows native installer format (CBS) but that directory isn’t created since those fusion custom actions aren’t used.

Unfortunately, advertised shortcuts in VS2013 Professional (part of Premium and Ultimate) cause a health check because some assemblies are installed into the GAC and since the directory doesn’t exist, Windows Installer initiates a repair operation that does not create the directory. This causes the problem to occur again and again until the directory is created manually.

If you have the Windows Installer Logging policy set (or the host program initiating the health check enables it via MsiEnableLog), those MSI*.log files won’t help much but to identify the calling program, which we typically see as,

%SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\mscorsvw.exe

If you search the Windows Application event log for the MsiInstaller source, the event description for event ID 1004 should say something like,

Detection of product '{9C593464-7F2F-37B3-89F8-7E894E3B09EA}', feature 'Visual_Studio_Professional_x86_enu', component '{E3FF99AA-78B9-4A06-8A74-869E9F65E1FE}' failed.  The resource 'C:\WINDOWS\Microsoft.NET\Framework\URTInstallPath_GAC\' does not exist.

Creating this directory (whatever directory event ID 1004 specifies) should stop the MSI*.log files from being created in droves.