Richard's Weblog

Charting with PowerShell

richmac — Tue, 28 Apr 2009 16:29:00 GMT

You may be aware that there are some 3-rd party add-ins for PowerShell that allow you to create charts and graphs from your PowerShell scripts. What you may not be aware of is that there is a free download from Microsoft that will allow you to do the...(read more)

Protecting Removable Drives with Bitlocker

richmac — Mon, 06 Oct 2008 12:36:46 GMT

In a recent post , I explained how easy it was to use Bitlocker to secure your drives in a dual-boot scenario with Windows Vista and Server 2008. Following this I had some discussions with colleagues about how to securely backup copies of the files...(read more)

Programming Hyper-V with WMI and C# - Getting Started

richmac — Mon, 11 Aug 2008 21:25:00 GMT

You may have seen from a recent post that I received a new laptop that was capable of running Hyper-V. Well, it's all fully installed and working, so I thought I might blog about it a bit. There are plenty of existing blogs on Hyper-V, so I thought I...(read more)

(Virtually) Everything You Need to Know About Hyper-V

richmac — Mon, 21 Jul 2008 12:00:00 GMT

Following on from my post last year on general virtualisation resources, here is a similar one just for Hyper-V. Enjoy! Note: Thanks to my colleague, Tushar, who sent some of these links around to our team recently. Official Hyper-V Web Sites Hyper-V...(read more)

Vista, Server 2008 and the Case of the Bitlocker Dual Boot

richmac — Sat, 19 Jul 2008 04:10:29 GMT

This week, I received my shiny new work laptop, which I'd been anticipating for some time. Normally, I'm not much of a hardware geek and don't get overly excited with new kit, but I was really looking forward to this as it is 64-bit and finally...(read more)

Manipulating Performance Monitor Logs

richmac — Tue, 08 Apr 2008 20:50:00 GMT

If you need to monitor or troubleshoot performance problems on a Windows system, chances are you'll simply fire up PerfMon, log some data to a file, which you later load in PerfMon for analysis. This is great and is often all that you need, but it's a...(read more)

Viewing Your MSDN Product Keys Off-Line

richmac — Mon, 10 Mar 2008 00:13:00 GMT

If you have an MSDN subscription, then you'll know that the subscription includes a set of product keys for use with the versions of Office, Windows, etc that your subscription gives you access to. The keys can be viewed on-line at the MSDN subscriber...(read more)

Forcing Theme Settings in Windows Vista

richmac — Fri, 17 Aug 2007 13:48:00 GMT

Recently I was working with a customer to find a way to automate forcing a specific Aero theme in Windows Vista. The idea was to have the Vista clients "colour-coded" according to their use; so whenever a user logs on the window border colour would indicate...(read more)

Service Security in Windows Vista

richmac — Wed, 27 Jun 2007 13:30:00 GMT

After a long break from blogging due to holidays and a heavy workload, I've finally got round to writing something new. To follow on from my last post on File and Registry Virtualisation , I thought I'd take a look at another Vista security-related topic:...(read more)

Windows Vista File and Registry Virtualisation

richmac — Fri, 18 May 2007 15:50:00 GMT

Windows Vista is designed to be more secure than previous versions of Windows. Part of the improvements are related to User Account Control (UAC), which encourages the good practice of not logging on with an Administrator account (and even if you do,...(read more)

Clustering Best Practices: Checking Hotfix Compliance

richmac — Fri, 04 May 2007 01:30:00 GMT

Do you use Microsoft Clustering? Are your clusters configured according to the current Microsoft recommended practices? How can you be sure of the configuration? Questions, questions. The first is easy, the second you might be unsure of and the third...(read more)

Professional Microsoft Virtual Server 2005

richmac — Wed, 18 Apr 2007 00:59:00 GMT

The eagle-eyed among you may have noticed a reference to an unpublished Virtual Server book buried in the middle of my recent list of virtualisation resources . At the time I compiled the list, the book wasn't actually available, but it is now, so I thought...(read more)

(Re-)Start Me Up ...

richmac — Fri, 13 Apr 2007 04:30:00 GMT

As I mentioned in a recent post , I'm currently working on a Windows Vista workshop. As part of that, I've created a simple application that demonstrates the basic interaction of the Windows Installer with Vista's new Restart Manager (RM). I thought I'd...(read more)

Windows Vista Resource Kit Released

richmac — Thu, 05 Apr 2007 02:58:00 GMT

If you're a long-time Windows Admin, then you'll know how invaluable the Windows Resource Kit has been for the various Windows versions over the years. Now the Windows Vista version has been released and with 1,500 pages of in-depth technical information...(read more)

How to Interpret Windows Installer Logs

richmac — Mon, 02 Apr 2007 22:43:00 GMT

[Updated: 4 April 2007]

If you have a problem with the Windows Installer or an MSI package you're installing, it's a sure bet that you will be told by some smart person to "enable logging".

That's great advice, except ... what do you do with the log once you get it? A common technique is to open it in Notepad and scroll up and down aimlessly, hoping to spot the "cause of your problem" section. While this is a very popular approach, it rarely yields good results. In this post, I'll walk you through the contents of a typical log so that next time you have an Installer problem you'll be in a better position to troubleshoot it yourself.

"Enable Logging"
First things first. If you are to take your smart friend's advice, you need to know how to generate a log. There are a number of ways to do this:

Command-Line
If you can install the MSI package from the command-line, even if only for troubleshooting, then this is a very easy way to generate a log. Simply use the "/l" switch during install:

msiexec /i SomeApp.msi /l*vx %temp%\SomeApp.log

Using the "*vx" modifier gives the most detail possible - you should always use this when troubleshooting.

Registry or Group Policy
If you cannot run the package from the command-line, then enable logging directly in the registry or via Group Policy, as described in KB223300: How to enable Windows Installer logging.

MsiLogging and MsiLogFileLocation properties
With MSI 4.0 these two properties can be set in the Property table of a package to enable logging and specify the log location. See MsiLogging Property for more details.

Installer API
If you are developing an Installer-aware application, you can use the MsiEnableLog API to enable logging for the lifetime of the calling process.

With so many ways to do this, it should be obvious that the Installer team take logging very seriously, and as you'll see the Installer logs a lot of information. Also, with all those methods available to you, you've really got no excuse for not using logging.

Log Contents
Once you have a log, here's what to expect it to contain:

General Contents
By default logs will contain things such as:

Most errors that occurred during the install including all Windows Installer errors that generate a user dialog.
Which custom actions were run.
Whether a reboot was requested and completed.
Values of Installer Properties, including details of any changes.
The source location.
Whether the user cancelled the install.
Where an install stopped.
Whether an install rolled back.
Client and Server information

The Windows Installer runs an installation in two distinct processes: Client and Server. These terms are intended to be used in the COM sense where the client and server are just different processes and not in the sense of distinct client and server computers on the network. The same log file will show information from both processes.

An action by the client process is denoted in the log by "(c)":

MSI (c) (C0:6C) [22:17:24:911]: SHELL32::SHGetFolderPath returned: C:\Users\Admin\AppData\Roaming

An action by the server process is denoted in the log by "(s)":

MSI (s) (38:90) [22:18:04:544]: Doing action: LaunchConditions

The "(30:90)" notation represent the "(processID:threadID)" that generated the entry. Only the last 2 (hexadecimal) digits of the process and thread IDs are given. For example, (30:90) could be generated by process ID 130 and thread ID 290. The time of the log entry is shown next in square brackets.

The log file will first show the client process as dialogs collect user information. After the user information is collected, it is time to do the setup work and the installation switches to the server process. For installations run with no visible UI, the client process is skipped:

MSI (c) (E4:F0) [22:52:31:105]: Client-side and UI is none or basic: Running entire install on the server.

The beginning of the server process looks very similar to the beginning of the client process. The service must re-evaluate all of the settings, to prevent a user from performing insecure operations. All of the private properties, policies, and other installation state settings must be re-evaluated.

Error Codes
The Installer logs a lot of useful information in the form of 'error' codes. Sometimes these are genuine errors, but often they are simply for information purposes and do not indicate a real problem. Full details of all codes can be found in the MSDN Library or the Windows Installer SDK.

As an example, take the following entry from the annotated log below:

MSI (c) (C0:6C) [22:17:24:953]: Note: 1: 1402 2: HKEY_CURRENT_USER\Software\Microsoft\MS Setup (ACME)\User Info 3: 2

The SDK defines the code 1402 as:

Could not open key: [2]. System error [3].

Thus we would read the log entry as:

Could not open key: HKEY_CURRENT_USER\Software\Microsoft\MS Setup (ACME)\User Info. System error 2.

System error codes can be found in the Platform SDK file Winerror.h or using the Net HelpMsg command:

In this case error code '2' resolves to "The system cannot find the file specified."

C:\>net helpmsg 2

The system cannot find the file specified.

Return Values
After each action the Installer will record the 'return value' in the log. This is an indicator of the success or otherwise of the action. Possible values are:

Value	Meaning
0	Action was invoked, but did not run (not necessarily a bad thing, maybe there was nothing for it to do)
1	Action was a success
2	Action was cancelled by user
3	An unrecoverable error has occurred
4	The installation was suspended awaiting a reboot

Simply searching for the phrase "Return Value 3" can be a quick way of pinpointing the errors in a log. This isn't guaranteed to lead to the source of a problem as some problems are quite subtle, but it's good first step. It may also break down in localised setup scenarios.

Annotated Verbose Installer Log
Here is an annotated Installer log to use as a reference during your own troubleshooting:

Annotated Windows Installer Log (.docx)

Annotated Windows Installer Log (.pdf)

This log was generated by installing the Debugging Tools for Windows on Windows Vista Ultimate (so MSI 4.0).

Installer logs tend to contain a lot of repeated entries. For example, all file copy operations look alike. So to make understanding the log easier most of the repetition is omitted and only useful examples of each entry type are shown; the original log contained over 5900 entries, but this reduced log contains around 1000. This is a lot less, but is still too much for a simple blog post, hence the downloadable file.

Wilogutl.exe
If you've used Installer logging before, then you probably read to this point thinking "why not just use Wilogutl?". It's a good question and the reason I think you should work with the logs directly is encapsulated in number 1 rule of using the Windows Installer:

Rule 1: Learn the Windows Installer Technology
The importance of this rule cannot be overstated. If you only follow one rule, this is the one to choose.

Microsoft Product Support often speak to Installer users who are installing packages which they created with a sophisticated high-level re-packaging tool, without any understanding of how the Installer actually works. While these tools are excellent at what they do and they abstract the user from the details on a day-to-day basis, the lack of Installer knowledge becomes a real problem when the package does not work as expected. Setup authoring is not simply about copying files. The Installer offers extensive functionality and complexity; understand it before you start authoring packages.

Reading through a lot of logs and using them to troubleshoot real problems is a great way to learn about how the Installer works. Obviously, once you're confident with the underlying technology you can return to using helpful tools to do the work for you.

If you are wondering what on Earth "Wilogutl" is, then have a look here:

Wilogutl.exe
Wilogutl.exe assists the analysis of log files from a Windows Installer installation, and it displays suggested solutions to errors that are found in a log file.

I won't discuss how to use Wilogutl here, but may do so in a future post.