Friday, April 24, 2015

Restoring Corrupted Windows Components Detected When Performing SFC, DSIM, and System Update

Using the System File Checker tool (SFC) and the Deployment Image Servicing and Management tool (DISM), we may fix a corrupted Windows system or a corrupted Windows component store. However, there are some cases the tools would fail to fix the problems. In addition, when performing a Windows update, we may also experience some problem. This post documents how we may locate a problem and manually fix the problem. This post is complementary to other two posts.

When we use SFC to repair missing or corrupted system files, SFC may report that it could not fix some corrupted files. Below is an example, 

  C:\WINDOWS\system32>sfc /scannow

  Beginning system scan.  This process will take some time.

  Beginning verification phase of system scan.
  Verification 100% complete.

  Windows Resource Protection found corrupt files but was unable to fix some
  of them. Details are included in the CBS.Log windir\Logs\CBS\CBS.log. For
  example C:\Windows\Logs\CBS\CBS.log. Note that logging is currently not
  supported in offline servicing scenarios.

  C:\WINDOWS\system32>
In the above, the output of the SFC command contains, 

  Windows Resource Protection found corrupt files but was unable to fix 
  some of them.
which indicates obviously that some files are corrupted and unfortunately SFC cannot fix them for you. The first and an easy attempt to fix the issue, in my opinion, would be to run a DISM command, for instance, 

  C:\WINDOWS\system32>dism.exe /Online /Cleanup-Image /RestoreHealth

  Deployment Image Servicing and Management tool
  Version: 6.3.9600.17031

  Image Version: 6.3.9600.17031

  [==========================100.0%==========================]
  The restore operation completed successfully. The component store corruption was
  repaired.
  The operation completed successfully.

  C:\WINDOWS\system32>


Then, run SFC again. With good fortune, SFC may report that it can now fix the corrupted files, as demonstrated below, 

  C:\WINDOWS\system32>sfc /scannow

  Beginning system scan.  This process will take some time.

  Beginning verification phase of system scan.
  Verification 100% complete.

  Windows Resource Protection found corrupt files and successfully repaired
  them. Details are included in the CBS.Log windir\Logs\CBS\CBS.log. For
  example C:\Windows\Logs\CBS\CBS.log. Note that logging is currently not
  supported in offline servicing scenarios.

  C:\WINDOWS\system32>


However, when we use DISM to recover from a corrupted Windows component store, DISM may also report that it could not fix some corrupted component store.

Even if the above two yield no error, a Windows Update may still fail. For instance, when I attempt to apply the KB3000850 update to my Windows 8.1 system, I encountered an error -- the update appears to be applied correctly; however, when the system reboots, it complains that the update failed to be applied successfully and the system rolled back and undid the change.

There are three logs that we typically examine for clues to identify corrupted component or component store.
The procedure that we can use to locate and fix the problem is outlined in this post.

The procedure is a manual one. In this post, let us examine two example problems and the methods to fix them. The first example is to examine CBS.log to obtain clues and fixing strategies. The second example is to examine setupapi.dev.log for clues to fix the problem.

  1. Example 1. After the DISM command fails to the /RestoreHealth operation, we examine %WinDir%\Logs\CBS\CBS.log. By searching "Total Detected Corruption" in the log file, we would find the following logging message, 
    
Checking System Update Readiness.

(p) CSI Payload Corrupt   amd64_microsoft-windows-lddmcore_31bf3856ad364e35_6.3.9600.16438_none_9cc10b53b757a2be\dxgkrnl.sys
Repair failed: Missing replacement payload.
(p) CSI Payload Corrupt   amd64_microsoft-windows-lddmcore_31bf3856ad364e35_6.3.9600.16408_none_9ce17b17b73f4eeb\dxgkrnl.sys
Repair failed: Missing replacement payload.

Summary:
Operation: Detect and Repair 
Operation result: 0x0
Last Successful Step: Entire operation completes.
Total Detected Corruption: 2


    The message indicates that two files are corrupted. Both of the files happen to be two versions of dxgkrnl.sys. In this example, we demonstrate that we obtain a copy of the file from a Windows update manually. The CBS.log cites many Windows updates. It is infeasible to download all of them and see if the update contains a copy of the file. The method I used to locate the appropriate Windows update is to search the Windows version number. In this case, according to the message, the Windows version number is 6.3.9600.16438 in the first CSI Payload Corrupt message. We search "6.3.9600.16438 dxgkrnl.sys" using Google, as below, 
    
   https://www.google.com/search?q=6.3.9600.16438+dxgkrnl.sys
    From the search result, it appears that Windows Update KB2887595. We then locate the stand-alone update package of the Windows Update from the Windows Download Center. The search string I used to locate the Windows Update is "KB2887595 x64" since my Windows system is a 64-bit version of Windows 8.1. Having downloaded the stand-alone update package of the Windows Update, we will obtain the copy of the version of dxgkrnl.sys and replace the corrupted copy with the downloaded one using the steps as follows, assuming that the Window Update Windows8.1-KB2887595-v2-x64.msu is in directory C:\Temp, 
    
C:\Windows\System32>cd C:\Temp

C:\Temp>mkdir KB2887595

C:\Temp>expand -f:* Windows8.1-KB2887595-v2-x64.msu KB2887595 > nul

C:\Temp>cd KB2887595

C:\Temp\KB2887595>mkdir KB2887595CAB

C:\Temp\KB2887595>expand -f:* Windows8.1-KB2887595-v2-x64.cab KB2887595CAB > nul


C:\Temp\KB2887595>dir KB2887595CAB\amd64_microsoft-windows-lddmcore_31bf3856ad364e35_6.3.9600.16438_none_9cc10b53b757a2be
 Volume in drive C is Windows8_OS
 Volume Serial Number is 282A-6B47

 Directory of C:\Temp\KB2887595\KB2887595CAB\amd64_microsoft-windows-lddmcore_31bf3856ad364e35_6.3.9600.16438_none_9cc10b53b757a2be

04/25/2015  04:39 PM    <DIR>          .
04/25/2015  04:39 PM    <DIR>          ..
08/22/2013  08:36 AM           212,992 cdd.dll
10/19/2013  05:13 AM         1,530,200 dxgkrnl.sys
10/03/2013  10:07 AM           382,808 dxgmms1.sys
08/22/2013  02:44 AM             2,465 lddmcore.ptxml
               4 File(s)      2,128,465 bytes
               2 Dir(s)  127,155,011,584 bytes free

C:\Temp\KB2887595>


    Clearly, we have successfully obtained a good copy of the corrupted file. Now we simply to copy the file to its component store under %WinDir%\WinSxS as demonstrated below, 
    
C:\Temp>takeown /f "%windir%\winsxs" /a
C:\Temp>icacls "%windir%\winsxs" /grant:r *S-1-5-32-544:(OI)(CI)(F) /q
C:\Temp\KB2887595>copy KB2887595CAB\amd64_microsoft-windows-lddmcore_31bf3856ad364e35_6.3.9600.16438_none_9cc10b53b757a2be\dxgkrnl.sys %WinDir%\WinSxS\amd64_microsoft-windows-lddmcore_31bf3856ad364e35_6.3.9600.16438_none_9cc10b53b757a2be
Overwrite C:\WINDOWS\WinSxS\amd64_microsoft-windows-lddmcore_31bf3856ad364e35_6.3.9600.16438_none_9cc10b53b757a2be\dxgkrnl.sys? (Yes/No/All): a

        1 file(s) copied.

C:\Temp\KB2887595>


    Similarly, we can conduct a web search for the second corrupted file via Google as follows, 
    
   https://www.google.com/search?q=6.3.9600.16408+dxgkrnl.sys

    From the search we learn that we could locate the file in the Windows Update KB2883200. Following the same procedure, we can replace the corrupted file with a good copy.
  2. Example 2. The second example is to resolve the update failure problem when I tried to apply the KB300850 update. Examining %WinDir%\Inf\setupapi.dev.log, I found the following messages, 
    
     sto: {Publish Driver Package: C:\WINDOWS\System32\DriverStore\FileRepository\wiaek002.inf_amd64_5b5a15ef9a58384c\wiaek002.inf} 07:54:15.316
     sto:      Driver Package = wiaek002.inf_amd64_5b5a15ef9a58384c
     idb:      {Publish Driver Package: C:\WINDOWS\System32\DriverStore\FileRepository\wiaek002.inf_amd64_5b5a15ef9a58384c\wiaek002.inf} 07:54:15.316
     idb:           Changing active driver package from 'wiaek002.inf_amd64_57f9361b96ceea4b' to 'wiaek002.inf_amd64_5b5a15ef9a58384c'.
     cpy:           Unpublished 'wiaek002.inf'.
!    inf:           Unable to load INF: 'C:\WINDOWS\System32\DriverStore\FileRepository\wiaek002.inf_amd64_57f9361b96ceea4b\wiaek002.inf'(00000003)
!    inf:           Error 3: The system cannot find the path specified.
!!!  inf:           Failed to open INF file "C:\WINDOWS\System32\DriverStore\FileRepository\wiaek002.inf_amd64_57f9361b96ceea4b\wiaek002.inf". Error = 0x00000003, Line = 0
!!!  sto:           Failed to get driver package file list. Error = 0x00000003, Filename = C:\WINDOWS\System32\DriverStore\FileRepository\wiaek002.inf_amd64_57f9361b96ceea4b\wiaek002.inf
!!!  idb:           Failed to update driver package files for 'wiaek002.inf_amd64_57f9361b96ceea4b'. Error = 0x00000003
!!!  idb:           Failed to publish 'C:\WINDOWS\System32\DriverStore\FileRepository\wiaek002.inf_amd64_5b5a15ef9a58384c\wiaek002.inf'. Error = 0x00000003
     idb:      {Publish Driver Package: exit(0x00000003)} 07:54:15.316
!!!  sto:      Failed to publish driver package. Error = 0x00000003
     sto: {Publish Driver Package: exit(0x00000003)} 07:54:15.316
    From the messages, we can learn that the wiaek002.inf file failed to be published in directory C:\WINDOWS\System32\DriverStore\FileRepository\wiaek002.inf_amd64_5b5a15ef9a58384c\wiaek002.inf

    Following the observation, we manually "publish" the driver. 
    
      mkdir C:\WINDOWS\System32\DriverStore\FileRepository\wiaek002.inf_amd64_5b5a15ef9a58384c
      copy C:\WINDOWS\Inf\wiaek002.inf C:\WINDOWS\System32\DriverStore\FileRepository\wiaek002.inf_amd64_5b5a15ef9a58384c\wiaek002.inf

    Then we reapply the KB300850 update again. In my case, it is a success.
Posted by at
Labels: , ,

4 comments:

Subscribe to: Post Comments (Atom)