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.
-
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.
-
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.
