rakhesh.com

SFC

SFC (used to be “System File Checker” but is now called Windows Resource Checker) is an in-built tool for verifying the integrity of all Windows systems files and also replacing them with good versions in case of any corruptions. It has been around for a while – I first used it on Windows 2000 I think – though am sure there’s many differences from that version and the latest ones. For instance, XP and prior used to store a copy of the system protected files in a folder called %WINDIR%\System32\DLLCache (but it would remove some of the protected files as disk space became scarce resulting in SFC prompting for the install media when repairing) while Vista and upwards use the %WINDIR%\System32\WinSxS folder (and its sub-folder %WINDIR%\System32\WinSxS\Backup).

The latest versions of SFC can also work against an offline install of Windows.

Here’s SFC on my computer complaining that it was unable to fix some errors:

It is best to view the log file using a tool like trace32 or cmtrace. Here’s a Microsoft KB article on how to use the log file. And here’s a KB article that explains how to manually repair broken files.

Servicing

Servicing is the act of enabling/ disable a role/ feature in Windows, installing/ uninstalling updates and service packs. You can service both currently running and offline installations of Windows (yes, that means you can have an offline copy of Windows on a hard disk or a VHD file and you can enable/ disable features and roles on it as well as install hot fixes and updates (but not service packs) – cool huh!). If you have used DISM (Deployment Image Servicing and Management) in Windows 7 and upwards (or pkgmgr.exe & Co. in Vista) then you have dealt with servicing.

File Based Servicing

Windows XP and before used to have File Based Servicing. The update or hotfix package usually had an installer (update.exe or hotfix.exe) that updated the files and libraries on the system. If these were system files they were installed/ updated at WINDIR%\System32 and a copy kept at the file protection cache %WINDIR\System32\DLLcache (remember from above?). If the system files were in use, a restart would copy the files from %WINDIR\System32\DLLcache to WINDIR%\System32. Just in case you needed to rollback an update, a backup of the files that were changed was kept at C:\Windows\$Uninstall$KBnnnnnn (replace “nnnnnn” with the KB number). Life was simple!

Component Based Servicing

Windows Vista introduced Component Based Servicing (CBS). Whereas with File Based Servicing everything was mashed together, now there’s a notion of things being in “components”. So you could have various features of the OS be turned off or on as required (i.e. features and roles). The component itself could be installed to the OS but not active (for example: the files for a DNS server are already installed in a Server install but not activated; when you enable that role, Windows does stuff behind the scenes to activate it). This extends to updates and hotfixes too. For instance, when you install the Remote Server Admin Tools (RSAT) on Windows 7, it installs all the admin tool components but none of these are active by default. All the installer does is just add these components to your system. Later, you go to “Programs and Features” (or use DISM) to enable the components you want. CBS is the future, so that’s what I’ll be focussing on here.

Components

From this blog post:

A component in Windows is one or more binaries, a catalog file, and an XML file that describes everything about how the files should be installed. From associated registry keys and services to what kind security permissions the files should have. Components are grouped into logical units, and these units are used to build the different Windows editions. Each component has a unique name that includes the version, language, and processor architecture that it was built for.

Component Store

Remember the %WINDIR%\System32\WinSxS folder above? That’s where all these components are stored. That folder is the Component Store. (As an aside: “SxS” stands for “Side by Side”. It is a complete (actually, more than complete) install of Windows that lives side by side to the running installation of Windows). When you install a component in Windows Vista and above, the files are actually stored in this component folder. Then, if the component feature/ role/ update is activated, hardlinks are created from locations in the file system to the files here. So, for instance, when you install a Server its component folder will already contains the files for the DNS role; later, when you enable the role hard links are created from WINDIR%\System32 and elsewhere to the files in %WINDIR%\System32\WinSxS.

Component Stack

Here’s a post from the Microsoft Servicing Guy on CBS. Like we had update.exe on XP and before, now we have trustedinstaller.exe which is the interface between the servicing stack and user-facing programs such as “Programs and Features”, DISM, MSI, and Windows Update. The latter pass on packages (and downloads them if necessary) to trustedinstaller.exe who invokes other components of the CBS stack to do the actual work (components such as CSI (Component Servicing Infrastructure), which you can read about in that link).

It is worth pointing out that dependency resolution (i.e. feature Microsoft-Hyper-V-Management-PowerShell requires feature Microsoft-Hyper-V-Management-Clients for instance) is done by the CBS stack. Similarly, the CBS stack is what identifies whether any files required for a feature/ role are already present on the system or need to be downloaded. All this info is passed on to the user-facing programs that interact with the user for further action.

Related folders and locations

Apart from the Component Store here are some other folders and files used by the CBS:

• %windir%\WinSXS\Manifests – Sub-folder of the Component Store, contains manifests
• %windir%\Servicing\Packages – A folder that contains the packages of a component. Packages are like components, they contain binaries (the payloads) and manifests (an XML file with the extension .MUM defining the payload as well as the state of the package (installed and enabled, only installed, not installed)). When you run Windows Update, for instance, you download packages that in turn update the components.

  A component might contain many packages. For instance, the Telnet-Client feature has just one package Microsoft-Windows-Telnet-Server-Package~31bf3856ad364e35~amd64~en-US~6.3.9600.16384.mum on my machine, but the HyperV-Client role has more than a dozen packages – Microsoft-Hyper-V-ClientEdition-Package~31bf3856ad364e35~amd64~en-US~6.3.9600.16384.mum being the package when the OS was installed, followed by packages such as Package_1033_for_KB2919355~31bf3856ad364e35~amd64~~6.3.1.14.mum and Package_13_for_KB2903939~31bf3856ad364e35~amd64~~6.3.1.2.mum, etc for various updates that were applied to it. (Remember: In XP and before updates targeted files. Now updates target components. So updates apply to components).

  An update that you install – say KBxxxxxxxx – might have multiple packages with each of these packages targeting different components of the system. The payload in a package is copied to the Component Store; only the .MUM defining the package is left in the %windir%\Servicing\Packages folder. Moreover, each component is updated with details of the package which affects it – this is what we see happening when an update is applied to the OS and Windows takes a long time configuring things. (Remember components are self-sufficient. So it also knows of the updates to it).

  You can get a list of packages installed on your system using the /Get-Packages switch to DISM:

  dism /online /Get-Packages

  1	dism /online /Get-Packages

  To get the same info as a table rather than list (the default):

  dism /online /Get-Packages /Format:Table

  1	dism /online /Get-Packages /Format:Table

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing – A registry key tree holding a lot of the servicing information.

  For instance, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageDetect\Microsoft-Hyper-V-ClientEdition-Package~31bf3856ad364e35~amd64~~0.0.0.0 on my machine tells me which packages are a part of that component.

  Note that the above component name doesn’t have a language. It is common to all languages. There are separate keys – such as HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageDetect\Microsoft-Hyper-V-ClientEdition-Package~31bf3856ad364e35~amd64~en-US~0.0.0.0 – which contain packages for that specific language variant of the component.

• %windir%\WinSXS\Pending.xml – An XML file containing a list of commands and actions to be performed after a reboot for pending updates (i.e. files that couldn’t be modified as they are in use)
• %windir%\Logs\CBS\CBS.log – The CBS log file.

Here’s a blog post from The Servicing Guy talking about the above locations. Unfortunately, it’s only part 1 as he didn’t get around to writing the follow-ups.

Summary

Here’s a high-level summary of many of the points I touched upon above:

• Windows Vista and upwards use Component Based Servicing. A component is a self-sufficient unit. It includes binaries (files and libraries) as well as some metadata (XML files) on where the files should be installed, security rights, registry & service changes, etc. In Windows Vista and upwards you think of servicing in terms of components.
• The files of a component are stored in the Component Store (the WinSxS folder). Everything else you see on the system are actually hard-links to the files in this Component Store.
• When a component is updated the older files are not removed. They stay where they are, with newer versions of any changed files being installed side by side to them and references to these files from elsewhere are now hard-linked to this newer version. This way any other components or applications that require the older versions can still use them.
• Components can be thought of as being made up of packages. When you download an update it contains packages. Packages target components. The component metadata is updated so it is aware that such and such package is a part of it. This way even if a component is not currently enabled on the system, it can have update packages added to it, and if the component is ever enabled later it will already have the up-to-date version.
• Remember you must think of everything in terms of components now. And components are self-sufficient. They know their state and what they do.

Service store corruptions

The Component Store can get corrupted, resulting in errors when installing updates and/ or enabling features. Note: this is not corruption with the system – which can be fixed via tools such as SFC – but corruptions to the Component Store itself.

Windows 8 and later

Windows 8 and upwards can detect and fix such corruptions using DISM /Cleanup-Image (don’t forget to specify /Online for online servicing or /Image:\path\to\install for offline servicing):

• DISM /Cleanup-Image /ScanHealth will scan the Component Store for errors. It does not fix the error, only scans and updates a marker indicating the Store has errors. Any errors are also logged to the CBS.Log file.
• DISM /Cleanup-Image /RestoreHealth will scan as above and also fix the error (so it’s better to run this than scan first and then scan & repair).
• DISM /Cleanup-Image /CheckHealth will check whether there’s any marker indicating the system has errors. It does not do a scan by itself (so there’s no real point to running this, except to quickly check whether any tool has previously set the marker).

If PowerShell is your weapon of choice (yaay to you!), you can use Repair-WindowsImage -ScanHealth | -RestoreHealth | -CheckHealth instead.

If corruptions are determined and you have asked for a repair then Windows Update/ WSUS are contacted for good versions of the components. The /LimitAccess switch can be used to disable this; the /Source switch can be used to specify a source of your own (you must point to the WinSxS folder of a different Windows installation; see this TechNet article for some examples). (Update: WSUS is not a good source so it’s better to use gpedit.msc or GPOs to temporarily specify a Windows Update server, or use the /LimitAccess switch to not contact WU/ WSUS at all and specify a WinSxS folder to use).

Example:

Windows 7 and prior

Windows 7 and below use a Microsoft tool called CheckSUR (Check System Update Readiness).

Here’s a blog post on using CheckSUR to repair corruption. Note that CheckSUR can only repair manifests while DISM /Cleanup-Image can do both manifests and payloads.

Managing the component store size

The Component Store will keep growing as more updates are installed to a system. One way to reduce the size is to tell Windows to remove all payloads from older Service Packs. For instance, say the machine began life as Windows 7, then had updates applied to it, then a Service Pack. You know you will never uninstall this Service Pack so you are happy with removing all the older payloads from WinSxS and essentially tell the OS that from now on it must consider itself as Windows 7 Service Pack 1 for good – there’s no going back.

Here’s how you can do that for the various versions of Windows:

• Windows Vista Service Pack 1 uses a tool called VSP1CLN.EXE to do this.
• Windows Vista Service Pack 2 and Windows Server 2008 SP2 use a tool called Compcln.exe
• Windows 7 Service Pack 1, Windows Server 2008 R2 Service Pack 1, and above use DISM /online /Cleanup-Image /SpSuperseded (for Windows 7 Service Pack 1 with update KB2852386 you can also use the Disk Cleanup Wizard (cleanmgr.exe)).
  • Also see this blog post.

Automatic scavenging

Windows 7 and above also automatically do scavenging to remove unused components from the Component Store. Windows Vista and prior do scavenging on a removal event, so you can add and remove a feature to force a scavenging.

Windows 8 has a scheduled task StartComponentCleanup that automatically cleans up unused components. It waits 30 days after a component has been updated before removing previous versions (so you have 30 days to rollback to a previous version of the update). You can run this task manually too:

Check this blog post for some screenshots.

Windows 8.1 and Server 2012 R2 extras

Windows 8.1 and Windows Server 2012 R2 include a new DISM switch to analyze the Component Store and output whether a clean up can be made.

The clean up can be done automatically or manually run via the task scheduler entry as previously mentioned. DISM too has a new switch which does the same (but doesn’t follow the 30 days rule like the schedule task so it is more aggressive).

The above switch is available in Windows 8 and Windows Server 2012 too.

Note that the scavenging options above (Windows 7 and up) only remove previous versions of the components. They are not as aggressive as the options to re-base the OS to a particular service pack. Once the previous versions of the components are removed you cannot rollback to those older versions but you can still uninstall the update you are on.

Windows 8.1 and Server 2012 R2 introduce a new switch that lets you re-base to whatever state you are in now. This is the most aggressive option of all as it makes the state of the system permanent. You cannot uninstall any of the existing updates after you rebase (any newer updates made hence can be uninstalled) – the state your system is in now will be frozen and become its new state. This new switch is called /ResetBase:

Windows Server 2012 and Server 2012 R2 extras

Windows Server 2012 introduces the concept of “features on demand”.

Remember I had said by default all the payloads for all the features in Windows are present in the WinSxS folder. When you enable/ disable features you are merely creating hard-links for the files in WinSxS. What this means is that even though your Server 2012 install may not use a feature its files are still present and taking up space in the WinSxS folder. Starting with Server 2012 you can now uninstall (rather than remove) a feature so its files from the WinSxS folder are deleted.

Of course once you remove the files this if you want to enable the feature later you must also specify a source from where they can be downloaded. Check this blog post for more info.

Update: A Feb 2015 post from the PFE team that goes into pretty much the same stuff I mention above in terms of reducing the WinSxS folder size.