Logging for the New Patch Wrapper

Logging for the New Patch Wrapper

  • Comments 7

One of several apparent improvements for the new patch wrapper is better logging support. More often than not if a problem occurred while trying to install the patch it was difficult to diagnose because there was no logs for the patch installation itself. A user would have to extract the .msp file and install it using msiexec.exe and pass verbose logging options, or would have to enabled the Windows Installer logging policy and find the right MSI*.log file in their his or her %TEMP% directory. Now all logs are created by default for both the wrapper and the patch itself.

The new patch wrapper will create a verbose log for each application of the patch, so that if the patch applies to multiple products installed on your system multiple patch logs are created. If all patch applications occur successfully the logs are deleted; any failures will leave the logs on your system which can help you and us diagnose the problems better without having to reproduce the problem just to get logs again.

The logging policy for the wrapper follows.

  • The wrapper will write its own log in a directory with the same name as the patch executable in the %TEMP% directory, and will have the name of the patch as originally downloaded with -wrapper.log appended. For example, if you download NDP20-KB123456-ENU.exe there will exist a %TEMP%\NDP20-KB123456-ENU\NDP20-KB123456-ENU-wrapper.log file.
  • If the Windows Installer logging policy is not set, verbose logs will be created in the patch-specific temporary logging directory described above with the patch executable name with -msi-%d.log appended, where %d is from 0..n for each time the patch is applied to a product installed on your machine. For example, if you download VS80-KB789012-ENU.exe that patches both VS core and the remote debugger (which are two separate packages) there will exist two files in %TEMP%\VS80-KB789012-ENU named VS80-KB789012-ENU-msi-0.log and VS80-KB789012-ENU-msi-1.log.
  • If the logging policy is set, the specified logging options are used to create log files in the %TEMP% directory with file names in the format MSI*.log and the log files are not deleted even if the patch is installed successfully for every applicable product installed.
  • If the Windows Installer logging options are passed to the command-line those options are used to write to the specified log file and the log file is not deleted even if the patch is applied successfully for every applicable product installed. If the patch applies to multiple products — and many Visual Studio patches will — you should pass + as a logging option to append to the specified log for each patch. This may be a little more difficult to diagnose problems since multiple patch installation transactions will be in the log, but you can search for "logging started" to find the beginning of the log section for each patch application. Even though you may specify a path to the log file using the logging options the patch wrapper log will still be in its respective directory in the %TEMP% directory.

When requesting support for patch installation issues, be sure to bundle all these logs together. Remember that if you just double-click the patch or even just run it from Windows Update and any failures occur, you can find a directory with the same name as the patch executable in your %TEMP% directory. If you're downloading from Windows Update and don't know the name, just switch the view of your %TEMP% directory to the Details view and sort by "Date Modified" to find the most recent patch-specific temporary logging directory.

For more information about the logging policy for the .NET Framework 2.0 and Visual Studio 2005 installs read Quan To's post about where to find the Visual Studio setup logs.

Leave a Comment
  • Please add 4 and 4 and type the answer here:
  • Post
  • I found a couple of articles that Heath Stewart wrote a few months ago that I somehow missed at the time...
  • One of the most-reported feedback issues with Visual Studio 2005 Service Pack 1 Beta is about how long

  • Quite a few beta customers have reported that the Visual Studio 2005 Service Pack 1 Beta install requires

  • Some customers are reporting that Visual Studio 2005 Service Pack 1 Beta tries to install multiple times.

  • Visual Studio 2005 Service Pack 1 can take a long time to install and may apply to multiple products

  • A link to Aaron Stebner's troubleshooting guide for Visual Studio 2005 and .NET Framework 2.0 setup (and patching).

  • How to diagnose errors when installing, repairing or patching, or uninstalling a product using Windows Installer technology.

Page 1 of 1 (7 items)