How to read a CBS log

Where it lives

The current log is %windir%\Logs\CBS\CBS.log. When it grows past its size limit Windows rolls it into CbsPersist_<timestamp>.log in the same folder, and older ones get compressed. If your failure happened more than a day or two ago, the evidence is in a CbsPersist file, not in CBS.log.

Both need administrator rights to read, and the file is locked while servicing is running. Copy it somewhere else before you start poking at it.

The format, by column

CBS lines are fixed width. This matters more than it sounds, because most scripts that try to parse these logs split on whitespace and get it wrong.

2026-08-19 14:53:44, Info                  CBS    TI: --- Initializing Trusted Installer ---
|                    |                     |      |
0                    21                    43     50

cols  0-18   timestamp
cols 19-20   ", "
cols 21-42   level, space padded
cols 43-49   component, space padded, and often empty
cols 50+     message

Two consequences worth knowing. First, the message text is full of commas, so splitting the line on , or on runs of whitespace produces nonsense: words from the message get read as component names. Second, a large share of lines have no component at all. In a healthy 82,776 line CBS.log I measured, 17,650 lines had an empty component field. They are continuation detail belonging to the operation above them.

Levels

Three: Info, Warning, and Error. The vast majority is Info. In that same healthy log there were five warnings and zero errors across 82,776 lines, which tells you how much noise you are searching through.

Components

The ones you will actually see are CBS (the servicing stack itself), CSI (the component store interface, where file and manifest level failures surface), SXS (side by side assemblies), and DISM if you are looking at dism.log, which uses the identical format.

The three searches

1. Find the failures

Select-String -Path C:\Windows\Logs\CBS\CBS.log -Pattern ", error" -Context 0,3

The comma matters. Searching for the bare word error matches thousands of harmless lines that merely contain the word. , error matches the level field, which is the actual failure marker.

2. Find CSI failures

CSI marks a failed operation with (F) before the status. Those lines are often more specific than the CBS error that follows them, because CSI names the file or manifest.

Select-String -Path C:\Windows\Logs\CBS\CBS.log -Pattern "\(F\)"

3. Match on the timestamp

Once you have the failure, note its timestamp and read everything within a few seconds either side. This is where the answer usually is, and it is the step people skip.

Why the error line is not the answer

This is the part worth internalising. A CBS error line gives you a code and a component. It almost never names the object that was refused. The lines above it name the file, the registry key, or the manifest that servicing was working on when it failed.

So the workflow is not "find the error code and search it". The workflow is: find the error line, read upward until you find the object, then decide whether the problem is permissions on that object, corruption of that object, or that object being missing. The code only tells you which of those three categories you are in.

Codes you will meet

• 0x800f081f, source files not found. Component store corruption, or a device that cannot reach a payload source.
• 0x800f0831, store corruption. Read the log for the KB it names, because it usually points at a specific missing manifest.
• 0x80070005, access denied. The log names the object that was denied, which is the only useful part.
• 0x80073712, component store corrupt. Usually needs a repair source rather than an online repair.

Or skip the reading

The log analyzer does all of the above in your browser: it splits the file by column so components come out right, pulls every error and warning, shows the lines above and below each one, and explains the codes it finds. The file is never uploaded, which is the point, because a CBS log is full of device names and internal paths.

Open the log analyzer