Home error repair troubleshooting windows

Troubleshooting CheckSUR.log Errors: A Step-by-Step Guide for Windows Client Users

Updated: • 0 • min read
Table of Contents

When facing issues with Windows Updates or other system stability problems on older Windows versions like Vista or Windows 7, the System Update Readiness Tool (CheckSUR) is often a critical utility. This tool scans for inconsistencies in the Windows servicing store and attempts to repair them. Understanding the CheckSUR.log file is paramount to diagnosing and resolving persistent system corruption errors. This log file provides detailed output about the inconsistencies found and the tool’s success or failure in fixing them. Analyzing its content allows users to pinpoint specific issues and take targeted actions to restore system health.

Troubleshooting CheckSUR.log Errors

The CheckSUR.log file is typically located in the %SYSTEMROOT%\Logs\CBS\ directory. It records the entire process of the CheckSUR tool execution, detailing which components were checked, what errors were detected, and which errors were successfully repaired. A thorough review of this log is the first step in understanding the nature of the servicing corruption affecting the system. Different sections of the log highlight various types of errors, each requiring a specific approach for resolution. It’s important to always examine the “Summary” section at the end of the log to get an overview of the tool’s findings and actions.

Understanding CheckSUR.log Results

The output within the CheckSUR.log provides clear indicators of the system’s state and the actions taken by the tool. The “Summary” section offers a quick snapshot of the execution time, the number of errors found, and crucially, the number of errors fixed. Based on this summary and other detailed entries, users can determine if the tool was fully successful or if manual intervention is required. Each scenario described in the log provides valuable diagnostic information necessary for subsequent troubleshooting steps.

Scenario 1: CheckSUR Fixed All Detected Errors

The most favorable outcome when running CheckSUR is that the tool successfully identifies and repairs all inconsistencies it finds. When this happens, the CheckSUR.log summary reflects a complete resolution. You will see the “Found errors” count matching the “Fixed errors” count. This indicates that the servicing store corruption detected by CheckSUR has been successfully repaired automatically.

The “Summary” section in the log will display output similar to this example:

Summary:
Seconds executed: 100
Found 10 errors
Fixed 10 errors

In this positive scenario, the core servicing corruption issues that CheckSUR is designed to handle should no longer be present on your computer. The system’s ability to install updates or perform other servicing operations should be restored. However, if you were using CheckSUR to troubleshoot a specific problem (like a failed Windows Update or a system feature not working), and that problem persists, it suggests the root cause might lie outside of servicing store corruption that CheckSUR can fix. In such cases, you would need to investigate the specific error message or symptom you are experiencing, potentially using other diagnostic tools or troubleshooting methods specific to that issue. CheckSUR’s job on servicing store issues is complete, allowing you to focus on other potential problem areas.

Scenario 2: Identifying and Resolving ‘Unavailable repair files’

A common issue encountered when running CheckSUR is the Unavailable repair files message. This indicates that the tool found inconsistencies, specifically related to package files (.mum, .cat, and sometimes .manifest files), but could not fix them because the necessary replacement files were not available in its local cache or on the system. These files are crucial for verifying and installing updates and components. Without the correct versions of these files, CheckSUR cannot complete the repair process for the identified corruption.

When faced with this issue, the CheckSUR.log will list the specific missing files under the Unavailable repair files: section. The summary might show errors found, but the “Fixed errors” count will be lower or zero for this category. Additionally, specific error counts like CBS MUM Missing Total Count might appear, detailing the types of missing package files.

The log output will look similar to this example, listing the files the tool needs but cannot find:

Summary:
Seconds executed: 264
Found 3 errors
CBS MUM Missing Total Count: 3
Unavailable repair files:

servicing\packages\Package_for_KB958690_sc_0~31bf3856ad364e35~amd64~~6.0.1.6.mum
servicing\packages\Package_for_KB958690_sc~31bf3856ad364e35~amd64~~6.0.1.6.mum
servicing\packages\Package_for_KB958690~31bf3856ad364e35~amd64~~6.0.1.6.mum
servicing\packages\Package_for_KB958690_sc_0~31bf3856ad364e35~amd64~~6.0.1.6.cat
servicing\packages\Package_for_KB958690_sc~31bf3856ad364e35~amd64~~6.0.1.6.cat
servicing\packages\Package_for_KB958690~31bf3856ad364e35~amd60.1.6.cat
winsxs\manifests\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.0.6002.18005_none_0b4ada54c46c45b0.manifest
winsxs\manifests\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_6.0.6002.18005_none_676975d87cc9b6e6.manifest

Step-by-Step Resolution for ‘Unavailable repair files’

Resolving this issue requires manually providing CheckSUR with the missing files. The tool is designed to look for these files in a specific location within its own directory structure. By placing the correct files there, you allow CheckSUR to complete the repairs it couldn’t perform initially. The process involves identifying the source of the missing files, obtaining them, and placing them in the designated folders.

Here are the steps to follow:

  1. Identify the Source Package: Examine the list of Unavailable repair files in the log. The filenames often contain clues about the update package (KB number) they belong to. For example, files containing KB958690 likely come from the update package for KB958690. Note the KB number and the architecture (amd64 or x86) mentioned in the filenames.
  2. Download the Required Package: Once you’ve identified the KB number and architecture, search the Microsoft Update Catalog website or the Microsoft Download Center for the corresponding update package. For the example above, you would search for “KB958690 x64” to find the “Windows6.0-KB958690-x64.msu” file (for Windows Vista 64-bit). Download the correct .msu or .cab file that contains the listed missing files.
  3. Extract and Place Package Files (.mum, .cat): Create a new folder named Packages inside the %SYSTEMROOT%\CheckSUR\ directory on the affected computer. Copy the downloaded .msu or .cab file into this %SYSTEMROOT%\CheckSUR\Packages\ folder. Do not extract the file yourself; CheckSUR will extract the necessary .mum and .cat files from the package when you rerun it. The tool is designed to look for .msu or .cab files placed directly into this folder.
  4. Obtain and Place Manifest Files (.manifest): If the log also lists missing .manifest files (found under winsxs\manifests\), you need to obtain these separately. The source package (.msu/.cab) usually doesn’t contain these manifest files directly in an easily accessible format. The most reliable way to get these is from a working computer running the exact same version of the operating system, including service pack level, and the same system architecture (x86 or x64).
  5. Copy Manifest Files: On the working computer, navigate to the %WinDir%\winsxs\manifests\ folder. Search for the manifest files listed as missing in your CheckSUR.log. Copy these specific .manifest files to a portable drive.
  6. Place Manifest Files: On the corrupted computer, create a new folder named Manifests inside the %SYSTEMROOT%\CheckSUR\ directory (i.e., %SYSTEMROOT%\CheckSUR\Manifests). Copy the .manifest files you obtained from the working computer into this %SYSTEMROOT%\CheckSUR\Manifests\ folder. Ensure the folder structure is correct: packages go in Packages, manifests go in Manifests.
  7. Rerun CheckSUR: After placing the missing package files (.msu or .cab) and manifest files (.manifest) in their respective locations (%SYSTEMROOT%\CheckSUR\Packages and %SYSTEMROOT%\CheckSUR\Manifests), rerun the CheckSUR tool. It should now find the necessary files you provided and use them to fix the inconsistencies reported previously.
  8. Verify Fixes: After the second run, check the CheckSUR.log again. The Unavailable repair files section should ideally be gone or significantly reduced. The “Summary” should show more errors fixed this time. If CheckSUR still reports missing files, repeat the process for any remaining items in the Unavailable repair files list.

This manual process effectively provides CheckSUR with the components it needs to repair the corrupted servicing store, overcoming the limitation of not having these files readily available. It’s a powerful technique for resolving stubborn update and component installation failures tied to servicing corruption. The key is accurately identifying the missing files and sourcing them from a matching system or official distribution channels.

Scenario 3: Addressing ‘Payload File Missing’ Errors

Another distinct type of error reported by CheckSUR is CSI Payload File Missing. This error indicates that the tool found references to a required binary file (like a .dll, .exe, or other system file) within the servicing store that should be present on the system, but the actual file is missing or corrupted at its expected location. These are not package or manifest files, but the core components of Windows itself. Unlike the ‘Unavailable repair files’ scenario where CheckSUR just needs the package to extract needed metadata, here the actual final binary file is missing from its installation location, usually within the winsxs (Side-by-Side) directory. CheckSUR can often detect this but may not always be able to fix it automatically, especially if the necessary replacement binary isn’t readily available or if the corruption is extensive.

When CSI Payload File Missing errors occur and CheckSUR cannot fix them, the log will list these specific files. The log entry will usually show the filename, the component it belongs to, and potentially some hexadecimal codes. Entries marked with (f) indicate a file was found missing, while entries marked with (fix) indicate CheckSUR attempted and possibly succeeded in fixing that specific instance.

The log output for this scenario might look like this example, showing missing payload files:

Summary:
Seconds executed: 100
Found 3 errors
Fix 1 errors
CSI Payload File Missing Total count: 3
Fix CSI Payload File Missing Total Count: 1

(f) CSI Payload File Missing 0x00000000 admparse.dll x86_microsoft-windows-ie-adminkitmostfiles_31bf3856ad364e35_6.0.6000.16386_none_abfb5fd109dad8b8 servicing_31bf3856ad364e35_6.0.6000.16386_none_23ddbf36a8a961bc
(f) CSI Payload File Missing 0x00000000 bootmgr x86_microsoft-windows-b..re-bootmanager-pcat_31bf3856ad364e35_6.0.6000.16386_none_c0f2f087b6457236
(fix) CSI Payload File Missing 0x00000000 bootmgr x86_microsoft-windows-b..re-bootmanager-pcat_31bf3856ad364e35_6.0.6000.16386_none_c0f2f087b6457236
(f) CSI Payload File Missing 0x00000000 winload.exe x86_microsoft-windows-b..environment-windows_31bf3856ad364e35_6.0.6000.16386_none_6701d52e8fdf8d45

In this example, admparse.dll and winload.exe are listed with (f) but no corresponding (fix), meaning CheckSUR found them missing but couldn’t replace them. bootmgr was found missing and CheckSUR attempted a fix, indicated by the (fix) line immediately following the (f) line for that file.

Step-by-Step Resolution for ‘Payload File Missing’

Fixing missing payload files requires manually replacing the corrupted or absent files with healthy copies. This process is more involved than replacing package files because the files need to be placed in their exact required location within the complex winsxs directory structure. Sourcing the correct version of the file from a matching system is crucial.

Follow these steps to resolve CSI Payload File Missing errors:

  1. Identify Unfixed Missing Files: Carefully examine the CheckSUR.log for CSI Payload File Missing entries. Look for lines starting with (f) that do not have a corresponding (fix) entry immediately following them for the same file and component. These are the files that CheckSUR could not repair. In the example above, admparse.dll and winload.exe are unfixed missing payload files.
  2. Identify the Target Location: Each missing file entry in the log includes the component name (e.g., x86_microsoft-windows-ie-adminkitmostfiles_31bf3856ad364e35_6.0.6000.16386_none_abfb5fd109dad8b8). This component name corresponds to a specific folder within the %WinDir%\winsxs\ directory. This is where the missing binary file should reside. The format is [architecture]_[component_name]_[public_key]_[version]_[language]_[checksum]. You need to find the folder matching this full name under winsxs.
  3. Source the Correct Files: Obtain the missing binary files (.dll, .exe, etc.) from another working computer. It is absolutely critical that the source computer is running the exact same version of the operating system (including Service Pack level) and the same system architecture (x86 or x64) as the affected computer. Minor version differences or different architectures can lead to system instability or failure.
  4. Locate Files on Source System: On the working source computer, navigate to %WinDir%\winsxs\. You may need to take ownership and grant yourself permissions to access these folders. Search for the folder matching the full component name identified in step 2. Inside this folder, you should find the binary file listed as missing in the CheckSUR.log.
  5. Copy Files to Target System: Copy the identified missing files from the source computer to a portable drive. On the affected computer, navigate to the corresponding location within %WinDir%\winsxs\. Find or recreate the exact component folder identified in step 2. You may again need to adjust permissions to write to this location. Paste the copied files into this specific component folder.
  6. Verify File Placement: Double-check that the copied files are placed in the correct winsxs subfolder matching the component name from the log. Ensure the file names match exactly.
  7. Rerun CheckSUR (Optional but Recommended): While manually placing the files might resolve the issue, rerunning CheckSUR after placing the files can help verify that the servicing store now correctly registers the presence of the files and that no other related inconsistencies exist. The subsequent log should show the previous (f) entries now either gone or potentially marked with (fix) if CheckSUR re-evaluates the component.
  8. Check System Stability: After replacing the files and optionally rerunning CheckSUR, check if the original problem (Windows Update errors, system feature issues) is resolved. If other CSI Payload File Missing errors remain, repeat the process for those files.

Manually placing files into the winsxs directory is an advanced troubleshooting step and requires extreme caution. Incorrectly placed or mismatched files can severely damage the operating system. Always ensure you are using files from an identical system configuration. This method directly addresses the physical absence of required system binaries that CheckSUR reported but could not autonomously replace.

General Troubleshooting Tips

Before relying solely on manual fixes derived from CheckSUR.log, consider these preparatory and follow-up steps:

  • Run SFC (System File Checker): Before running CheckSUR, run sfc /scannow from an elevated Command Prompt. SFC attempts to repair protected Windows system files. Sometimes, the issues CheckSUR reports stem from file corruption that SFC might be able to fix more directly.
  • Check Disk Health: File corruption can be a symptom of underlying hard drive issues. Run a check disk utility (chkdsk /f /r) to scan for and potentially repair disk errors that might be causing files to become corrupted or inaccessible.
  • Ensure Windows Update is Working: After addressing errors found in CheckSUR.log, attempt to run Windows Update again. If the servicing store is repaired, updates that previously failed might now install successfully.
  • Consider System Restore: If problems persist after extensive troubleshooting with CheckSUR and manual file replacement, a System Restore point created before the issues began might be an option, though this will undo other changes made since the restore point.
  • Antivirus Scan: Ensure your system is free of malware, as some infections can corrupt system files.

Summary Table of CheckSUR.log Errors and Solutions

Understanding the log output is key to selecting the right troubleshooting path. This table summarizes the common error types discussed and their corresponding general solutions:

Log Entry Type Indication Files Involved CheckSUR Fixes Automatically? Typical Manual Solution
All Errors Fixed Servicing corruption found and repaired. Various Yes No manual steps needed based on log; troubleshoot other issues if necessary.
Unavailable repair files Missing package/metadata files prevent repair. .mum, .cat, .manifest No Download update packages (.msu/.cab), copy to %SYSTEMROOT%\CheckSUR\Packages\. Copy .manifest from matching system to %SYSTEMROOT%\CheckSUR\Manifests\. Rerun CheckSUR.
CSI Payload File Missing Missing or corrupted binary system files. .dll, .exe, other binaries Sometimes (indicated by (fix)) Identify unfixed files in log. Copy the exact files from the exact same path (winsxs) on a matching system to the corrupted system.

Visualizing the Troubleshooting Process

Understanding the flow of analyzing the log and taking action can be helpful. Here is a simple diagram outlining the process:

mermaid graph TD A[Run CheckSUR Tool] --> B{Examine CheckSUR.log}; B --> C{Look at Summary}; C --> D{Found = Fixed?}; D -- Yes --> E[Servicing Corruption Fixed]; E --> F[Test System / Rerun WU]; D -- No --> G{Check Specific Errors}; G --> H{Unavailable repair files?}; H -- Yes --> I[Identify Missing Packages/Manifests]; I --> J[Download/Copy Missing Files]; J --> K[Place Files in CheckSUR Folders]; K --> A; %% Rerun CheckSUR H -- No --> L{CSI Payload File Missing?}; L -- Yes --> M[Identify Unfixed Missing Binaries]; M --> N[Source Files from Matching System]; N --> O[Copy Files to Correct winsxs Paths]; O --> P[Verify File Placement]; P --> A; %% Rerun CheckSUR (Optional but recommended) G -- No --> Q[Troubleshoot Other Errors/Symptoms]; F --> R{Problem Resolved?}; R -- Yes --> S[Done]; R -- No --> Q; A --> B; %% Re-analyze log after fixes

This diagram illustrates the iterative nature of troubleshooting with CheckSUR. You run the tool, analyze the log, perform manual steps based on the errors, and then potentially rerun the tool and re-analyze the log until all servicing-related issues are resolved or identified as outside the scope of CheckSUR.

Successfully troubleshooting CheckSUR.log errors involves careful log analysis, precise file handling, and sourcing files from reliable, matching systems. By understanding what each error message signifies and following the detailed steps outlined, users can effectively repair servicing store corruption and restore their Windows client’s functionality.

Have you encountered these specific CheckSUR.log errors? Share your experiences or ask questions in the comments below!

Post a Comment