Background reading material:
How to analyze the log file entries that the Microsoft Windows Resource Checker (SFC.exe) program generates in Windows Vista:
Aaron Stebner’s WebLog : Steps I use to narrow down an OS update installation failure on Windows Vista and higher:
One of the big changes between XP and Vista/Win7 is the patching stuff one looks at. In XP/2k3 you’ll be asked to look at the windowsupdate.log file and the KB######.log file (that’s typically the Knowledge base article number). In Vista and Win7 (and 2k8) Windowsupdate.log is still there, but the patching stuff is in the Component Based Servicing logs or CBS.log for short. Me being a member of the TV generation sees “CBS” and thinks the television network.
It’s not that. But everytime someone says “look in your CBS log file” that the very first thing I think of.
You’ll find two logs in the C:\Windows\Logs\CBS folder
One called CBS.log, the other CBS.persist.log. CBS.persist.log is the older of the two and is generated when the cbs.log is around 35-40 megs. It’s normally a few weeks older.
You can safely dump the persist log folder if you want to.
One thing you will notice when you try to open these files is that they freak out and ask you to provide proper rights. Right mouse click on the files, and click on the properties. Go to the security tab and you’ll see that even if you are “the administrator” in Vista because you aren’t really and truly THE “500″ mega mondo I OWN everything Administrator, it will keep this protected.
To open it up I normally just make a copy and dump it into the documents folder.
You’ll still need to give permission to do it.
Now that you have it, click on it to open in Notepad.
Okay, that’s nice but now what? Use the find in notepad to find words like error or failure if you’ve had an issue. Search on the KB article number in there (I still don’t get why some KB numbers end up in there adn why some don’t and why it keeps detecting a certain bundle of patches.
If you do find a section where there are errors, next we steal from Aaron’s post about what to do next….from Aaron’s FABULOUS blog post:
Determine the meaning of the error and possible workarounds
From here, the next step I take depends on what data appears in cbs.log. Some of the information I look for is the following:
- Does the same error code occur for multiple different OS update packages? If so, that typically means that there is a problem with the OS update engine itself as opposed to with the update that is failing.
- Does the error code appear in the System Update Readiness Tool knowledge base article? If so, I typically try to use the tool available in that knowledge base article and/or the steps in this blog post.
- Does the error code appear in the table of common CBS error codes? If so, I try the workaround suggested there for the error code that I found in cbs.log.
- If the error code does not appear in either of the above articles, then I try to use the err.exe tool to determine more detailed information about the cause of the error.
For additional information
While researching this blog post, I found a useful link on TechNet – http://technet.microsoft.com/library/cc732334.aspx. This link contains more details about how to read and interpret the following log files:
It includes a table of common errors that can appear in a cbs.log along with possible resolutions or workarounds.