Sunday, December 16, 2007

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

13 comments:

Anonymous said...

i have been trying to get this update to install since last week with no luck. i followed your advice, uninstalled comodo and you were spot on it installed first time. many thanks. it was driving me nuts every time it failed...

Anonymous said...

There's no need to uninstall Comodo.
Open the CFP Gui, select the Defense+ tab -> Defense+ Tasks -> Defence+ Settings.
Check the option 'Deactivate the Defense+ permanently (Requires a system restart)'.
Note: The summary will state that the Defense+ security level is set to Inactive
Restart and install patch then revert to the original setting in Defense+ and restart again.
I'm sure there's an even more efficient way of doing this but as a casual user I'm too lazy to find out!

Claus said...

@pclemo

Thanks for this tip! I'll do some digging and update the post with your tip once I check it out.

I'm sure your suggestion will be greatly appreciated by Comodo fans.

This looks to be a more "elegant" temporary workaround that the more brutal "uninstall" method.

You are very generous to share it!

--Cheers!

John N said...

I have Comodo Pro Firewall and took the easy route suggested and then rebooted; installed the MS update; then changed the Comodo settings again and rebooted. Everything worked just great. Thanks for the tip.
John N

Anonymous said...

Thanks for your solution, but it didn't work on my Vista Basic computer.

Technically, you're right, this update problem is related to Comodo Firewall. But here's the issue for me: Defense+ was *already* disabled. I already checked off in the Comodo menu to disable it from the first day I installed, and I still had the Windows update issue.

In order to solve my problem (thanks to reading your blog), I had to completely uninstall Comodo, and now the update has gone through successfully. But simply disabling defense+ didn't work for me unfortunately. Is it because I'm using Vista Basic, I'm not completely certain.

I feel there is a deeper issue here between Windows Vista and Comodo, and it could affect the Vista SP1 coming soon. It's a shame because I prefer Comodo instead of Zonealarm, which Digg users once pointed out has spyware tendencies of sending secret packets of data back to its server

Claus said...

ChrisB.

I'm thinking this is going to end up being one of those "Try A, if not, then do B" solutions."

A = Set Defense+ to permanently disabled. Reboot. Patch. Reboot. Reactivate.

if not, then

B = Unistall Comodo, reboot, patch, reboot, reinstall Comodo.

Now that you mentioned it, I also had set the Defense+ portion to disabled during my Comodo's setup/installation process on Vista Home Premium. I don't think the version of Vista matters...

Can you confirm that even though your's was set this way, you did try the "permanently disable" method? The reason I ask is that I also tried the slider-bar method first (which didn't work) and even though it was disabled due to my setup selection...I didn't "permanently" disable it with this other option/reboot process. Could be that something in Comodo is still running and causing the conflict.

My problem here is I don't have a second "test-lab" setup for Vista at home. And I don't want to keep going through patch/firewall installations/un-installs to find the combos that work/don't on my working Vista system.

I appreciate all the info you are sharing in the comments. It helps.

I agree with your concern/assessment regarding Vista SP1 and Comodo. I think everything will be good, but just don't know. Comodo get's rated high due to it's leakproof firewall protections, but the addition of all the "HIPS" (Defense+) protection runs the risk of impacting the system. I personally don't use HIPS type protections on my system. Just a good old AV program and a firewall.

I'm also waiting for Sunbelt Software to come out with it's Vista compatable freeware firewall version. If these Comodo issues continue, I might just swap back to the default Vista firewall for now (though it offers no outbound/leaking protections).

I'm almost certainly going to disable/remove Comodo if I am still using it before dropping the final Vista SP1 update on my system...just to be safe as you pointed out as well.

John N said...

I am using Vista Home Premium and the disable worked fine. Also, Comodo has an update available as a patch and perhaps this will take care of the issue. Has anyone advised Comodo of the problems?
John N

Claus said...

Hi John N.

Good question! I had previously installed a Comodo patch prior to putting the update on my system, but wasn't paying attention to the version #'s so I don't know if it was the latest one or not (CFP 3.0.14.276 patch).

I do know that my current Comodo install is now at the .276 level.

I noticed in the release notes. that it mentions this: "Defense+ no longer allows some applications to modify a protected file if it is not allowed."

I wonder if this might have something to do with what we are seeing....

I peeped into the Comodo forums and found these very recent forum threads:

Windows update KB942763

Firewall 3.0.13.238: unable to install Windows Update because of Comodo

v3 is blocking some MS Vista updates

Comodo and Microsoft Updates

...including one it looks like you posted ;) Thanks for the mention!

From a very quick look at them all, it seems that there is a real mix of issues going on here. Some say the disable Defense+ method works for them, others say they tried it and it didn't help and they had to go with the uninstall method. Some say the updated patch version didn't help.

I also saw a mention about someone have an unrelated issue due to not running the Comodo GUI as "administrator" and getting prevented by UAC.

I'm sure Comodo team is hard at work on this.

I hope they give a final report in some form specifically addressing what the issue was and that they specifically fixed it...

Between Comodo's legendary toughness and Vista's UAC/file protections...I'm not surprised to see some of these issues right now as Vista is still a young OS system and it might take a while for security app programmers (and everyone else) to cut their teeth on it and get really good.

I appreciate everyone's comments and feedback!

Anonymous said...

Hi Claus,

Thanks for the tips. Very informative and appreciated. Didn't know Comodo was the problem.

I found tzres.dll and tzupd.exe in My Pending Files under Defense+. By adding these to My Own Safe Files, I could install the Update without turning off Defense+, or uninstalling.

Guess I just leave them there for any future updates.

John

Anonymous said...

I just wanted to say thanks for helping me solve my problem with several MS updates that I haven't been able to enter on my wife's Vista HP laptop. You reference to Comodo was the clue.

In my case Defense+ was already disabled so I went ahead and unstalled Comodo entirely. Once it was gone the three updates I'd been struggling with (some for two months) went right in with no problem.

I've reinstalled a newer version of Comodo and will keep my fingers crossed. Oddly I could find no reference at the Comodo site to any problems with MS updates.

I've been searching Google for days looking for help and yours is the first site I've found that connected installation problems to Comodo. You don't know how much I appreciate your post.

Thank you.

Anonymous said...

I'm glad you found the post helpful! It really was a frustrating situation.

The change notes for Comodo are a bit hard to find; try this link:

Comodo Firewall Pro - Release Notes

I've also updated to the very latest version and gone ahead and put Comodo Firewall back on my Vista system again. Will see how it works. So far so good.

I have disabled (turned off) the Defense+ features and am using the freeware ThreatFire HIPS solution instead. Don't know if one is any better than the other, but so far, so good with both Comodo and Threatfire in this configuration.

Since I am running AVG-Free (for AV) and Threatfire (for malware) I have turned off Windows Defender to help keep my system resources lightened. I have a post somewhere on this blog about that decision.

So far the Vista updates have been going on with no more issues. Hope this keeps up. I will probably disable all the firewall/HIPS/AV programs running when I get ready to install Vista SP1 on my system...just to be safe.

Thanks for leaving a comment!

WeaP said...

http://support.microsoft.com/kb/942763

will tell you that it replaces and supersedes a previous update: 933360.

Manually deleting that previous update has allowed the new update 942763 to install finally!!

Anonymous said...

Thank You for this blog it was very helpfull to me.

I searched since month for this.