The Windows Servicing Guy

Tips and tricks from a Windows support engineer on issues related to servicing

Help me, help you

Help me, help you

  • Comments 3
  • Likes

We frequently get cases where customers have issues with installing updates or service packs.  With the release of Service Pack 2 recently for Windows Vista and Windows 2008, I thought it might be a good idea with what would be good to collect before you call us for support.  Some of these steps just might resolve your issue and save you some money (or an incident).

Keep in mind that this information pertains only to Windows Vista and Windows 2008 (it will also apply to Win7). Troubleshooting issues with 2003 and lower use a different engine (update.exe) and the logging mechanisms are different.

Before you call into Microsoft with one of these issues, please attempt to do the following:

  1. Have the exact error code you're getting when it fails.  When I say exact, I mean the entire hex code that the error has as well as word for word verbiage.  A lot of people like to make the error more friendly (we're guilty internally of this too) and that makes it almost impossible to find at times.  So please, be specific.
  2. Run CheckSUR against a machine.  CheckSUR is a tool we developed that can fix certain types of corruption in the servicing stack.  It does this automatically without any input from you.  It can be found here: http://support.microsoft.com/kb/947821
  3. From an elevated command prompt, run SFC /SCANNOW.  This command will project files from the component store (\Windows\winsxs) to the proper location in the file system.  Sometimes its as easy as just making sure that the right file is there for a fix to install properly.
  4. If all else fails, go ahead and get your logs together.  The logs we typically need for troubleshooting these issues are the following:
    • \Windows\logs\CBS\CBS.log
    • \Windows\logs\CBS\CBS.persist.log
    • \Windows\logs\CBS\CheckSUR.log
    • \Windows\WindowsUpdate.log
    • System Event log
  5. That's it.  If everything above fails, we'll need to look through those logs and see if we can determine why you're having the particular issue you are seeing.

Hopefully, this alleviates some of the issues you might experience or at least eliminates some downtime if you do have to call into us because you already have your logs available.  I'll cover a little more about what's in these logs and how you can troubleshoot issues in a later post.

Comments
  • Hi joscon.

    For a while I've wondered about the order that SURT and SFC should run in. Now I know, but I'm not sure what the reason is. Could you briefly explain why running SURT is step 2, and running SFC is step 3, and not the other way around?

  • Sure, the reason you want to run CheckSUR first is that it is checking for corrupted binaries and manifests that it knows how to fix.  SFC on the other hand is checking to see if the version that you have in the component store matches that of the one on the file system.  

    If you were having a problem with a corrupted manifest that was causing some sort of servicing issue, it most likely wouldnt be able to be reprojected with SFC, however CheckSUR could fix the manifest and then any further reprojection could take place as it should.

    --Joseph

  • I see. So CheckSUR is like chkdsk for the component store, whereas SFC is more of a version fixing tool. So if anything, CheckSUR is the more 'fundamental', low-level tool of the two. Given that there must be some case for building CheckSUR into the OS, or at least making it available as a recommended Windows Update.

    Thanks Joseph.

    Andrew