Vista KB942763 Update Failure and Solution

So Friday I got around to firing up our Vista Home Premium system and downloading the slew of Microsoft Patch Tuesday updates I had waiting.

They all installed without any issues or complaints,

except for KB942763.

This is the December 2007 cumulative time zone update for Microsoft Windows operating systems.

Hmmm.

So I attempted a reinstallation. It downloaded again and failed.

So I rebooted the system and tried again. Failure.

So I next went and downloaded the Vista x32 patch version for Vista to a manual installation.

It failed as well.

Hmmm.

Sounds like time for some research....

To the InterWebs....!

First thing I did was to do a Google search.

Seems that there are quite a number of Vista users who are also having an issue with this patch.

The error code 80070643 is pretty cryptic and though some feel seems to tie into Microsoft Office installations, I doubt it had anything to do with that.

They seem to have tried all the things I did to no avail.

Most of them just punted and set the update to "hide" so it doesn't keep presenting itself.

I did that as well, but wanted to see if there were any clues. Time to break out my safari-gun.

Peeking Behind the Curtain

I fired up Process Monitor, set some filters and began event capture.

Then I re-ran the installer until it failed and I had closed it out.

I then began reviewing the data...and there was lots to sift through.

The very first thing I looked for were "Failed" results...only there really weren't any that would appear to stop the program from working. There were lots of queries and registry writes, but no show-stoppers. Strange.

By examining the Process Tree history view, I could track the following events:

1. TrustedInstaller.exe launches and beings a process called tzupd.exe (Microsoft timezone refresh utility) from the following path: C:\Windows\WinSxS\x86_microsoft-windows-i..rnational-timezones_31bf3856ad364e35_ 6.0.6000.16520_none_134b76120c7bbaad\
2. From that location it runs it with the following argument: /uninstall
3. Next it runs the wemgr.exe (Windows Problem Reporting) tool with the following argurments: -outproc" "1068" "1400"
4. Then it runs tzupd.exe again with the following command: "C:\Windows\servicing\GC32\tzupd.exe" /install
5. Then it runs tzupd.exe again with the following command: "C:\Windows\WinSxS\x86_microsoft-windows-i..rnational-timezones_31bf3856ad364e35_ 6.0.6000.16589_none_131399240ca44662\tzupd.exe" /uninstall
6. Our friend wemgr.exe gets the spotlight again: "C:\Windows\system32\wermgr.exe" "-outproc" "1068" "1860"
7. Finally, tzupd.exe makes it last appearance: "C:\Windows\servicing\GC32\tzupd.exe" /install

I could see tzupd.exe running from multiple locations, but whatever it was trying to accomplish wasn't working.

Wonder if the tzupd.exe files can tell me anything.

Regarding TZUPD.EXE

I checked the properties of the file and found that it (and it's counterpart tzres.dll) that were running from these locations were listed as version 6.0.6000.16520 and dated 8/31/2007.

Hmmm, that is indeed strange...I think I see a possible lead.

Microsoft provides the following file information for Vista in KB942763.

File information

The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time item in Control Panel.

Windows Vista, 32-bit versions

File name File version File size Date Time Platform

Tzres.dll 6.0.6000.20712 2,048 30-Oct-2007 23:59 x86

Tzupd.exe 6.0.6000.20712 18,944 31-Oct-2007 01:46 x86

Tzres.dll.mui 6.0.6000.16589 19,456 31-Oct-2007 03:52 Not Applicable

This file information didn't seem to jive with what I was finding running on my system. According to the KB, I should be finding a file version with at least that version number/date or later.

It was clear that the tzupd.exe file that was executing and failing from my update patch wasn't what was expected. I now suspected that is why the update was failing...it wasn't using the expected version.

So, how can I tell if the version in my downloaded patch was correct?

Can I unpack the KB patch file...like I do when I am slipstreaming?

Yep...you just have to know how.

The Secret MUS File Door Knock

The downloaded patch is named Windows6.0-KB942763-x86.msu

The MSU file extension stands for "Microsoft Update Standalone Package".

I eventually located this tip by John Savill at Windows IT Pro:

Q. How can I extract the files from a Windows Vista Microsoft Update Standalone Package (MSU)?

A. The new MSU format doesn't support the old /x type switches to extract the content. It also can't be run on a pre-Vista OS. To extract the content from an MSU file, you need to use the Expand command that's part of Vista. Note that the Expand command from earlier versions of Windows are different and won't work. Use the -F switch to extract the content, as the following example shows:

D:\temp>mkdir msu

D:\temp>expand -F:* Windows6.0-KB929761-x86.msu d:\temp\msu

The command produces the following output:

Adding d:\temp\msu\WSUSSCAN.cab to Extraction Queue
Adding d:\temp\msu\Windows6.0-KB929761-x86.cab to Extraction Queue
Adding d:\temp\msu\Windows6.0-KB929761-x86-pkgProperties.txt to Extraction Queue

Adding d:\temp\msu\Windows6.0-KB929761-x86.xml to Extraction Queue

Expanding Files ...

Expanding Files Complete ... 4 files total.

At this point, the .cab files, which contain the actual files, are still not extracted, so now run the extract command on the cab file, as the following command and resulting output shows:

D:\temp>expand -F:* d:\temp\msu\Windows6.0-KB929761-x86.cab d:\temp\msu

Adding d:\temp\msu\update.mum to Extraction Queue
Adding d:\temp\msu\x86_microsoft-windows-wusa_31bf3856ad364e35_

6.0.6000.20496_no
ne_ab489c6034d78613.manifest to Extraction Queue
Adding d:\temp\msu\x86_microsoft-windows-
wusa_31bf3856ad364e35_6.0.6000.16400_no
ne_ab1a4f0b1b764fed.manifest to Extraction Queue
Adding d:\temp\msu\update-bf.mum to Extraction Queue
Adding d:\temp\msu\x86_microsoft-windows-
wusa.d_31bf3856ad364e35_6.0.6000.20496_
none_4632ef2815ba2cfd.manifest to Extraction Queue
Adding d:\temp\msu\x86_microsoft-windows-
wusa.d_31bf3856ad364e35_6.0.6000.16400_
none_4604a1d2fc58f6d7.manifest to Extraction Queue
Adding d:\temp\msu\update.cat to Extraction Queue
Adding d:\temp\msu\update-bf.cat to Extraction Queue
Adding d:\temp\msu\x86_microsoft-windows-
wusa_31bf3856ad364e35_6.0.6000.16400_no
ne_ab1a4f0b1b764fed\wusa.exe to Extraction Queue
Adding d:\temp\msu\x86_microsoft-windows-
wusa_31bf3856ad364e35_6.0.6000.20496_no
ne_ab489c6034d78613\wusa.exe to Extraction Queue

Expanding Files ....

Expanding Files Complete ... 10 files total. --------------------

Using this sample, I quickly expanded my particular MSU file, and then its CAB file "Windows6.0-KB942763-x86.cab"

Only problem was that when I dived into the results, there were 368 objects in the resulting folder.

Hmm. Luckily I found what I was looking for (tzupd.exe and tzres.dll) in the following folders:

"\x86_microsoft-windows-i..rnational-timezones_31bf3856ad364e35_6.0.6000.16589_none _131399240ca44662"

and

"x86_microsoft-windows-i..rnational-timezones_31bf3856ad364e35_6.0.6000.20712_none _13e1e543258f6e5b"

Notice the highlighted sections in both names gives the version number of the files.

These were indeed older than the ones my system was using to perform the patching:

They all ended up being dated 12/16/2007 in their file properties.

Very interesting...

Can I Manually Swap Them?

So my next thought was that maybe the rights on the files was too high to allow the installer to work. (Sure, I know it's dumb, but I've seen stranger things at work with file/folder permissions.)

My plan was to rename to old versions of the files where they were being accessed via Process Monitor, then add in the new ones I had unpacked. That should do the trick.

Only one problem....the security settings on the files would only allow "Trusted Installer" permission to change/modify/delete the files. Not even System or Administrator had sufficient rights (these were set only at "Read & Execute" and "Read."

Turns out that "Trusted Installer" is actually a service and not a user. You won't find in in the users list even though it has file permissions all over a Vista system. This forum post by "Darrell Gorter [MSFT]" hits the important points:

This is part of the new ACLS to help improve security in Windows Vista

From this link below: I am posting a couple of paragraphs that talk about
Trusted Installer:

http://www.microsoft.com/technet/technetmag/issues/2007/06/ACL/defaul...

Trusted Installer The Trusted Installer is actually a service, not a user,
even though you see permissions granted to it all over the file system.
Service hardening allows each service to be treated as a full-fledged
security principal that can be assigned permissions just like any other
user. For an overview of this feature, see the January 2007 issue of
TechNet Magazine. The book Windows Vista Security (Grimes and Johansson,
Wiley Press, 2007) explores service hardening in detail, including how it
is leveraged by other features, such as the firewall and IPsec.

Trusted Installer In Windows Vista, most of the OS files are owned by the
TrustedInstaller SID, and only that SID has full control over them. This is
part of the system integrity work that went into Windows Vista, and is
meant specifically to prevent a process that is running as an administrator
or Local System from automatically replacing the files. In order to delete
an operating system file, you thus need to take ownership of the file and
then add an ACE on it that lets you delete it. This provides a thin layer
of protection against a process that is running as LocalSystem and has a
System integrity label; a process that has lower integrity is not supposed
to be able to elevate itself to change ownership. Some services, for
instance, can run with medium integrity, even though they are running as
Local System. Such services cannot replace system files so an exploit that
takes over one of them can’t replace operating system files, making it a
bit harder to install a rootkit or other malware on the system. It also
becomes more difficult for system administrators who are offended by the
mere presence of some system binary to remove that binary.

I then reviewed this post Nothing ventured, nothing gained : Deleting from the WinSxS directory which explained more details about the rights and security token for TrustedInstaller. However it didn't leave me hopeful:

That long SID (S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464) is the service sid for Trusted Installer. By parts, that SDDL means "the owner and group are Trusted Installer; there is a protected and auto-inherit DACL; the ACEs of that DACL grant the trusted installer full access; the ACEs of the DACL also grant builtin-administrators, local system, and builtin users generic-read and generic-write access; each ACE is also automatically inherited by child containers and child objects."

So, the security descriptor on the object will prevent even administrators from creating or deleting objects underneath %windir%\winsxs, which is why even an elevated administrator cannot (by default) delete content.

Elevated administrators do have (by default) the SeTakeOwnership privilege enabled. Such a token could take ownership of anything under %windir%\winsxs. Once the owner, the administrator could then reset the SDDL on the object, granting themselves full access to the object. Of course, the generic LUA administrator token does not allow enabling the "take ownership" privilege, so this is only possible after answering the LUA elevation prompt successfully.

I leave it to the intrepid user to figure out the correct combination of "takeown.exe", "icacls.exe", and "rmdir" to actually remove content.

Fortunately, it appears Darrell Gorter is a brilliant guy as I next found this tip of his in another forum post:

You can follow the steps at the bottem of this article:
929833 Some Windows Vista functions may not work, or Windows Vista may stop
responding
http://support.microsoft.com/default...b;EN-US;929833
. At an elevated command prompt, type the following command, and then
press ENTER:
takeown /f Path_And_File_Name
For example, type takeown /f E:\windows\system32\jscript.dll .
2. Type the following command, and then press ENTER to grant
administrators full access to the file:
icacls Path_And_File_Name /GRANT ADMINISTRATORS:F
For example, type icacls E:\windows\system32\jscript.dll /grant
administrators:F .
First you have take ownership of the files and folders, Then you have
grant permissions to be able to delete them.

Yes! I forgot about the "takeown" and "icacls" commands. How silly of me.

But that jogged something else loose in my memory...where had I seen a reference to icacls before?

Yep...in this article by Mark Minasi "chml: A Utility To Manage Windows Integrity Levels".

chml is a freeware power-toy utility that allows administrators to escalate or deescalate the integrity level of Windows files. It is a really cool tool to use and really simplifies changing ownership rights on files. Go read his article for the details and the tool. Good stuff. Couple it with the Sysinternals tool PsExec and as Mark Minasi shows, you have a powerful one-two punch combo to take future malware on Vista that adopts file permissions greater than Administrator down. Sweet. Let's hope we don't need this technique for a while...

Sounds like I'm in for some effort trying to escalate my rights enough to take ownership of these files...and the possibility of doing some bad mojo to my Vista system if I do something wrong.

I would need to de-escalate the rights on the target files, change the names, drop in the new file versions I extracted from the MSU update file, escalate their rights up to TrustedInstaller (they are protected for a reason) then give the installer another run. I bet it would work...but is the risk worth it?

Time for the Thinking Chair

Here is what I know knew: The update file from Microsoft did indeed consist of a very recent file version and date.

1. The updater running on my system was actually using an older version of the tzupd.exe file already there from a previous patching.
2. I was almost certain that because the updated file wasn't being allowed to be used that was the cause of the patch failure.
3. I wasn't seeing any clear failure events when monitoring the patching process using ProcessMonitor.
4. I had a plan and a means to do manually drop the correct files, but the swap might wreck my system, if it would work at all. Big chance on just a timezone update.

Then I realized something...what else could be possibly intercepting my installation? Maybe my newly patched Comodo Firewall that has both a firewall and its "Defense+" system and process guard?

What are the odds?

So I disabled both the firewall and the "Defense+" protection (but didn't reboot) and tried the update again.

Nope. Still failing.

So I considered the options.

I could try to disable Comodo firewall in with AutoRuns and do a reboot. I took a review and found three entries and services that I could disable, but then I thought: What if I didn't get them all? Would it make a no-boot situation? Maybe Comodo had a fail-safe.

So I took the safer route and just uninstalled it.

I rebooted and ran the installer again.

The Vista KB942763 Update Failure Solution - Uninstall Comodo firewall

Success!

(Note: See update to post further below for a more elegant solution than a complete uninstall of Comodo...)

Post Mortem

I thought to run Process Monitor during the each installation process. This time the Process Tree just showed TrustedInstaller running tzupd.exe two times:

"C:\Windows\WinSxS\x86_microsoft-windows-i..rnational-timezones_31bf3856ad364e35_6.0.6000.16520_ none_134b76120c7bbaad\tzupd.exe" /uninstall

and

"C:\Windows\servicing\GC32\tzupd.exe" /install

Both times were successful as the tzupd.exe file version this time was 6.0.6000.16589 dated 12/14/2007.

So was this just a strange conflict between Comodo's Defense+ and this particular KB942763 patch? All the other updates from December 2007 went on without any issues, what made this one special?

Should I go back and reinstall Comodo firewall now? Will I need to uninstall it again at the next round of Windows Updates? What impact might it have on the upcoming Vista SP1 release going on smoothly?

What's more, I have the same settings for Comodo firewall and Defense+ on my XP systems as well and it didn't interfere with the KB going on any of them.

Somehow I suspect the primary issue isn't with the Comodo firewall but the Defense+ portion and how it interacts and guards certain files and processes along with the highest "TrustedInstaller" rights of those files.

One thing I didn't do was to try and disable the "Defense+" feature only, then reboot with it disabled to see if the installation would work (without fully uninstalling Comodo firewall).

I think I am going to reinstall Comodo now and just keep the Defense+ portion disabled on the Vista system.

Then if I see any more Windows Updates failing, I know who my prime suspect will be.

Troubleshoot kindly!

--Claus

Update - The "Elegant" Workaround

A super thanks to pclemo for sharing this easier technique in the comments earlier.

Following these steps avoids having to do a complete uninstall of Comodo firewall as I did. That way works but this is way better. Thanks also to JohnN for independently confirming it works!

1. Find the Comodo icon in the system tray and right-click on it.
2. Click "Open..."
3. In the Comodo program window, click on the "Defense+" shield in the top bar area
4. On the left-hand side you will see the "Defense+ Tasks" column.
5. Click on the "Advanced" icon.
6. Find the "Defense+ Settings" in the last row and click on the name to open this section in a new window.
7. The very bottom checkbox says "Deactivate the Defense+ permanently (Requires a sysem restart), check the box.
8. Click the "Apply" button.
9. A "Restart Required" window will appear. Select "Yes" to restart your system.

Note: The summary will now state that the Defense+ security level is set to Inactive.

10. Once the system has come back on and you are on your desktop, install the KB942763 patch.
11. Now, repeat steps 1-8, but in step 7 uncheck the "Deactive the Defense+ permanently" option box.
12. Do a final system reboot and your system should be back to normal; having both the patch installed successfully as well as the Comodo firewall's Defense+ setting enabled again.

More questions:

Like pclemo, I am also wondering if there isn't an even easier way of disabling Comodo's Defense+ just enough to let this patch install without completely shutting the thing down. I did try to disable it in my earlier troubleshooting by using the slider but it didn't help. I didn't do a reboot which might have helped. However if that requires a reboot, it doesn't seem any easier or more effective that just disabling it as pclemo suggested. So I'm not sure that there is any net gain by using another method if it requires a system reboot anyway.

I hope this post and updated "elegant" method shared by pclemo help end Vista/Comodo user's frustrations around the globe who are dealing with this issue.

We are glad to share our experiences and help!

--CV