Welcome to the Sysnative Windows Update Academy!
This tutorial is the first in a long series of many guides and resources that we host here at Sysnative. Specifically, it is the first tutorial in our Windows Update Academy where we teach you how to fix many different Windows Update problems on your own - some simple, some very complex.
Warning: This article is extremely technical. It is only intended to be accessible to those with plenty of prior computing experience.
Welcome to the first tutorial of this school, which aims to teach the basics of analysing and fixing errors reported by the System Update Readiness Tool. You need have no former knowledge of the subject, only a desire to learn.
The single most important piece of advice I can ever give you in this school is not to disregard an unfamiliar logfile. Just because you do not recognise it/have not been taught how to read it does not mean that it cannot be deciphered with some concerted effort and potentially web searching. Always take the time to look at an unfamiliar logfile, and you will almost always be rewarded with at least some useful information. However, it is not my intention to leave you completely unprepared, and consequently I do intend to outline here some basic techniques used in the analysis of System Update Readiness Tool logfiles, to get your foot in the door. Further understanding should be gained through the other tutorials available here, but primarily through practice.
N.B. This tutorial was originally written for Windows 7 / Windows Vista, but everything still holds for Windows 10 / Windows 8 with just one small change. We shall discuss this difference at the very end.
CheckSUR.log and CheckSUR.persist.log
If the System Update Readiness Tool (SURT) is run multiple times, multiple log files will have been created. The CheckSUR.log file stores only the logfile from the latest run of the SURT. The CheckSUR.persist.log file contains the logfiles from every execution of the SURT, in forwards chronological order.
Both logfiles can be found in the %SystemRoot%\Logs\CBS (C:\Windows\Logs\CBS) directory.
The System Update Readiness Tool
This tool itself can be found at KB947821. The general process of dealing with a thread is given below.
First, you should instruct the Original Poster (OP), also known as the thread starter, to download and then 'install' the SURT. This will generate the logfiles discussed above, which you instruct the OP to upload. Next, you analyse these logfiles, create a fix from them, and instruct the OP in this fix. The tool should then be re-run at the end of the fix and the logfiles re-uploaded so that you confirm that all corruptions have been successfully repaired, and finally check with the OP that their problem is now resolved.
A couple of points of note about this process:
The installation process of the SURT will look like that of any other Windows Update, however, be aware that it does not actually 'install' itself in the most technical meaning of the word, but simply runs itself whilst claiming to be "installing". This has multiple consequences: firstly, since it has not properly installed itself, it cannot be, and does not need to be, manually run after installation; secondly, it can be "installed" (run) multiple times without first needing an "uninstallation", which indeed does not exist.
The second point of note is about whether to choose CheckSUR.log or CheckSUR.persist.log (remind yourself if you cannot fully remember the difference). When making assessment of a computer you have never dealt with before, or not for a long time, you should choose CheckSUR.persist.log to look for evidence of cause of corruption in previous runs of the SURT (you are looking for entries present in older logfiles but not the most recently logfile). If, however, you know that there has only been one run of the SURT between the last logfile that you have seen and the current date, you may request the smaller and more wieldy CheckSUR.log.
Moving onwards to the actual contents of the logfiles:
The Header
A CheckSUR.log always contains a header, for example:
First notice the binary version. 6.0.x.x indicates either Windows Vista or Windows Server 2008. 6.1.x.x indicates either Windows 7 or Windows Server 2008 R2. 6.2.x.x indicates Windows 8 or Windows Server "8".
Next notice the package version number, which indicates the version of the SURT. Always check this, and know the package version of the most recent revision of the tool (which are made approximately once every two months), to ensure that the OP is not using an old version of the tool. However, be extremely cautious, as this number is not updated in every revision of the tool, so just because the OP's logfile has the latest package version does not absolutely guarantee that they are using the latest version of the tool. The reasons for this are outside of the realm of this first tutorial.
Finally note that there is no way from this header to identify the architecture of the platform under which the tool was run.
The Structure of a Line
All CheckSUR.log lines take the same general form. Look over the following example line:
The first part of this line is (f). This denotes a fatal error. The two others available are (w) for warning, and (fix), which denotes an error which has already been fixed. Fix lines are not a replacement for a (f) line. They come as a separate entry immediately below the (f) line. Always check for a (fix) immediately below a (f). For example:
The second part of the line is the type of corruption, in this case CBS MUM Corrupt. This tells you exactly what sort of issue you are dealing with, and as each has its own method of repair, you will use this part of the line to plan your fix. You will be gradually introduced to several of the most common corruption types and how to repair them over this and the following tutorials, and you should find that you learn them very quickly by immersion and without having to rote learn them, very quickly. For the rarer corruption types (of which there are a lot), you will not be expected to memorise them, and instead a reference library will be provided so that you can look them up.
The third part of the line is the error code particular for the corruption type, in this case 0x800F0900. Not all corruption types specify this (instead giving 0x00000000), however, a number of corruption types will have multiple different fixes depending entirely upon this error code. You must consult with the reference library to confirm whether the error code has any bearing on the fix for each corruption type you come across. Be assured that the error code does not affect any of the corruption types in this tutorial unless otherwise specified. In general, whilst error codes are to be discussed fully only later in this course, the most common difference is between error code 0x00000002 (ERROR_FILE_NOT_FOUND) and 0x00000005 (ERROR_ACCESS_DENIED). The former means that the file/folder/registry key/whatever is completely missing and needs recreating, whereas the latter means that the file/folder/registry key/whatever has incorrect permissions set which need correcting. However, as ever, consult with the reference library for confirmation.
The fourth part of the line is the item the error applies to. This may be a file, a folder, a registry key, or a registry value. In this case, it is servicing\Packages\Package_2_for_KB2079403~31bf3856ad364e35~amd64~~6.1.1.0.mum.
Finally, the fifth part of the line is optional, and is not included in all error codes. Its value is entirely dependent on the corruption type, and sometimes even the error code, and there is absolutely no general case as to what information is supplied here. Consequently, you can only proceed by contacting the reference library. In this particular example, "Line 1:" gives us the first line of the corrupt manifest. This particular manifest has nothing in its first line, but sometimes a large amount of junk data could be returned here, which you would need to be careful of.
The remainder of this tutorial is given to some general methods of fixing corruptions which can be applied to more than one specific corruption type.
Fixing common CheckSUR.log errors, including Windows Update error code 0x800B0100
Anyone who works with the SURT and Windows Update for any length of time will soon come to learn that the 0x800B0100 error code is the most common error code which results in a situation where this sort of fix is required, so you will likely find that you deal with many cases of this error code over your time here and elsewhere. However, know that the techniques outlined below can be applied to many different error codes, and not just the 0x800B0100 error.
First, some background. The group of errors which can be fixed using this method occur when some files Windows Update uses to maintain state have become corrupt, whatever the reason. Replacing these files fixes the error. That is the theory here, and indeed this is the theory surrounding most of the SURT. The tool reports corruptions in a variety of locations, and you either replace the file or reconstruct the registry key. The actual location (show as different corruption types) remains largely irrelevant: you simply replace a file from a different folder, or reconstruct a slightly different registry key. The theory is the same regardless.
The remainder of this tutorial specifically will show you how to source and replace a file in general, which will allow you to fix most file system based CheckSUR.log corruptions. Some of the other classes of corruptions reported by this tool include registry corruptions and files which cannot be replaced in this way (do not be concerned by these, they will be discussed fully later). You will soon find that many of the former, as they require complete reconstruction from nothing of a certain registry key or value, are considerably harder to fix than their file system counterparts. These are far beyond the scope of this tutorial, but we will cover them all in good time. Indeed, you will probably later come across more than you could wish in a lifetime, as we have become somewhat of a magnet for these extremely rare and difficult to fix corruptions, being approximately the only forum currently on the internet able to regularly fix them.
Moving onwards to a complete example, take a look at this full logfile. You have by now studied in moderate depth individual parts of the logfile, but you may not have yet seen a complete logfile, and you are unlikely to yet know anything about the actual corruptions reported here. However, that does not mean that you cannot gain a very deep insight into this logfile even without that additional understanding.
Consider for a moment every file and every registry key which resides on your computer. Now consider all of the ways in which they can become corrupt. Consider how many variations there are. Now understand that no matter how hard I try, I cannot write out exact steps for fixing every variation of every corruption for every file, registry key, and value on every computer. It simply isn't possible. All I can do is give you examples, general cases, and building blocks so that you can draw together links from past experiences to put together a fix for the exact variation in front of you. Although you are a long way off from that yet, it is what we are eventually building up to: it's tricky, I won't deny it, but it's also extremely challenging and what makes this (to my biased mind) one of the most interesting disciplines you could have chosen to specialise in. But we have to start somewhere, and immediately is the best time.
Back to the logfile at hand: read through this logfile completely, and attempt to understand what each part of it. You are not expected to work out how to fix any of these corruptions, I merely want you to read each line very carefully and see how they all tie together into a complete logfile. Work out what each line means, work out which files are corrupt, how SURT refers to each type of file (hint: get the name for each group from corruption type), any relevant error codes, line severity, etc. etc. Finally, and if you have not already, devise the purpose of the "Unavailable repair files:" section of the logfile.
You should by now have worked out the purpose of the "Unavailable repair files:" section of the logfile - to conveniently group together all of the files you will need to source and replace. This is extremely useful for more than just the most obvious reason: multiple different corruption types will write to this section of the logfile, and as long as you know the general techniques (which we shall look at after first examining the remainder of this logfile) for fixing the corruptions reported in this section, it does not matter what corruption type they originated from, the fix is always exactly the same. Consequently, despite there being about 20 corruption types which write to this section of the logfile, you do not need to memorise anything about each of them: you simply use the same technique on all of them.
However, this does not mean that you can get away with analysing only this final section of the logfile - you should always look at all parts of the logfile. Firstly, there are many corruption types which do not write to this section of the logfile, and you would not want to miss seeing those errors in the logfile, and secondly, there are an extremely small number of specific corruptions which require a different fix - exceptions to the general rule. We will cover these later, but do not be concerned with them now. They are both small in number and easy to spot. Finally, the very keen of memory will remember that I mentioned earlier that there are some file system corruptions which cannot be repaired in the same way as the others. These corruption types do not write to this section of the logfile, therefore, any corruptions under the "Unavailable repair files:" section repair in this way, and any file system corruptions which do not write to this section of the logfile do not repair in this way.
However, care is needed. In an older version of the SURT there was a bug (now fixed) which omits the .mum entries and duplicates the .cat entries in the "Unavailable repair files:" section of the logfile, like so:
Note that despite how it may at first appear, you must still source the .mum files, even though they are not explicitly listed. This is because, without exception, .cat and .mum files must always be replaced as a pair of files (by pair I mean those two file which have the same name and differ by file extension only), even if only one of the pair is corrupt. Look back at the "Unavailable repair files:" section of the complete logfile and ascertain that you fully understand that there are two pairs of .mum/.cat files there, not four individual files.
However, whilst this may seem like an innocuous bug, a small error in the code, I personally believe that it resulted because of the situation briefly described above. Whilst .cat/.mum pairs of files must always be replaced as a pair, it is possible for only one file of the pair to become corrupt (although you will soon find out that this is a rare occurrence). Consequently, whilst these files always appear as a pair in the "Unavailable repair files:" section of the log, to remind you to source both, it may be that only one of the .cat/.mum file appears in the main section of the logfile. It is therefore of my opinion that the first entry of the pair in the main bulk of the logfile adds both the .cat and the .mum entries to the footer. This ensures that even if the other member of the pair is not corrupt and so never gets added to the logfile, both files still get added to the footer.
First, the file extension needed to be standardised so that it didn't matter whether CBS MUM corrupt or CBS Catalog corrupt showed up first, and .cat was as good a choice as either. Secondly, the file extension for the second entry needed to be converted to .mum. However, this conversion was seemingly accidentally omitted, resulting in this duplication of .cat files as noted. Whilst this is only a theory, and I cannot guarantee its accuracy, it is the best explanation I have yet come up with for this phenomenon.
You may now be wondering why I chose to dedicate myself to explaining something so...trivially unimportant. To me, this particular bug is of very little importance. However, it demonstrates another example of something I have already alluded to in this tutorial: the ability to draw together other knowledge to create theories for unfamiliar scenarios. Although I will not attempt to teach those methods until much later in the course, I feel that it is important for you to be exposed to such theories right from the beginning of your time here.
Whilst we will look into the exact purpose of .cat/.mum/.manifest files only later in the course, for now know that .manifest and .mum files are both internally plain-text XML files and can therefore be opened using Notepad or a similar text editor. .cat files on the other hand are security catalogs, and so store digital signature information for other files (digital signatures are one part of a complete solution designed to prevent Windows files from being tampered with or infected - the file's digital signature will become invalid if its contents change, be that due to infection or corruption).
As you have already covered, .cat and .mum files always come in pairs, however, there is an exceptional scenario when a .cat/.mum pair becomes a .cat/.mum/.ses trio. Only a very few updates, primarily service packs, contain this extra XML based .ses file, and it attaches only to one specific pair .cat/.mum pair - the primary package pair, which you will meet later in this tutorial). By contrast, .manifest files are completely separate and individual entities.
Manifest files reside in %SystemRoot%\winsxs\Manifests, and catalog and mum files reside in their pairs in %SystemRoot%\servicing\Packages.
Now that we have covered some additional theory, think back to the complete logfile we were trying to create a fix for. We have identified two pairs of .cat/.mum files, and two .manifest files as corrupt from the "Unavailable repair files:" section, and I can confirm that there are no complexities or exceptions to the rule here that you have not yet covered. We now need to repair these corruptions. To this, there are two steps: first, you must source a good replacement for the file (a non-corrupt or "clean" copy of exactly the same file), and second you must make the replacement (replace the corrupt copy of the file on the problem computer with your non-corrupt copy). In theory, this sounds quite easy. Let's see how it plays out in practice.
Step 1: Sourcing a Clean Copy of the File
The most important fact to keep in mind at all times when sourcing a file is that very similar is not good enough. Even if you can't quite find the right file, you must never substitute a similar file. You must always find the exact file you are looking for, or ask for help.
Whilst some people will, or sometimes even recommend that you, source the replacement file from a different computer with a similar configuration, I would advise against this technique. The copy of a file from a computer which has been in operation for two years is more likely to be corrupt than the copy from a good download from Microsoft's webservers, which is the method that I shall be teaching. Additionally, it generally takes longer to use other computers to source files from, not least because most files only appear on certain computer configurations, you will need to maintain very many different computers or virtual PCs to source files even the majority of files. Additionally, there will still be times when you won't have the exact file you need on any of your configurations, and you will have to resort to downloading the file from Microsoft's webservers anyway. It would then have been better to learn and use this way initially.
The first step to take is to identify the Microsoft Knowledge Base article number (KB number) from which the update the corrupt file originates from came from. This is usually very easy for .cat and .mum files, but can be significantly more difficult for .manifest files.
Most .cat or .mum files have a file name that takes the following form:
For example:
Public key tokens and what they are used, are outside of the scope of this tutorial, and there is no need for you to know anything about them in order to fix corruptions, however, if you are particularly interested, there is a good explanation here: Dot net blog: Public keys and public key tokens.
There are additionally a few other file name formats of .cat and .mum files, which are used more rarely:
1: Primary Package
The primary package, also known as the default package or base package, does not have a package number, for example:
2: Localised Packages
Localised packages have localisation strings inserted between the double tilde symbol in the name, just before the version number, for example:
It is perfectly possible and indeed normal for localised packages to appear on computers with only a single installed language. They are just as required as any other file, and should be repaired in exactly the same way as any other.
3: Additional Versioning
An additional string is appended after the KB number and an underscore to indicate further versioning. The most common values will be RTM and SP1, although other values are possible, particularly on non-native components, for example vpc.
4: Fully Named Packages
Some packages use a name instead of a KB number and package number. They usually belong to either non-Windows Microsoft products or to core Windows components (also know as native packages), which are those components which existed in the base RTM, and were not added in any Windows Update. These can create additional hurdles to overcome, and will be discussed later, but for the record, some examples:
Short Practice Exercise
Have a little fiddle in the %SystemRoot%\servicing\Packages folder, and look at the naming conventions used for each of the different pairs of .mum and .cat files. See if your computer features any .ses files. Explore the .mum and .ses files in Notepad, and simply double click on .cat files to explore them.
Once you have had a good look, come back for the remainder of this tutorial.
Step 1: Sourcing a Clean Copy of the File (cont.)
I am sure by now that it doesn't need stating, but to identify which KB article (Windows Update) a .cat or a .mum file originates from, you simply read it from the file name. We will cover later how to deal with the few rare instances of .cat and .mum files which do not have this information in their names. The reason you want to find the KB number is so that you can find and download the Windows Update package the corrupt files come from. Then you can extract the Windows Update package and source replacements for the corrupt files.
However, for manifest files, the situation is not quite as simple. Once again, there are a variety of naming conventions, however, none contain the KB number in the name. To provide some examples:
Fortunately, it will usually not matter that the name does not contain the KB number, as any corrupt update is missing both .cat or .mum files, and .manifest files. Although we may not be able to trace the .manifest files, by sourcing and extracting the Windows Update files for the missing .cat and .mum files, and by looking in the same update for replacement .manifests, the vast majority of files can be sourced. In the extremely rare cases where a .manifest file cannot be sourced in this way, more complicated approaches, outlined later in the course, can be utilised.
Now that you know the KB numbers for the corrupt Windows Updates, you can use this knowledge to download each Windows Update package in turn, extract it, and finally source the relevant .cat/.mum files then check to see if it contains any of the missing .manifest files. To actually download the update, either web search for the KB number proceeded by "KB" (e.g. "KB936332"), or enter it in the URL [NO-PARSE]http://support.microsoft.com/kb/{number}[/NO-PARSE] (e.g. [NO-PARSE]http://support.microsoft.com/kb/936332[/NO-PARSE]). Once you have reached that page, use the download link for IT Professionals, to reach the actual download page (this is the general case - some KB articles use slightly different wording, and I aim to show you these in a practice exercise very soon).
Short Practice Exercise
Have a little fiddle in the %SystemRoot%\winsxs\Manifests folder, and look at the naming conventions used for each of the different .manifest files. See if your computer has any .cat or .mum files there (most computers will have a very few .cat or .mum files here, with the vast majority in the normal location of %SystemRoot%\servicing\Packages, but you may still have a few. Explore a couple of the .manifest files in Notepad.
Once you have had a good look, come back for the rest of this tutorial.
Short Practice Exercise
Find the download links for the following Windows Updates (I strongly advise you to attempt all of these, as they each attempt to teach a subtly different point):
Extracting an Update
Once you have downloaded the Windows Update file you believe to contain a clean copy of a file you are attempting to source, most usually with the file extension .msu, it must be extracted so that you can get access to the contained files. It is imperative they you do not use 3rd party extraction programs (for example 7-Zip or WinRAR) to extract either this .msu file, or any internal .cab files, as these programs incompletely extract such archives (in reality, some of these tools may work on service packs, but they certainly won't work on normal updates, so I recommend always using the one completely safe method outlined below).
First create a small directory structure in a convenient location, with a new folder inside another new folder. I shall use C:\Update\Extracted (both new, empty, folders) as an example. Place the downloaded .msu file into the outer of the two folders (C:\Update\Windows6.1-KB2345886-x64.msu in this example).
Open up an instance of the Command Prompt, and type:
expand -f:* {update location and name}.msu {destination folder}
(for example, expand -f:* C:\Update\Windows6.1-KB2345886-x64.msu C:\Update)
Then type:
expand -f:* {update location and name}.cab {destination folder}
(for example, expand -f:* C:\Update\Windows6.1-KB2345886-x64.cab C:\Update\Extracted)
Clean replacements of files can then be sourced from the C:\Update\Extracted folder.
Short Practice Exercise
Download and extract, using the methods given above, a clean copy of:
for a Windows 7 SP1 x64 computer. Please keep all extracted files handy, as you will be using them again very soon.
The Default Package
I briefly mentioned the default or primary package earlier in this tutorial, where I said that they take a general form without a package number, for example:
That was all that you needed to know back then, but there is a little bit more to the story. If you were to extract KB2345886 (the same KB which you just extracted into C:\Update\Extracted as a practice exercise), you will notice that it does not seem to contain the default package file (Package_for_KB2345886~31bf3856ad364e35~amd64~~6.1.1.2.cat). This is actually not quite true - it does contain it, but under a different name - update.cat.
If you ever need to extract a replacement for the default package, you must take either update.cat or update.mum, and then rename it back immediately.
For example,
You absolutely must not forget this. It is extremely important, comes up time and time again, and has confused many a good analyst. Do not forget this!
Finally, the default package can also have versioned versions of it (remember from earlier in this tutorial: SP1, RTM, and occasionally others, such as VPC). These require no renaming, and should be treated just like any other .cat or .mum file. For example,
The bf Files:
Look back once again at your extracted KB2345886. You will notice that every pair of .cat and .mum files has a linked pair of bf files, where _bf is inserted into the name directly after the kb number. Some examples:
You need learn very little about bf files, except for the fact that they are different to their non-bf companions and can therefore not be used interchangeable. However, in all other respects they behave identically, and so are extracted and repaired (and renamed, in the case of update-bf.cat and update-bf.mum) in exactly the same way as their non-bf counterparts.
Using Clean Copies of Files to Repair a Computer
Now that you have sourced all the required files (extracting multiple Windows Updates if required), it is time to replace the corrupt files on the affected computer. There are a couple of ways of doing this. First, I do not ever recommend altering permissions or ownership on system files. This is actually far more dangerous that it first appears, because permissions and ownership are a primary line of defence against malware. Consequently, if permissions and ownership are not reset to exactly how they were, you can open a computer up to infection. Fortunately, there are easy alternatives which avoid the need for this, which is why I expect to see none of you attempting to alter permissions or ownership on system files whilst you are under my supervision or at this forum. In addition, there is the other practical issue that files are often in-use and need to be replaced over a reboot or with special tools, and so manually altering permissions and ownership so that a standard copy & paste operation can be made to work is both dangerous and often ineffective. Provided below are the safer alternatives.
Fortunately, there is a very neat solution provided for us by Microsoft through the SURT for .cat, .mum, and .manifest files (only these file extensions, unfortunately, due to security reasons, I think).
.cat and .mum files, in pairs (remember that they must always be paired up, even if only one is corrupt), can be placed in the %SystemRoot%\Temp\CheckSur\servicing\Packages directory, and .manifest files can be placed in the %SystemRoot%\Temp\CheckSur\winsxs\Manifests directory, and the System Update Readiness Tool re-run. The SURT will then perform the replacement of corrupt files, sourcing good files from the directories given above, and dealing with all permission issues safely and securely.
This is the best way of replacing corrupt files of these extensions. However, when the corruptions lie in other locations (primarily %SystemRoot%\winsxs), or affect other file extensions, and consequently this method cannot be used, other solutions must be employed. These topics are outside of the scope of this tutorial, and will be covered in full later in the course.
Remember to rename all update.cat and update.mum files (and bf equivalents) before placing them in this directory, otherwise the SURT won't know which update those files came from.
The CheckSUR.log can then be re-analysed to confirm that all detected errors have been fixed. For example,
Changes in Windows 8 and Windows 10
Windows Update has a very capable auto-fix function built into it. In many cases it is able to detect and repair problems without the user ever noticing. Of course this process isn't always successful, but it does exist and it does work much of the time.
In Windows Vista and Windows 7, one of these capabilities was the System Update Readiness Tool (SURT) which was designed to repair complex servicing corruptions. It could be automatically downloaded and run by Windows Update (hence the .msu file format) whenever needed, or manually downloaded by a user from the Microsoft website.
As of Windows 8 and Windows 10, SURT is now built into the core operating system as a part of DISM (Deployment Image Servicing and Management).
To run it, you simply execute the command DISM /Online /Cleanup-Image /RestoreHealth from the Command Prompt, being mindful to get all the capital letters just right as DISM is very picky on that front.
The logfile is then output to C:\Windows\Logs\DISM.log rather than C:\Windows\Logs\CBS\CheckSUR.log, but otherwise looks very similar:
Other differences between Windows 7 and later versions of Windows are mostly minor and not important right now, and will be covered in more detail later in the academy.
Conclusion
Finally, the end of the first tutorial! I hope you learned something, maybe even enjoyed it. There is plenty more to cover though: this is only the beginning.
Now would be a very good time to put your skills to the test in Practice Log 1. I would strongly advise you to do so in order to solidify your understanding, and it will hopefully also draw out any slight misunderstandings or points of confusion. Remember that you do not need to form your reply into a mock reply to the user at this time: simply provide us with the fix that you have created.
Please remember to ask us any questions that you may have, and indeed provide us with any feedback about this tutorial - weak or poorly explained areas in particular. We are all very friendly and open to questions, and it is absolutely imperative that you get a rock solid foundation in the basics before even considering moving on. So don't be shy and ask us anything and everything which is troubling you :)
Finally, now that you have had a taste as to what we do here, and what it is like to specialise in Windows Update diagnosis, I hope that you like what you have experienced. However, if you have any anxieties, or feel that this isn't for you, please talk to me about it. It may well be that there are ways we can improve your experience, or it could just be that this isn't for you. Whatever your concerns, please let me know so that we can discuss them.
This tutorial is the first in a long series of many guides and resources that we host here at Sysnative. Specifically, it is the first tutorial in our Windows Update Academy where we teach you how to fix many different Windows Update problems on your own - some simple, some very complex.
Warning: This article is extremely technical. It is only intended to be accessible to those with plenty of prior computing experience.
- If you have a Windows Update problem you want to get help with without needing lots of computer experience, stop reading this and instead return to the Window Update Posting Instructions.
- If you want to learn more about what the Sysnative Windows Update Academy is, read this post: Learn How to Fix Windows Update: The Sysnative Windows Update Academy
- If you want to learn the basics of fixing Windows Update yourself, continue reading this post.
Welcome to the first tutorial of this school, which aims to teach the basics of analysing and fixing errors reported by the System Update Readiness Tool. You need have no former knowledge of the subject, only a desire to learn.
The single most important piece of advice I can ever give you in this school is not to disregard an unfamiliar logfile. Just because you do not recognise it/have not been taught how to read it does not mean that it cannot be deciphered with some concerted effort and potentially web searching. Always take the time to look at an unfamiliar logfile, and you will almost always be rewarded with at least some useful information. However, it is not my intention to leave you completely unprepared, and consequently I do intend to outline here some basic techniques used in the analysis of System Update Readiness Tool logfiles, to get your foot in the door. Further understanding should be gained through the other tutorials available here, but primarily through practice.
N.B. This tutorial was originally written for Windows 7 / Windows Vista, but everything still holds for Windows 10 / Windows 8 with just one small change. We shall discuss this difference at the very end.
CheckSUR.log and CheckSUR.persist.log
If the System Update Readiness Tool (SURT) is run multiple times, multiple log files will have been created. The CheckSUR.log file stores only the logfile from the latest run of the SURT. The CheckSUR.persist.log file contains the logfiles from every execution of the SURT, in forwards chronological order.
Both logfiles can be found in the %SystemRoot%\Logs\CBS (C:\Windows\Logs\CBS) directory.
The System Update Readiness Tool
This tool itself can be found at KB947821. The general process of dealing with a thread is given below.
First, you should instruct the Original Poster (OP), also known as the thread starter, to download and then 'install' the SURT. This will generate the logfiles discussed above, which you instruct the OP to upload. Next, you analyse these logfiles, create a fix from them, and instruct the OP in this fix. The tool should then be re-run at the end of the fix and the logfiles re-uploaded so that you confirm that all corruptions have been successfully repaired, and finally check with the OP that their problem is now resolved.
A couple of points of note about this process:
The installation process of the SURT will look like that of any other Windows Update, however, be aware that it does not actually 'install' itself in the most technical meaning of the word, but simply runs itself whilst claiming to be "installing". This has multiple consequences: firstly, since it has not properly installed itself, it cannot be, and does not need to be, manually run after installation; secondly, it can be "installed" (run) multiple times without first needing an "uninstallation", which indeed does not exist.
The second point of note is about whether to choose CheckSUR.log or CheckSUR.persist.log (remind yourself if you cannot fully remember the difference). When making assessment of a computer you have never dealt with before, or not for a long time, you should choose CheckSUR.persist.log to look for evidence of cause of corruption in previous runs of the SURT (you are looking for entries present in older logfiles but not the most recently logfile). If, however, you know that there has only been one run of the SURT between the last logfile that you have seen and the current date, you may request the smaller and more wieldy CheckSUR.log.
Moving onwards to the actual contents of the logfiles:
The Header
A CheckSUR.log always contains a header, for example:
Code:
=================================
Checking System Update Readiness.
Binary Version 6.1.7600.20667
Package Version 8.0
2010-08-13 13:26First notice the binary version. 6.0.x.x indicates either Windows Vista or Windows Server 2008. 6.1.x.x indicates either Windows 7 or Windows Server 2008 R2. 6.2.x.x indicates Windows 8 or Windows Server "8".
Next notice the package version number, which indicates the version of the SURT. Always check this, and know the package version of the most recent revision of the tool (which are made approximately once every two months), to ensure that the OP is not using an old version of the tool. However, be extremely cautious, as this number is not updated in every revision of the tool, so just because the OP's logfile has the latest package version does not absolutely guarantee that they are using the latest version of the tool. The reasons for this are outside of the realm of this first tutorial.
Finally note that there is no way from this header to identify the architecture of the platform under which the tool was run.
The Structure of a Line
All CheckSUR.log lines take the same general form. Look over the following example line:
Code:
(f) CBS MUM Corrupt 0x800F0900 servicing\Packages\Package_2_for_KB2079403~31bf3856ad364e35~amd64~~6.1.1.0.mum Line 1:
Code:
(f) CSI Missing Identity 0x00000000 identity amd64_microsoft-windows-i..iccontent.resources_31bf3856ad364e35_6.1.7600.16385_en-us_06458c544252951f
(fix) CSI Missing Identity CSI Registry Item Repaired amd64_microsoft-windows-i..iccontent.resources_31bf3856ad364e35_6.1.7600.16385_en-us_06458c544252951fThe third part of the line is the error code particular for the corruption type, in this case 0x800F0900. Not all corruption types specify this (instead giving 0x00000000), however, a number of corruption types will have multiple different fixes depending entirely upon this error code. You must consult with the reference library to confirm whether the error code has any bearing on the fix for each corruption type you come across. Be assured that the error code does not affect any of the corruption types in this tutorial unless otherwise specified. In general, whilst error codes are to be discussed fully only later in this course, the most common difference is between error code 0x00000002 (ERROR_FILE_NOT_FOUND) and 0x00000005 (ERROR_ACCESS_DENIED). The former means that the file/folder/registry key/whatever is completely missing and needs recreating, whereas the latter means that the file/folder/registry key/whatever has incorrect permissions set which need correcting. However, as ever, consult with the reference library for confirmation.
The fourth part of the line is the item the error applies to. This may be a file, a folder, a registry key, or a registry value. In this case, it is servicing\Packages\Package_2_for_KB2079403~31bf3856ad364e35~amd64~~6.1.1.0.mum.
Finally, the fifth part of the line is optional, and is not included in all error codes. Its value is entirely dependent on the corruption type, and sometimes even the error code, and there is absolutely no general case as to what information is supplied here. Consequently, you can only proceed by contacting the reference library. In this particular example, "Line 1:" gives us the first line of the corrupt manifest. This particular manifest has nothing in its first line, but sometimes a large amount of junk data could be returned here, which you would need to be careful of.
The remainder of this tutorial is given to some general methods of fixing corruptions which can be applied to more than one specific corruption type.
Fixing common CheckSUR.log errors, including Windows Update error code 0x800B0100
Anyone who works with the SURT and Windows Update for any length of time will soon come to learn that the 0x800B0100 error code is the most common error code which results in a situation where this sort of fix is required, so you will likely find that you deal with many cases of this error code over your time here and elsewhere. However, know that the techniques outlined below can be applied to many different error codes, and not just the 0x800B0100 error.
First, some background. The group of errors which can be fixed using this method occur when some files Windows Update uses to maintain state have become corrupt, whatever the reason. Replacing these files fixes the error. That is the theory here, and indeed this is the theory surrounding most of the SURT. The tool reports corruptions in a variety of locations, and you either replace the file or reconstruct the registry key. The actual location (show as different corruption types) remains largely irrelevant: you simply replace a file from a different folder, or reconstruct a slightly different registry key. The theory is the same regardless.
The remainder of this tutorial specifically will show you how to source and replace a file in general, which will allow you to fix most file system based CheckSUR.log corruptions. Some of the other classes of corruptions reported by this tool include registry corruptions and files which cannot be replaced in this way (do not be concerned by these, they will be discussed fully later). You will soon find that many of the former, as they require complete reconstruction from nothing of a certain registry key or value, are considerably harder to fix than their file system counterparts. These are far beyond the scope of this tutorial, but we will cover them all in good time. Indeed, you will probably later come across more than you could wish in a lifetime, as we have become somewhat of a magnet for these extremely rare and difficult to fix corruptions, being approximately the only forum currently on the internet able to regularly fix them.
Moving onwards to a complete example, take a look at this full logfile. You have by now studied in moderate depth individual parts of the logfile, but you may not have yet seen a complete logfile, and you are unlikely to yet know anything about the actual corruptions reported here. However, that does not mean that you cannot gain a very deep insight into this logfile even without that additional understanding.
Consider for a moment every file and every registry key which resides on your computer. Now consider all of the ways in which they can become corrupt. Consider how many variations there are. Now understand that no matter how hard I try, I cannot write out exact steps for fixing every variation of every corruption for every file, registry key, and value on every computer. It simply isn't possible. All I can do is give you examples, general cases, and building blocks so that you can draw together links from past experiences to put together a fix for the exact variation in front of you. Although you are a long way off from that yet, it is what we are eventually building up to: it's tricky, I won't deny it, but it's also extremely challenging and what makes this (to my biased mind) one of the most interesting disciplines you could have chosen to specialise in. But we have to start somewhere, and immediately is the best time.
Back to the logfile at hand: read through this logfile completely, and attempt to understand what each part of it. You are not expected to work out how to fix any of these corruptions, I merely want you to read each line very carefully and see how they all tie together into a complete logfile. Work out what each line means, work out which files are corrupt, how SURT refers to each type of file (hint: get the name for each group from corruption type), any relevant error codes, line severity, etc. etc. Finally, and if you have not already, devise the purpose of the "Unavailable repair files:" section of the logfile.
Code:
=================================
Checking System Update Readiness.
Binary Version 6.1.7601.21645
Package Version 12.0
2011-07-24 20:02
Checking Windows Servicing Packages
Checking Package Manifests and Catalogs
(f) CBS MUM Corrupt 0x800F0900 servicing\Packages\Package_for_KB2479628_SP1~31bf3856ad364e35~amd64~~6.1.1.4.mum Line 1:
(f) CBS Catalog Corrupt 0x800B0100 servicing\Packages\Package_for_KB2479628_SP1~31bf3856ad364e35~amd64~~6.1.1.4.cat
(f) CBS MUM Corrupt 0x800F0900 servicing\Packages\Package_for_KB2479628~31bf3856ad364e35~amd64~~6.1.1.4.mum Line 1:
(f) CBS Catalog Corrupt 0x800B0100 servicing\Packages\Package_for_KB2479628~31bf3856ad364e35~amd64~~6.1.1.4.cat
Checking Package Watchlist
Checking Component Watchlist
Checking Packages
Checking Component Store
(f) CSI Manifest All Zeros 0x00000000 winsxs\Manifests\amd64_microsoft-windows-win32k_31bf3856ad364e35_6.1.7601.17535_none_1704df9bb135a53a.manifest amd64_microsoft-windows-win32k_31bf3856ad364e35_6.1.7601.17535_none_1704df9bb135a53a
(f) CSI Manifest All Zeros 0x00000000 winsxs\Manifests\wow64_microsoft-windows-win32k_31bf3856ad364e35_6.1.7600.16732_none_1f702c09e872af44.manifest wow64_microsoft-windows-win32k_31bf3856ad364e35_6.1.7600.16732_none_1f702c09e872af44
Summary:
Seconds executed: 595
Found 6 errors
CSI Manifest All Zeros Total count: 2
CBS MUM Corrupt Total count: 2
CBS Catalog Corrupt Total count: 2
Unavailable repair files:
winsxs\manifests\amd64_microsoft-windows-win32k_31bf3856ad364e35_6.1.7601.17535_none_1704df9bb135a53a.manifest
winsxs\manifests\wow64_microsoft-windows-win32k_31bf3856ad364e35_6.1.7600.16732_none_1f702c09e872af44.manifest
servicing\packages\Package_for_KB2479628_SP1~31bf3856ad364e35~amd64~~6.1.1.4.cat
servicing\packages\Package_for_KB2479628_SP1~31bf3856ad364e35~amd64~~6.1.1.4.mum
servicing\packages\Package_for_KB2479628~31bf3856ad364e35~amd64~~6.1.1.4.cat
servicing\packages\Package_for_KB2479628~31bf3856ad364e35~amd64~~6.1.1.4.mum
Customer Experience report successfully uploaded. Thank you for participating. For more information, see the Microsoft Customer Experience Improvement Program on the Microsoft web site.However, this does not mean that you can get away with analysing only this final section of the logfile - you should always look at all parts of the logfile. Firstly, there are many corruption types which do not write to this section of the logfile, and you would not want to miss seeing those errors in the logfile, and secondly, there are an extremely small number of specific corruptions which require a different fix - exceptions to the general rule. We will cover these later, but do not be concerned with them now. They are both small in number and easy to spot. Finally, the very keen of memory will remember that I mentioned earlier that there are some file system corruptions which cannot be repaired in the same way as the others. These corruption types do not write to this section of the logfile, therefore, any corruptions under the "Unavailable repair files:" section repair in this way, and any file system corruptions which do not write to this section of the logfile do not repair in this way.
However, care is needed. In an older version of the SURT there was a bug (now fixed) which omits the .mum entries and duplicates the .cat entries in the "Unavailable repair files:" section of the logfile, like so:
Code:
Unavailable repair files:
winsxs\manifests\amd64_microsoft-windows-win32k_31bf3856ad364e35_6.1.7601.17535_none_1704df9bb135a53a.manifest
winsxs\manifests\wow64_microsoft-windows-win32k_31bf3856ad364e35_6.1.7600.16732_none_1f702c09e872af44.manifest
servicing\packages\Package_for_KB2479628_SP1~31bf3856ad364e35~amd64~~6.1.1.4.cat
servicing\packages\Package_for_KB2479628_SP1~31bf3856ad364e35~amd64~~6.1.1.4.cat
servicing\packages\Package_for_KB2479628~31bf3856ad364e35~amd64~~6.1.1.4.cat
servicing\packages\Package_for_KB2479628~31bf3856ad364e35~amd64~~6.1.1.4.catNote that despite how it may at first appear, you must still source the .mum files, even though they are not explicitly listed. This is because, without exception, .cat and .mum files must always be replaced as a pair of files (by pair I mean those two file which have the same name and differ by file extension only), even if only one of the pair is corrupt. Look back at the "Unavailable repair files:" section of the complete logfile and ascertain that you fully understand that there are two pairs of .mum/.cat files there, not four individual files.
However, whilst this may seem like an innocuous bug, a small error in the code, I personally believe that it resulted because of the situation briefly described above. Whilst .cat/.mum pairs of files must always be replaced as a pair, it is possible for only one file of the pair to become corrupt (although you will soon find out that this is a rare occurrence). Consequently, whilst these files always appear as a pair in the "Unavailable repair files:" section of the log, to remind you to source both, it may be that only one of the .cat/.mum file appears in the main section of the logfile. It is therefore of my opinion that the first entry of the pair in the main bulk of the logfile adds both the .cat and the .mum entries to the footer. This ensures that even if the other member of the pair is not corrupt and so never gets added to the logfile, both files still get added to the footer.
First, the file extension needed to be standardised so that it didn't matter whether CBS MUM corrupt or CBS Catalog corrupt showed up first, and .cat was as good a choice as either. Secondly, the file extension for the second entry needed to be converted to .mum. However, this conversion was seemingly accidentally omitted, resulting in this duplication of .cat files as noted. Whilst this is only a theory, and I cannot guarantee its accuracy, it is the best explanation I have yet come up with for this phenomenon.
You may now be wondering why I chose to dedicate myself to explaining something so...trivially unimportant. To me, this particular bug is of very little importance. However, it demonstrates another example of something I have already alluded to in this tutorial: the ability to draw together other knowledge to create theories for unfamiliar scenarios. Although I will not attempt to teach those methods until much later in the course, I feel that it is important for you to be exposed to such theories right from the beginning of your time here.
Whilst we will look into the exact purpose of .cat/.mum/.manifest files only later in the course, for now know that .manifest and .mum files are both internally plain-text XML files and can therefore be opened using Notepad or a similar text editor. .cat files on the other hand are security catalogs, and so store digital signature information for other files (digital signatures are one part of a complete solution designed to prevent Windows files from being tampered with or infected - the file's digital signature will become invalid if its contents change, be that due to infection or corruption).
As you have already covered, .cat and .mum files always come in pairs, however, there is an exceptional scenario when a .cat/.mum pair becomes a .cat/.mum/.ses trio. Only a very few updates, primarily service packs, contain this extra XML based .ses file, and it attaches only to one specific pair .cat/.mum pair - the primary package pair, which you will meet later in this tutorial). By contrast, .manifest files are completely separate and individual entities.
Manifest files reside in %SystemRoot%\winsxs\Manifests, and catalog and mum files reside in their pairs in %SystemRoot%\servicing\Packages.
Now that we have covered some additional theory, think back to the complete logfile we were trying to create a fix for. We have identified two pairs of .cat/.mum files, and two .manifest files as corrupt from the "Unavailable repair files:" section, and I can confirm that there are no complexities or exceptions to the rule here that you have not yet covered. We now need to repair these corruptions. To this, there are two steps: first, you must source a good replacement for the file (a non-corrupt or "clean" copy of exactly the same file), and second you must make the replacement (replace the corrupt copy of the file on the problem computer with your non-corrupt copy). In theory, this sounds quite easy. Let's see how it plays out in practice.
Step 1: Sourcing a Clean Copy of the File
The most important fact to keep in mind at all times when sourcing a file is that very similar is not good enough. Even if you can't quite find the right file, you must never substitute a similar file. You must always find the exact file you are looking for, or ask for help.
Whilst some people will, or sometimes even recommend that you, source the replacement file from a different computer with a similar configuration, I would advise against this technique. The copy of a file from a computer which has been in operation for two years is more likely to be corrupt than the copy from a good download from Microsoft's webservers, which is the method that I shall be teaching. Additionally, it generally takes longer to use other computers to source files from, not least because most files only appear on certain computer configurations, you will need to maintain very many different computers or virtual PCs to source files even the majority of files. Additionally, there will still be times when you won't have the exact file you need on any of your configurations, and you will have to resort to downloading the file from Microsoft's webservers anyway. It would then have been better to learn and use this way initially.
The first step to take is to identify the Microsoft Knowledge Base article number (KB number) from which the update the corrupt file originates from came from. This is usually very easy for .cat and .mum files, but can be significantly more difficult for .manifest files.
Most .cat or .mum files have a file name that takes the following form:
Code:
Package_{Package number}_for_{KB number}~{Public Key Token}~{Architecture}~~{Version}.{cat/mum}
Code:
Package_4_for_KB2560656~31bf3856ad364e35~amd64~~6.1.1.2.{cat/mum}There are additionally a few other file name formats of .cat and .mum files, which are used more rarely:
1: Primary Package
The primary package, also known as the default package or base package, does not have a package number, for example:
Code:
Package_for_KB2079403~31bf3856ad364e35~amd64~~6.1.1.0.catLocalised packages have localisation strings inserted between the double tilde symbol in the name, just before the version number, for example:
Code:
Package_4_for_KB2560656~31bf3856ad364e35~amd64~ru-RU~6.1.1.2.cat3: Additional Versioning
An additional string is appended after the KB number and an underscore to indicate further versioning. The most common values will be RTM and SP1, although other values are possible, particularly on non-native components, for example vpc.
Code:
Package_for_KB982018_RTM~31bf3856ad364e35~amd64~~6.1.3.2.cat
Package_for_KB2425227_SP1~31bf3856ad364e35~amd64~~6.1.1.1.cat
Package_for_KB976933_vpc~31bf3856ad364e35~amd64~~7.1.7601.17514.catSome packages use a name instead of a KB number and package number. They usually belong to either non-Windows Microsoft products or to core Windows components (also know as native packages), which are those components which existed in the base RTM, and were not added in any Windows Update. These can create additional hurdles to overcome, and will be discussed later, but for the record, some examples:
Code:
Microsoft-Windows-TerminalServices-MiscRedirection-Package~31bf3856ad364e35~amd64~~6.1.7601.17514.cat
Microsoft-Windows-VirtualPC-Package~31bf3856ad364e35~amd64~~7.1.7600.16393.cat
Server-Help-Package.ClientHomePremium~31bf3856ad364e35~amd64~~6.1.7601.17514.catHave a little fiddle in the %SystemRoot%\servicing\Packages folder, and look at the naming conventions used for each of the different pairs of .mum and .cat files. See if your computer features any .ses files. Explore the .mum and .ses files in Notepad, and simply double click on .cat files to explore them.
Once you have had a good look, come back for the remainder of this tutorial.
Step 1: Sourcing a Clean Copy of the File (cont.)
I am sure by now that it doesn't need stating, but to identify which KB article (Windows Update) a .cat or a .mum file originates from, you simply read it from the file name. We will cover later how to deal with the few rare instances of .cat and .mum files which do not have this information in their names. The reason you want to find the KB number is so that you can find and download the Windows Update package the corrupt files come from. Then you can extract the Windows Update package and source replacements for the corrupt files.
However, for manifest files, the situation is not quite as simple. Once again, there are a variety of naming conventions, however, none contain the KB number in the name. To provide some examples:
Code:
wow64_microsoft-windows-kernel32_31bf3856ad364e35_6.1.7601.17514_none_fc389502a14bd4ea.manifest
msil_system.drawing.resources_b03f5f7f11d50a3a_6.1.7600.16385_en-us_bda8c488f3777036.manifest
x86_policy.1.0.microsof..op.security.azroles_31bf3856ad364e35_6.1.7600.16385_none_9d5b0583c8186aea.manifest
x86_microsoft-windows-l..homebasic.resources_31bf3856ad364e35_6.1.7600.16385_en-us_5aff93fe857d5dec.manifest
amd64_.netframework_31bf3856ad364e35_6.1.7600.16385_none_34b78d5c105d8b49.manifest
amd64_0a5042d96597c7c42dd6e6f522bc4902_b03f5f7f11d50a3a_6.1.7601.21884_none_4d1d149f7c725758.manifestNow that you know the KB numbers for the corrupt Windows Updates, you can use this knowledge to download each Windows Update package in turn, extract it, and finally source the relevant .cat/.mum files then check to see if it contains any of the missing .manifest files. To actually download the update, either web search for the KB number proceeded by "KB" (e.g. "KB936332"), or enter it in the URL [NO-PARSE]http://support.microsoft.com/kb/{number}[/NO-PARSE] (e.g. [NO-PARSE]http://support.microsoft.com/kb/936332[/NO-PARSE]). Once you have reached that page, use the download link for IT Professionals, to reach the actual download page (this is the general case - some KB articles use slightly different wording, and I aim to show you these in a practice exercise very soon).
Short Practice Exercise
Have a little fiddle in the %SystemRoot%\winsxs\Manifests folder, and look at the naming conventions used for each of the different .manifest files. See if your computer has any .cat or .mum files there (most computers will have a very few .cat or .mum files here, with the vast majority in the normal location of %SystemRoot%\servicing\Packages, but you may still have a few. Explore a couple of the .manifest files in Notepad.
Once you have had a good look, come back for the rest of this tutorial.
Short Practice Exercise
Find the download links for the following Windows Updates (I strongly advise you to attempt all of these, as they each attempt to teach a subtly different point):
Code:
KB2560656
KB982018
KB2586448 (Windows 7 x64, SP0, IE9)Once you have downloaded the Windows Update file you believe to contain a clean copy of a file you are attempting to source, most usually with the file extension .msu, it must be extracted so that you can get access to the contained files. It is imperative they you do not use 3rd party extraction programs (for example 7-Zip or WinRAR) to extract either this .msu file, or any internal .cab files, as these programs incompletely extract such archives (in reality, some of these tools may work on service packs, but they certainly won't work on normal updates, so I recommend always using the one completely safe method outlined below).
First create a small directory structure in a convenient location, with a new folder inside another new folder. I shall use C:\Update\Extracted (both new, empty, folders) as an example. Place the downloaded .msu file into the outer of the two folders (C:\Update\Windows6.1-KB2345886-x64.msu in this example).
Open up an instance of the Command Prompt, and type:
expand -f:* {update location and name}.msu {destination folder}
(for example, expand -f:* C:\Update\Windows6.1-KB2345886-x64.msu C:\Update)
Then type:
expand -f:* {update location and name}.cab {destination folder}
(for example, expand -f:* C:\Update\Windows6.1-KB2345886-x64.cab C:\Update\Extracted)
Clean replacements of files can then be sourced from the C:\Update\Extracted folder.
Short Practice Exercise
Download and extract, using the methods given above, a clean copy of:
Code:
Package_1_for_KB2560656~31bf3856ad364e35~amd64~~6.1.1.2.catThe Default Package
I briefly mentioned the default or primary package earlier in this tutorial, where I said that they take a general form without a package number, for example:
Code:
Package_for_KB2345886~31bf3856ad364e35~amd64~~6.1.1.2.cat (default package)
Package_1_for_KB2345886~31bf3856ad364e35~amd64~~6.1.1.2.cat (package number 1)If you ever need to extract a replacement for the default package, you must take either update.cat or update.mum, and then rename it back immediately.
Code:
update.cat --> Package_for_KB{KB number}~{Public Key Token}~{Architecture}~~{Version}.cat
update.mum --> Package_for_KB{KB number}~{Public Key Token}~{Architecture}~~{Version}.mum
Code:
update.cat --> Package_for_KB2345886~31bf3856ad364e35~amd64~~6.1.1.2.cat
update.mum --> Package_for_KB2345886~31bf3856ad364e35~amd64~~6.1.1.2.mumFinally, the default package can also have versioned versions of it (remember from earlier in this tutorial: SP1, RTM, and occasionally others, such as VPC). These require no renaming, and should be treated just like any other .cat or .mum file. For example,
Code:
Package_for_KB2345886_RTM~31bf3856ad364e35~amd64~~6.1.1.2.catLook back once again at your extracted KB2345886. You will notice that every pair of .cat and .mum files has a linked pair of bf files, where _bf is inserted into the name directly after the kb number. Some examples:
Code:
Package_1_for_KB2345886_bf~31bf3856ad364e35~amd64~~6.1.1.2.cat
Package_1_for_KB2345886_bf~31bf3856ad364e35~amd64~~6.1.1.2.mum
Package_for_KB2345886_rtm_bf~31bf3856ad364e35~amd64~~6.1.1.2.cat
Package_for_KB2345886_rtm_bf~31bf3856ad364e35~amd64~~6.1.1.2.mum
update-bf.cat
update-bf.mumUsing Clean Copies of Files to Repair a Computer
Now that you have sourced all the required files (extracting multiple Windows Updates if required), it is time to replace the corrupt files on the affected computer. There are a couple of ways of doing this. First, I do not ever recommend altering permissions or ownership on system files. This is actually far more dangerous that it first appears, because permissions and ownership are a primary line of defence against malware. Consequently, if permissions and ownership are not reset to exactly how they were, you can open a computer up to infection. Fortunately, there are easy alternatives which avoid the need for this, which is why I expect to see none of you attempting to alter permissions or ownership on system files whilst you are under my supervision or at this forum. In addition, there is the other practical issue that files are often in-use and need to be replaced over a reboot or with special tools, and so manually altering permissions and ownership so that a standard copy & paste operation can be made to work is both dangerous and often ineffective. Provided below are the safer alternatives.
Fortunately, there is a very neat solution provided for us by Microsoft through the SURT for .cat, .mum, and .manifest files (only these file extensions, unfortunately, due to security reasons, I think).
.cat and .mum files, in pairs (remember that they must always be paired up, even if only one is corrupt), can be placed in the %SystemRoot%\Temp\CheckSur\servicing\Packages directory, and .manifest files can be placed in the %SystemRoot%\Temp\CheckSur\winsxs\Manifests directory, and the System Update Readiness Tool re-run. The SURT will then perform the replacement of corrupt files, sourcing good files from the directories given above, and dealing with all permission issues safely and securely.
This is the best way of replacing corrupt files of these extensions. However, when the corruptions lie in other locations (primarily %SystemRoot%\winsxs), or affect other file extensions, and consequently this method cannot be used, other solutions must be employed. These topics are outside of the scope of this tutorial, and will be covered in full later in the course.
Remember to rename all update.cat and update.mum files (and bf equivalents) before placing them in this directory, otherwise the SURT won't know which update those files came from.
The CheckSUR.log can then be re-analysed to confirm that all detected errors have been fixed. For example,
Code:
(f) CBS MUM Corrupt 0x800F0900 servicing\Packages\Package_2_for_KB2286198~31bf3856ad364e35~amd64~~6.1.1.1.mum Line 1:
(fix) CBS MUM Corrupt CBS File Replaced Package_2_for_KB2286198~31bf3856ad364e35~amd64~~6.1.1.1.mum from Cabinet: C:\Windows\CheckSur\v1.0\windows6.1-7601-x64-clientcab4.cab.
(fix) CBS Paired File CBS File also Replaced Package_2_for_KB2286198~31bf3856ad364e35~amd64~~6.1.1.1.cat from Cabinet: C:\Windows\CheckSur\v1.0\windows6.1-7601-x64-clientcab4.cab.
Code:
(f) CSI Manifest All Zeros 0x00000000 winsxs\Manifests\amd64_mscorlib_b77a5c561934e089_6.1.7600.20717_none_3dbbc63282d93e16.manifest amd64_mscorlib_b77a5c561934e089_6.1.7600.20717_none_3dbbc63282d93e16
(fix) CSI Manifest All Zeros CSI File Replaced File: amd64_mscorlib_b77a5c561934e089_6.1.7600.20717_none_3dbbc63282d93e16.manifest From: C:\Windows\CheckSur\v1.0\windows6.1-7601-x64-clientcab4.cabChanges in Windows 8 and Windows 10
Windows Update has a very capable auto-fix function built into it. In many cases it is able to detect and repair problems without the user ever noticing. Of course this process isn't always successful, but it does exist and it does work much of the time.
In Windows Vista and Windows 7, one of these capabilities was the System Update Readiness Tool (SURT) which was designed to repair complex servicing corruptions. It could be automatically downloaded and run by Windows Update (hence the .msu file format) whenever needed, or manually downloaded by a user from the Microsoft website.
As of Windows 8 and Windows 10, SURT is now built into the core operating system as a part of DISM (Deployment Image Servicing and Management).
To run it, you simply execute the command DISM /Online /Cleanup-Image /RestoreHealth from the Command Prompt, being mindful to get all the capital letters just right as DISM is very picky on that front.
The logfile is then output to C:\Windows\Logs\DISM.log rather than C:\Windows\Logs\CBS\CheckSUR.log, but otherwise looks very similar:
Code:
=================================
Checking System Update Readiness.
(p) CBS MUM Corrupt Package_100_for_KB2887535~31bf3856ad364e35~amd64~~6.2.1.10
(p) CBS MUM Corrupt Package_101_for_KB2887535~31bf3856ad364e35~amd64~~6.2.1.10
(p) CBS MUM Corrupt Package_1_for_KB2887537~31bf3856ad364e35~amd64~~6.2.1.6
(p) CBS MUM Corrupt Package_53_for_KB2887535~31bf3856ad364e35~amd64~~6.2.1.10
(p) CBS MUM Corrupt Package_53_for_KB2887536~31bf3856ad364e35~amd64~~6.2.1.6
(p) CBS MUM Corrupt Package_for_KB2887535_RTM~31bf3856ad364e35~amd64~~6.2.1.10
(p) CBS MUM Corrupt Package_for_KB2887535~31bf3856ad364e35~amd64~~6.2.1.10
(p) CBS MUM Corrupt Package_for_KB2887536_RTM~31bf3856ad364e35~amd64~~6.2.1.6
(p) CBS MUM Corrupt Package_for_KB2887536~31bf3856ad364e35~amd64~~6.2.1.6
(p) CBS MUM Corrupt Package_for_KB2887537_RTM~31bf3856ad364e35~amd64~~6.2.1.6
(p) CBS MUM Corrupt Package_for_KB2887537~31bf3856ad364e35~amd64~~6.2.1.6
Summary:
Operation: Detect and Repair
Operation result: 0x8000ffff
Last Successful Step: CBS store detection completes.
Total Detected Corruption: 11
CBS Manifest Corruption: 11
CBS Metadata Corruption: 0
CSI Manifest Corruption: 0
CSI Metadata Corruption: 0
CSI Payload Corruption: 0
Total Repaired Corruption: 0
CBS Manifest Repaired: 0
CSI Manifest Repaired: 0
CSI Payload Repaired: 0
CSI Store Metadata refreshed: True
Total Operation Time: 3946 seconds.Other differences between Windows 7 and later versions of Windows are mostly minor and not important right now, and will be covered in more detail later in the academy.
Conclusion
Finally, the end of the first tutorial! I hope you learned something, maybe even enjoyed it. There is plenty more to cover though: this is only the beginning.
Now would be a very good time to put your skills to the test in Practice Log 1. I would strongly advise you to do so in order to solidify your understanding, and it will hopefully also draw out any slight misunderstandings or points of confusion. Remember that you do not need to form your reply into a mock reply to the user at this time: simply provide us with the fix that you have created.
Please remember to ask us any questions that you may have, and indeed provide us with any feedback about this tutorial - weak or poorly explained areas in particular. We are all very friendly and open to questions, and it is absolutely imperative that you get a rock solid foundation in the basics before even considering moving on. So don't be shy and ask us anything and everything which is troubling you :)
Finally, now that you have had a taste as to what we do here, and what it is like to specialise in Windows Update diagnosis, I hope that you like what you have experienced. However, if you have any anxieties, or feel that this isn't for you, please talk to me about it. It may well be that there are ways we can improve your experience, or it could just be that this isn't for you. Whatever your concerns, please let me know so that we can discuss them.
Last edited: