Scenarios where enabling Windows Installer verbose logging does not appear to work
A while back, I posted a list of instructions that can be used to enable Windows Installer verbose logging in order to troubleshoot MSI-based setup issues. Since then, some people have tried to follow those instructions in order to gather Visual Studio and .NET Framework setup log files and found that they did not produce any logs named %temp%\msi*.log like I described in that post.
Unfortunately, I neglected to explain a subtle but important point in that previous blog post. Some MSI-based setups are packaged with a setup bootstrapper package (also known as an external UI handler) that uses the Windows Installer MsiEnableLog API to enable verbose logging by default. When this API is used, Windows Installer will create the log file with the specified name and the specified logging attributes, regardless of the logging policy set in the registry on the system. For reference, Windows Installer system policy settings are described in more detail in this MSDN topic.
The net result of this logic is that the steps listed in my previous blog post do not need to be used to enable verbose logging for some product setups, and in fact will not cause logs named %temp%\msi*.log to be generated.
The following is a list of some products that I know of that use an external UI handler and the MsiEnableLog function, and that therefore create their own log files regardless of the Windows Installer logging policy on the system. Each link contains information about the names and locations of the logs that the products create:
- .NET Framework 2.0
- .NET Framework 3.0
- .NET Framework 3.5
- Office 2003
- Office 2007
- Office 2007 SP1
- SQL Server 2005
- Visual Studio .NET 2002
- Visual Studio .NET 2003
- Visual Studio 2005
- Visual Studio 2008
- XNA Game Studio 2.0
Many other MSI-based products, including the .NET Framework 1.0 and 1.1, will create a log named %temp%\msi*.log if you use the steps listed in my previous blog post.