Professional Documents
Culture Documents
Understand and Troubleshoot Servicing in Windows Server 8 Beta
Understand and Troubleshoot Servicing in Windows Server 8 Beta
Abstract
This Understand and Troubleshoot Guide (UTG) enables you to learn technical concepts, functionality, and troubleshooting methods for Servicing in Windows Server 8 Beta. This UTG provides you with: A technical overview and functional description of this feature. Technical concepts to help you successfully install, configure, and manage this feature. User Interface options and settings for configuration and management. Relevant architecture of this feature, with dependencies, and technical implementation. Primary troubleshooting tools and methods for this feature.
Copyright information
This document is provided as-is. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. 2012 Microsoft. All rights reserved.
Active Directory, Hyper-V, Microsoft, MS-DOS, Visual Basic, Visual Studio, Windows, Windows NT, Windows Server, and Windows Vista are trademarks of the Microsoft group of companies.
About the Authors Author: Bio: Joseph Conway Joseph is a Senior Support Escalation Engineer on the Windows CORE team based in Charlotte, NC with 13 years of Windows support experience. He has experience in releases of Windows from Windows NT 4.0 to Windows Server 2008 R2 and is currently a beta engineer on the Windows Server "8" Beta team. Joseph has created or contributed to many training courses and Microsoft KB articles and is the author of the Windows Servicing Guy blog (http://blogs.technet.com/b/joscon/)
Table of Contents
Understand and Troubleshoot Servicing in Windows Server "8" Beta ......................................................... 1
Introducing Windows Servicing .................................................................................................................................1 Technical Overview ...............................................................................................................................................2 Componentization terminology ............................................................................................................................2 Component state terminology ..............................................................................................................................3 Features on Demand .................................................................................................................................................4 Using DISM ................................................................................................................................................................4 In-box Corruption Repair .........................................................................................................................................19
Purpose/Benefits
Windows servicing design is based on the concept of operating system componentization. Componentization allows uniformity in the Windows codebase by allowing all Windows developers to write to a standard manifest. Additionally, the servicing design allows for a more robust mechanic for the installation or removal of a specific binary by supporting transactional rollback of operations. DISM was created to be a consolidated tool for any operations needed to prepare an image for deployment or modify an image post-deployment. DISM consolidated many of the tools previously included in Windows AIK with Windows 2008 and Windows Vista. Windows Server "8" Beta enhances the DISM tool to include robust new features for predeployment and post-deployment environments. We will discuss these improvements through the remainder of this guide as well as offer hands-on examples, that can further increase understanding of this tool and its capabilities. In brief, the new components are: Features on Demand In-box corruption repair IMAGEX ported to DISM Fully offline capable support DISM Windows PowerShell cmdlet support
Technical Overview
Requirements
The Windows Servicing components do not have any prerequisites, as they are included with every client and server edition. DISM also does not have any prerequisites; it is included with every client and server version of the operating system. DISM capabilities introduced with Windows Server "8" Beta are available on down-level versions of Windows 7 by installing the Assessment and Deployment Kit (ADK). The ADK has its own prerequisites on those computers.
Functional Description
System builders and administrators use DISM to service both online and offline images throughout the image life cycle. DISM is a command line tool that offers Windows PowerShell support (new in Windows Server "8" Beta) for the scriptable installation of drivers, Windows Updates, localization settings (not available in Windows PowerShell cmdlets) and image edition management.
Componentization terminology
Component Store: Repository of components that contain all previous versions of files, including the current version, projected to the file system as needed. The component store is the \Windows\winsxs directory. Package Store: Repository of package manifests on the system. The package store is located in \Windows\servicing\packages. New package manifests are added to this store as updates are installed. Component: The basic building block for servicing operations. Manifests define components. They act as a container for such resources as binaries, registry values, services and security descriptors. Components have unique names comprised of a standard set of identity attributes. Manifest: Used to define components or deployments. Manifests can be broken into the following types: o Package (or Update): A container for deployments as well as other packages. The only type of manifest that does not contain the .man extension; instead, they use .mum. Package manifests do the following: Act as a container for deployments or other packages Define feature selectability (can it be turned on/off) Define package applicability. For example, do other packages need to be installed first
Component: Serves as the most basic building block that describes a feature. It defines the resources required for the feature such as binaries, registry values, services, dependencies, etc.
Features on Demand
Features on Demand is a new option in Windows Server "8" Beta that allows administrators and image builders to reduce the amount of space used by the component store by removing the payload of the optional component from a system image. Payload refers to the role or feature associated binaries. Features on Demand also allow for the addition of roles and features on an as-needed basis once removed from an image and an appropriate restoration source. Available sources include Windows Server "8" Beta or Windows 8 Consumer Preview WIM files, network location with Windows installation files and Windows Update. Features on Demand is exposed via the DISM command line interface, the new DISM and Server Manager Windows PowerShell cmdlets.
Using DISM
DISM is the platform used for most servicing operations in Windows. DISM is a context-based command line interface. The image target determines available commands. Variations include the image state (online or offline) and image type (full operating system, core operating system or Windows PE image). Commands are specific to these variable factors and must be taken into account when servicing an image. For example, Windows PE commands are only available when servicing a Windows PE image. Online targets are running operating systems. Offline targets are images being prepared for deployment and currently mounted to a folder. Because DISM.exe commands are image state specific, some commands can only run against a specific image state. An example is the command: DISM.exe /online /set-edition that allows a Windows image to transition to a higher edition on server-based operating systems (i.e. Standard to Datacenter). While you can run this command against both online or offline images, the syntax of the specific command is dependent on the image state and operating system type (client or server). For example, an online image requires the /ProductKey switch to set the operating system edition, whereas for an offline image the command is /Set-ProductKey and must be run after the /Set-Edition command. DISM.exe has a multi-level help structure, that is dependent on the operation and the target image. For example, when you first run DISM.exe help (using DISM /?), it displays the following output. New commands for Windows Server "8" Beta are shown in bold:
Deployment Image Servicing and Management tool Version: 6.2.8166.0
DISM.exe [dism_options] {Imaging_command} [<Imaging_arguments>] DISM.exe {/Image:<path_to_offline_image> | /Online} [dism_options] {servicing_command} [<servicing_arguments>] DESCRIPTION: DISM enumerates, installs, uninstalls, configures, and updates features
and packages in Windows images. The commands that are available depend on the image being serviced and whether the image is offline or running. GENERIC IMAGING COMMANDS: /Get-MountedImageInfo /Get-ImageInfo /Commit-Image /Unmount-Image /Mount-Image /Remount-Image /Cleanup-Mountpoints WIM COMMANDS: /List-Image /Delete-Image /Split-Image only /Export-Image /Append-Image /Capture-Image data /Apply-Image /Get-MountedWimInfo /Get-WimInfo /Commit-Wim /Unmount-Wim /Mount-Wim /Remount-Wim /Cleanup-Wim - Displays a list of the files and folders in a specified image. - Deletes the specified volume image from a WIM file that has multiple volume images. - Splits an existing .wim file into multiple readsplit WIM (SWM) files. - Exports a copy of the specified image to another file. - Adds another image to a WIM file. - Captures an image of a drive into a new WIM file. Captured directories include all subfolders and Applies an image. Displays information about mounted WIM images. Displays information about images in a WIM file. Saves changes to a mounted WIM image. Unmounts a mounted WIM image. Mounts an image from a WIM file. Recovers an orphaned WIM mount directory. Deletes resources associated with mounted WIM images that are corrupted. - Displays information about mounted WIM and VHD images. - Displays information about images in a WIM or VHD file. - Saves changes to a mounted WIM or VHD image. - Unmounts a mounted WIM or VHD image. - Mounts an image from a WIM or VHD file. - Recovers an orphaned image mount directory. - Deletes resources associated with corrupted mounted images.
IMAGE SPECIFICATIONS: /Online /Image - Targets the running operating system. - Specifies the path to the root directory of an offline Windows image.
DISM OPTIONS: /English /Format /WinDir /SysDriveDir /LogPath /LogLevel Displays command line output in English. Specifies the report output format. Specifies the path to the Windows directory. Specifies the path to the system-loader file named BootMgr. - Specifies the logfile path. - Specifies the output level shown in the log (1-4).
- Suppresses automatic reboots and reboot prompts. - Suppresses all output except for error messages. - Specifies the path to a scratch directory.
For more information about these DISM options and their arguments, specify an option immediately before /?. Examples: DISM.exe DISM.exe DISM.exe DISM.exe
This output details many of the image mounting options and some of the global command arguments used with DISM servicing command options. DISM help also shows the commands used to service an online image. To see the online DISM commands, you need to run the DISM help command (DISM /online /?). This can also be run against an offline image using the /image argument. The command displays the following output:
Deployment Image Servicing and Management tool Version: 6.2.8166.0 Image Version: 6.2.8166.0
The following commands may be used to service the image: WINDOWS EDITION SERVICING COMMANDS: /Set-ProductKey /Get-TargetEditions /Get-CurrentEdition /Set-Edition - Sets the product key of the offline image. - Displays a list of Windows editions that an image can be upgraded to. - Displays the edition of the current image. - Upgrades an image to a higher edition.
DEFAULT ASSOCIATIONS COMMANDS: /Remove-DefaultAppAssociations - Removes the default application associations from a Windows image. /Import-DefaultAppAssociations - Imports a set of default application associations to a Windows image. /Get-DefaultAppAssociations - Displays the list of default application associations from a Windows image. /Export-DefaultAppAssociations - Exports the default application associations from a running operating system. APPX SERVICING COMMANDS: /Remove-ProvisionedAppxPackage - Removes AppX packages from the image. AppX packages will not be installed when new user accounts are created. /Add-ProvisionedAppxPackage - Adds AppX packages to the image and sets them to install for each new user.
/Get-ProvisionedAppxPackages - Displays information about AppX packages in an image that are set to install for each new user. UNATTEND SERVICING COMMANDS: /Apply-Unattend DRIVER SERVICING COMMANDS: /Remove-Driver /Add-Driver /Get-DriverInfo /Get-Drivers - Removes driver packages from an offline image. - Adds driver packages to an offline image. - Displays information about a specific driver in an offline image or a running operating system. - Displays information about all drivers in an offline image or a running operating system. - Applies an unattend file to an image.
INTERNATIONAL SERVICING COMMANDS: /Set-LayeredDriver /Set-UILang /Set-UILangFallback /Set-UserLocale /Set-SysLocale - Sets keyboard layered driver. - Sets the default system UI language that is used in the mounted offline image. - Sets the fallback default language for the system UI in the mounted offline image. - Sets the user locale in the mounted offline image. - Sets the language for non-Unicode programs (also called system locale) and font settings in the mounted offline image. - Sets the input locales and keyboard layouts to use in the mounted offline image. - Sets the default time zone in the mounted offline image. - Sets all international settings in the mounted offline image. - Sets all international settings to the default values for the specified SKU language in the mounted offline image. - Generates a new lang.ini file. - Defines the default language that will be used by setup. - Displays information about the international settings and languages.
APPLICATION SERVICING COMMANDS: /Check-AppPatch /Get-AppPatchInfo /Get-AppPatches /Get-AppInfo /Get-Apps - Displays information if the MSP patches are applicable to the mounted image. - Displays information about installed MSP patches. - Displays information about all applied MSP patches for all installed applications. - Displays information about a specific installed MSI application. - Displays information about all installed MSI applications.
PACKAGE SERVICING COMMANDS: /Add-Package /Remove-Package /Enable-Feature /Disable-Feature /Get-Packages /Get-PackageInfo /Get-Features /Get-FeatureInfo /Cleanup-Image Adds packages to the image. Removes packages from the image. Enables a specific feature in the image. Disables a specific feature in the image. Displays information about all packages in the image. Displays information about a specific package. Displays information about all features in a package. Displays information about a specific feature. Performs cleanup and recovery operations on the image.
For more information about these servicing commands and their arguments, specify a command immediately before /?. Examples: DISM.exe /Image:C:\test\offline /Apply-Unattend /? DISM.exe /Image:C:\test\offline /Get-Features /? DISM.exe /Online /Get-Drivers /?
Each command has further nested help that gives more information on the command and its usage. Using the set-edition command, we can see that further information on the command can be found by running the help for that command (DISM /online /set-edition /?):
Deployment Image Servicing and Management tool /Set-Edition:<edition_ID> [/ProductKey:<product_key>] /GetEula:<path>] [/AcceptEula |
Use the /Set-Edition option without the /ProductKey option to change an offline Windows image to a higher edition. Use the /Set-Edition option with the /ProductKey option only to change a running Windows Server operating system to a higher edition. Use /Get-TargetEditions to find the edition-IDs. Example: DISM.exe /Image:C:\test\offline /Set-Edition:"Ultimate" For more information about this topic, see: http://technet.microsoft.com/en-us/library/dd744256(WS.10).aspx
More Information:
From here we can see the specific options for both online/offline and server/client images. Current likely scenarios for using the DISM tool include: Adding additional third party drivers to an offline image prior to releasing the image for deployment Adding additional Windows Update security patches to an offline image prior to deployment
Once they create a deployment roadmap for the new image, administrators can remove the roles and features from the selected image. One method to remove roles and features is to do the following: 1. Copy the installation WIM to a local directory (in this example C:\) 2. Create a mount directory to mount the WIM to (in this example C:\image) 3. Find the index of the image you will be editing:
DISM /get-imageinfo /imagefile:c:\install.wim 4. Mount the image to the folder created in step #2: DISM /mount-image /imagefile:c:\install.wim /index:3 /mountdir:c:\image
5. Determine the name of the role or feature to be removed: 6. Determine the name(s) of the features to be removed from the installation source and then remove them:
DISM /image:c:\image /disable-feature /featurename:DHCPServer /remove DISM /image:c:\image /get-features /format:table > features.txt
9. Prepare the image for deployment by adding it to a WDS or MDT deployment point. Verification of role and feature removal happens post-deployment by attempting to add the role or feature back into the operating system using Server Manager, DISM.exe or the Windows PowerShell cmdlets. The removal event appears differently for each utility. In Server Manager, the removed feature is selectable but the installation of the removed feature will fail. Feature on Demand does not support adding features back into the image using Server Manager.
In DISM.exe, checking the feature information shows that the package state is disabled with Payload Removed. This allows administrators to know that the feature itself is not present on the computer. The following is an example of a command used to query feature status:
DISM /online /get-featureinfo /featurename:DHCPServer
10
You can see further confirmation of feature removal by attempting to install the feature within DISM. It fails with exit code: 0x800f0906. This error does not occur if group policy objects (GPO) have been enabled in an environment that allow alternative sources such as Windows Update or alternate source locations. In this case, the feature would be re-enabled. The command for this is:
DISM /online /enable-feature /featurename:DHCPServer
11
When removing a package from an online image that requires a restart to complete the package removal, the administrator will be presented with a restart now option as seen in the figure below. Payload removal will not occur until the reboot is completed and the package state will show as Disable Pending in DISM. When a removal operation pends a reboot, any subsequent removal events will also prompt the administrator for a reboot until the condition for the reboot is satisfied. The command for this is:
DISM /online /disable-feature /featurename:NetFx4 /remove
12
Additionally, there are also Windows PowerShell cmdlets available for Windows Server Manager. These cmdlets were present in Windows 2008 R2 and Windows 7 and can be loaded using the module name servermanager. This command gives an available listing of cmdlets for Server Manager includes. The command is:
Get-command -module servermanager|ft -auto
It is important to understand Windows PowerShell usage for the DISM and servermanager modules. The servermanager module shares functional parity with the Server Manager User interface. This means you can use servermanager cmdlets to add and remove Windows Server roles and features. They can also remove the payloads of those roles and features via Features on Demand. The DISM cmdlet set offers the ability to also remove role and feature payloads available with the Features on Demand option. Additionally, the DISM cmdlets offer the ability to manipulate packages, drivers, edition settings and more. In the following example, we remove the DHCP Server role using the Features on Demand DISM cmdlets:
13
1. Mount the Windows Image to modify: mount-windowsimage -imagepath c:\install.wim -index 3 -path c:\image
Once the feature is removed its State will show as DisabledwithPayloadRemoved 5. Unmount the image, saving the changes:
DISMount-windowsimage -path c:\image -save
6. Deploy the image Using the Server Manager module, you can accomplish the same task as above. In the following example, we will remove the DHCP Server role from a running Windows Server "8" Beta: 1. Open an Administrative Windows PowerShell command prompt 2. Remove the DHCP Server role from Windows:
uninstall-windowsfeature DHCP -remove
Note:
14
Administrators may wish to limit the restoration sources for removed features based on enterprise security concerns or productivity concerns. To add features back into an image that have been previously removed, administrators will need to use DISM.exe from an elevated command prompt, the Windows PowerShell cmdlets for DISM or Server Manager and a path to the Windows Image file (.WIM) that holds the necessary payload for the feature to be restored. Source paths are not required if GPO's have been defined for the environment. To restore features using DISM.exe: 1. Locate the .WIM file that contains the payload for the restore operation. This can be located on locally attached storage or a network share. 2. Run the command: DISM /online /enable-feature /featurename:telnetclient /source:wim:c:\install.wim:2 (where the WIM index is the image in the WIM file that contains the source of the feature payload)
Starting with Windows Vista and Windows 2008, Windows operating systems are packaged in the Windows Image Format (WIM). The WIM format enables the shipment of multiple editions of the operating system from within the same file. Windows uses the product key to determine the edition channel and index in the \sources\install.wim to install. Determining the images carried within a specific WIM file can be done with DISM. This is done with the following command: Get-WindowsImage -ImagePath d:\sources\install.wim The output of the command is below.
Note:
Important:
To reduce overall operating system disk footprint, the Windows Server "8" Beta Core installation option has many roles and features removed from its component store. Windows Server "8" Beta Core editions can utilize features on demand functionality to install
15
roles or features that are not present. When adding features to a Windows Server "8" Beta Core system, administrators should ensure they are using the proper index as an installation source as the Windows Server "8" Beta Core indexes do not carry the required payload to reinstall roles or features that are not already present. To install roles and features on a Windows Server "8" Beta Core computer, use the non-Core indexes found in install.wim (such as index 2 and 4 in the image above).
Administrators who wish to disable the use of Windows Update and WSUS servers from being used as applicable sources for enabling features can use the /LimitAccess switch inside of DISM. This will prevent the installation from attempting to contact WU/WSUS servers. An example of this command would be:
DISM /image:c:\image /enable-feature /featurename:telnetclient /limitaccess
This would enable the Telnet Client feature without attempting to contact external Windows Update servers or internal WSUS servers.
This returns a status value for a field labeled "Complete Offline Capable. Return values for this field shown below, along with a description.
Value Description The update/package cannot complete installation of an offline image and will require the image be brought online in order to complete install. When adding such a package to an offline image, the package will be of Install State pending until the image is brought online.* The update/package completes all of its actions if installed to an offline image. After adding such a package to an offline image, the package Install State is installed. It is not possible to pre-determine whether the package/update is Completely Offline Capable or not. (This is typically due to the complex dependencies that exist between packages that may not already be on the users system. Determination can only be made at runtime.)
No
Yes
Undetermined
16
After adding such a package to an offline image, the package will be in Install State pending if it requires online processing to complete its actions, or in state installed if it was Completely Offline Capable.
In some cases, Administrators may want to apply updates if, and only if, they are Completely Offline Capable. The offline capabilities of some packages may be listed as Undetermined and discernible only at runtimeAdministrators can utilize the /prevent-pending switch as part of their installation command. The /prevent-pending switch ensures that a package is only applied to a mounted image if it is Completely Offline Capable. If, at runtime, it is determined the package is not Completely Offline Capable (thereby generating pended actions), Windows cancels package installation before applying to the system. Syntax for this command is:
DISM /image:c:\image /add-package /package-path:c:\<update> /prevent-pending
Available policy settings include the following: Alternate source file path: Specifies the network location for use in installation operations. This must be a fully qualified path and can be either a folder location or
17
WIM file. You can specify multiple paths by using ";" between the paths. Valid syntax is wim:<path to wim>:<index> Never attempt to download payload from Windows Update: Disables the use of Windows Update as an installation source
Values for this policy are in the registry under the following key:
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Servicing
Possible registry values include: LocalSourcePath Specifies location to use for installation source. Can specify more than one source when separated with a ;. Valid sources include a network folder path or a WIM file (using the syntax wim:<path to wim>:<index>) UseWindowsUpdate Enables use of Windows Update as an installation source
18
Available options include the following: /CheckHealth: scans for corruption flags on the servicing stack. No corrective action is taken if this returns a positive result. This operation is very quick and returns a status of one of the following: o o o The image store is healthy The image store is repairable The image store is not repairable
/ScanHealth: scans for known corruption markers in the servicing stack and report them back to the user. It takes no action based on the scan results. This operation has a progress indicator during its scan and can take several minutes to complete. It returns a status of one of the following: o The image store is healthy
19
o o
/RestoreHealth: Scans for component store corruption and proactively repairs any corruption found. It returns a status of one of the following: o o o The image store is healthy The image store is repairable The image store is not repairable
/LimitAccess: When used with /RestoreHealth, does not attempt to download repair files from Windows Update if they could not be found in the local source
DISM Windows PowerShell cmdlets expose this functionality through the RepairWindowsImage verb. An example of usage for Windows PowerShell would be:
Repair-WindowsImage -CheckHealth -online
This command would scan the servicing stack for corruption flags and report the status back to the user. For corruption repair, the available sources for files include: Local or network attached Windows Image file known to carry the payload needed for repair Windows Update (if configured) Standard folder layout (such as the \Sources\sxs folder)
When the in-box corruption repair tool has finished running, the results write to the C:\Windows\Logs\DISM\DISM.log. The DISM.log will only contain entries for the /ScanHealth and /RestoreHealth commands. An example of a clean entry in the DISM.log:
20
Available policy settings include the following: Alternate source file path: Specifies the network location for use in repair operations. This must be a fully qualified path and can be either a folder location or WIM file. Specify multiple paths by using ";" between the paths. Valid syntax is wim:<path to wim>:<index> Never attempt to download payload from Windows Update: Disables the use of Windows Update as a repair source
21
Contact Windows Update directly to download repair content instead of Windows Server Update Services (WSUS): Bypasses the WSUS servers and directly contacts Windows Update as a repair source.
Values for this policy are in the registry under the following key:
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Servicing
Possible registry values include: LocalSourcePath locations to use for repair sources. Can specify more than one source when separated with a ;. Valid sources include a network folder path or a WIM file (using the syntax wim:<path to wim>:<index>) UseWindowsUpdate Enables use of Windows Update as a repair source RepairContentServerSource if using a WSUS server for Windows Update, this ignores the WSUS server and uses the Microsoft Windows Update server (for repair source only, does not affect servicing)
22 2012 Microsoft Corporation. All rights reserved.
23
To prevent unwanted changes to system files, the TrustedInstaller account owns the majority of files in the \System32 directory. This account is part of the TrustedInstaller service used by the component store to make changes against an online Windows system during a servicing event. Because the Trusted Installer account owns these files, users must take ownership of the file/directory to make any meaningful changes to an online operating system. You can change offline systems at will. Microsoft does not recommend making changes to the file system in this fashion; it can result in system instability. In the event of unwanted changes to the file system or component store, the first step in troubleshooting would be to verify that the current files on the file system are valid. To verify the validity of the component store use the System File Checker (SFC.exe). SFC can be run online or offline against an operating system. SFC verifies a cryptographically signed hash; if this hash value does not match the hash in the component store, the file is re-projected. Unlike in Windows 2003 and prior, Windows 8 Consumer Preview and Windows Server "8" Beta does not proactively repair - only as a reactive measure. This means that you must run SFC for actions to take place against the file system. Prior to running SFC, Microsoft Support recommends verifying component store integrity with DISM. SFC contains the following options:
24
SFC [/SCANNOW] [/VERIFYONLY] [/SCANFILE=<file>] [/VERIFYFILE=<file>] [/OFFWINDIR=<offline windows directory> /OFFBOOTDIR=<offline boot directory>] /SCANNOW with /VERIFYONLY operation is /SCANFILE problems are /VERIFYFILE repair /OFFBOOTDIR directory /OFFWINDIR directory Scans integrity of all protected system files and repairs files problems when possible. Scans integrity of all protected system files. No repair performed. Scans integrity of the referenced file, repairs file if identified. Specify full path <file> Verifies the integrity of the file with full path <file>. operation is performed. For offline repair specify the location of the offline boot For offline repair specify the location of the offline windows
No
Use of the appropriate switch with SFC is important because not all switches result in repair operation(s). For example, the /verifyonly and /verifyfile switches do not project any files when run against a system but does display files that are not correct. The only authoritative command line switches are /scannow and /scanfile. When running these commands against an online or offline store, any files that do not match the files in the component store are projected. One further consideration with SFC is its usage in offline servicing, such as when booted into WinRE. When booted in WinRE, the component store is not specified. To specify the proper component store and ensure any changes take effect, use the /OFFBOOTDIR and /OFFWINDIR switches. For example, the following command would project the kernel32.dll file if the file in \System32 were different from that in the component store on D:\Windows\winsxs:
sfc /SCANFILE=d:\windows\system32\kernel32.dll /OFFBOOTDIR=d:\ /OFFWINDIR=d:\windows
Also note, both the /OFFBOOTDIR and /OFFWINDIR switches must be specified when servicing an offline store.
25
Each of the aforementioned log files should be collected for every servicing issue. Each log details different information about the servicing operations on a computer. The following sections specify what each log details as well as any additional options available for the logs verbosity.
CBS.log
The CBS.log is the primary log to use when troubleshooting servicing issues. The CBS.log gives a verbose listing of most of the actions happening with in each servicing session. The CBS.log will list such events as the applicability checks for the performed operation, the plan section that results from those checks, and any failures that may occur during the installation or uninstall of a servicing component. The CBS.log is also useful in determining the parent/child relationships that are involved in each operation and what the states of those manifests or packages are. The CBS.log is quite detailed by default; however, it does offer an extra layer of verbosity that will show the file and registry operations being performed for each transaction. To enable verbose CBS logging: 1. NET STOP TRUSTEDINSTALLER 2. Add the following system environment variable: WINDOWS_TRACING_FLAGS with a value of 10000. *NOTE: This does not require a reboot. 3. NET START TRUSTEDINSTALLER Anything new logs
WindowsUpdate.log
The WindowsUpdate.log logs all of the information passed by the Windows Update Agent (WUA). WUA triggers when users attempt to install Windows Updates from within the Windows Update control panel or if the user has automatic updates enabled. Using the WindowsUpdate.log in conjunction with a CBS.log can allow you to line up time stamps to get detailed information about a specific error. To enable more verbose WindowsUpdate.log logging, do the following: Add the following new registry entries: o HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Wi ndowsUpdate\Trace
26
Add a DWORD value: "Flags" with a HEX value of 16. Add a DWORD value: "Level" with a HEX value 3 Stop and restart the Windows Update Service using the command: net stop wuauserv and net start wuauserv
DISM.log
The DISM.log gives detailed information from the perspective of DISM that is manipulating packages on behalf of the DISM tool. The log creates entries only when the DISM tool itself manipulates packages. This makes the DISM.log a required troubleshooting log for instances of attempting to install, remove or manipulate packages outside of the normal servicing infrastructure (such as Windows Update). The DISM.log offers four levels of verbosity via the /Loglevel switch in DISM. Logging options display in the output below:
Deployment Image Servicing and Management tool Version: 6.1.7600.16385
/LogLevel:<n> Specifies the maximum output level shown in logs. The accepted values are: 1 = Errors only 2 = Errors and warnings 3 = Errors, warnings, and information 4 = All the above and debug output If not specified, it defaults to 3 (maximum logging). Example: DISM.exe /Image:C:\test\offline /loglevel:1.
Sessions.xml
The sessions.xml logs each transaction within a specific servicing session. The sessions.xml exists as several different files. One complete sessions.xml file that lists all of the CBS sessions activity on a system, and individual sessions files for the independent sessions. Microsoft Support recommends gathering the complete sessions.xml log for troubleshooting, because there may be an issue that persists across sessions. Sessions.xml breaks a CBS session into the independent actions performed against a specific set of package(s) during a CBS operation. The log is useful to determine the specific actions that should have taken place against a package. Sessions.xml lists the client who initiated the session, such as Windows Update Agent, the package identifier(s), and the various actions taken against those packages (including state changes).
27
Pending.xml
Windows creates the pending.xml file when there are POQ (pending operations queue), AIQ (advanced operation queue) or DOQ (driver operations queue) operations pending processing on shutdown or reboot. This file contains the list of changes to the system for
28
when that reboot takes place and can be valuable in determining if there are any actions missing from a specific servicing action.
There are times when a pending operation fails and generates a pending.xml.bad file. If this file exists on a system, collect it with the pending.xml file.
Note:
// CBS writes the poqexec string to SetupExecute so that if the system loses power unexpectedly before shutdown processing can occur, SMSS will run the POQ under the hood. This only happens if there are no pending driver operations. Since shutdown processing is actually occurring here, the string is taken from SetupExecute and later removed after success 2008-12-09 13:54:11, Info CBS Obtained poqexec from SetupExecute. C:\Windows\winsxs\x86_microsoft-windowsservicingstack_31bf3856ad364e35_6.0.6002.16601_none_0b471220c46f9bfc\poqexec.ex e /display_progress \SystemRoot\WinSxS\pending.xml // The POQ is extracted out of the pending.xml 2008-12-09 13:54:11, Info CBS Running poqexec with: C:\Windows\winsxs\x86_microsoft-windowsservicingstack_31bf3856ad364e35_6.0.6002.16601_none_0b471220c46f9bfc\poqexec.ex e /noreboot /display_progress \SystemRoot\WinSxS\pending.xml 2008-12-09 13:54:11, Info 2008-12-09 13:54:32, Info from SetupExecute 2008-12-09 13:54:32, Info SetupExecute. 2008-12-09 13:54:32, Info completed successfully. CBS CBS CBS CBS Shtd: progress thread started Attempting to remove poqexec Removed poqexec from Shtd: Primitive operations
DISM:
DISM has several useful commands for troubleshooting servicing issues. Notably the revertpendingactions command and the new in-box corruption commands. /Revertpendingactions allows for the cancelling of all pending packages on a system. This is very handy to use in cases where installing a driver or other update prevents normal boot. By using the revertpendingactions switch via DISM on a system, a cancelling session is generated and passed to CBS. Once done, no further servicing actions can take place against
29
the machine and a reboot is required for the cancelling session to run and remove the pending updates. The /revertpendingactions command is only meant for recovery scenarios and should only be used for that purpose.
DISM.exe /Image:C:\test\offline /Cleanup-Image /RevertPendingActions DISM.exe /online /Cleanup-Image /RevertPendingActions
With this release, DISM also has the ability to check for component store corruption using the health commands. These commands are:
DISM.exe /online /Cleanup-Image /CheckHealth DISM.exe /online /Cleanup-Image /ScanHealth DISM.exe /online /Cleanup-Image /RestoreHealth
The CheckHealth flag checks to see if Windows has already detected a corruption marker on the component store that needs to be resolved based on the last /ScanHealth operation. If the corruption marker returns a value of healthy then there is not a corruption marker currently detected. If corruption is suspected and the /CheckHealth parameter is returning a value of healthy, the /ScanHealth command must be re-run to check for new corruption.
CHKDSK:
Physical hardware issues can cause issues that manifest themselves in the component store or during a servicing operation. CHKDSK is a well-known command line utility used to fix disk corruption. CHKDSK can be a useful tool to ensure that the underlying structures of the disk are not causing corruption in the component store. It is a good idea to run CHKDSK against a volume whenever other attempts to resolve servicing issues have resulted in no progress.
MEMTEST:
Similar to CHKDSK, the MEMTEST tool is an in-box command line tool used to check the validity of physical RAM on a system. Using this tool can be a good check to make sure that the physical resources on the machine are not causing corruption.
System Restore
System Restore is a well-known recovery tool included with client level operating systems. System restore reverts changes from a client version of Windows and is invoked online through the control panel or offline via the Windows Recovery Environment.
30