Windows 10 update error 0x80070005 caused by NTFS corruption in C:\Windows\INF

This guide describes a specific Windows Update failure we encountered on Windows 10 22H2.

The update repeatedly failed with:

0x80070005
E_ACCESSDENIED
Access Denied

The affected update in this case was:

2026-09 Cumulative Update for Windows 10 Version 22H2 for x64-based Systems
KB5122878

The important point is that 0x80070005 was not itself the diagnosis.

It was only the error Windows returned after a lower-level operation failed.

Several common explanations were investigated first. They did not solve the problem.

These included:

• retrying Windows Update normally
• manually installing the update
• rebuilding the Windows Update cache
• disabling Bitdefender
• completely uninstalling Bitdefender and trying again
• checking Administrator access
• checking the affected file permissions
• checking TrustedInstaller
• checking Windows servicing
• investigating firmware and Secure Boot because the affected file was named c_firmware.inf

None of those resolved the update failure.

The breakthrough came from stopping the generic troubleshooting and finding the exact operation that was producing 0x80070005.

The investigation went:

Windows Update failure
        ↓
CBS.log
        ↓
c_firmware.inf identified
        ↓
SetupAPI.dev.log
        ↓
Windows could not replace C:\Windows\INF\c_firmware.inf
        ↓
permissions checked and found to be normal
        ↓
CHKDSK
        ↓
NTFS directory/index corruption found in C:\Windows\INF
        ↓
offline CHKDSK repair
        ↓
update installed successfully

The purpose of this guide is therefore not:

Got 0x80070005? Run CHKDSK.

That would be just another generic fix.

The purpose is to determine whether your machine has the same or a closely related fault before repairing anything.

Every command in this guide is intended to be run in:

Windows PowerShell

with:

Administrator rights

Do not use a normal non-elevated PowerShell window.

Do not switch to Command Prompt.

There is no Command Prompt-only command in the main procedure.

Native Windows utilities such as:

chkdsk.exe
DISM.exe
icacls.exe
fsutil.exe

can be launched directly from PowerShell.

Click Start and type:

powershell

Right-click:

Windows PowerShell

and choose:

Run as administrator

A PowerShell prompt normally looks similar to:

PS C:\Windows\system32>

The title bar should indicate that the session is running as Administrator.

All commands below should be entered into that Administrator PowerShell window unless this guide explicitly states otherwise.

Do not start changing permissions or repairing Windows simply because Windows Update says that an update failed.

First establish the actual error.

If Windows Update reports:

0x80070005

continue with the investigation below.

The Windows error name normally associated with this value is:

E_ACCESSDENIED

However, that still does not tell us what Windows was denied access to.

That is what we need to discover.

Still in Administrator PowerShell, run:

Select-String -Path "$env:windir\Logs\CBS\CBS.log" -Pattern '80070005','E_ACCESSDENIED','Access is denied'

CBS stands for Component Based Servicing.

This is one of the primary logs used by the Windows servicing system while installing Windows updates.

You may receive many results.

We are interested in lines around the time the update failed and particularly anything identifying:

an INF file
a driver operation
a package
a registry object
a directory
a file

In our case CBS contained:

Doqe: Recording result: 0x80070005, for Inf: c_firmware.inf

followed by:

DriverUpdateInstallUpdates failed [HRESULT = 0x80070005 - E_ACCESSDENIED]

and:

Doqe: Failed installing driver updates

and:

Failed installing driver updates

CBS subsequently showed the Driver Operations Queue failing while processing the update.

That changed the investigation substantially.

The failure was no longer simply:

Windows Update gives Access Denied

It was now:

Windows servicing is returning Access Denied while processing c_firmware.inf.

If CBS identifies:

c_firmware.inf

continue exactly as below.

If CBS identifies another .inf file while showing a similar Driver Operations Queue failure, this procedure may still be relevant.

Examples might look like:

Doqe: Recording result: 0x80070005, for Inf: something.inf

or:

DriverUpdateInstallUpdates failed [HRESULT = 0x80070005 - E_ACCESSDENIED]

with a particular INF package immediately associated with the failure.

In that situation, substitute your INF filename for c_firmware.inf in the later searches.

If CBS instead shows that 0x80070005 originates from something completely different, such as a registry operation, another directory, a service, a package operation unrelated to driver publishing, or another identifiable object, stop following this particular fix.

Your 0x80070005 probably has a different cause.

The useful next step in that situation is to analyse the log rather than randomly applying fixes.

For example, you could give the relevant CBS section to ChatGPT and ask:

Windows Update is failing with 0x80070005. Read these CBS log lines and identify the first operation that actually fails. Do not give me generic Windows Update fixes. Identify the file, registry key, driver, package or servicing operation that originally produced the error, and distinguish that from later operations that merely repeat or inherit the same HRESULT.

CBS gave us the filename:

c_firmware.inf

The next question was therefore:

What exactly happened when Windows tried to process c_firmware.inf?

Windows records detailed driver and INF installation activity in:

C:\Windows\INF\setupapi.dev.log

Still in Administrator PowerShell, run:

Select-String -Path "$env:windir\INF\setupapi.dev.log" -Pattern 'c_firmware.inf'

If CBS identified another INF, replace the filename accordingly.

For example:

Select-String -Path "$env:windir\INF\setupapi.dev.log" -Pattern 'whatever.inf'

In our case SetupAPI showed that Windows could successfully stage the replacement package.

Windows had the newer file available from WinSxS and DriverStore.

The problem occurred when it tried to replace the published copy in:

C:\Windows\INF

The critical entry was:

Unable to delete existing file 'C:\Windows\INF\c_firmware.inf' before creating hardlink. Error = 0x00000005

followed by:

Failed to publish 'c_firmware.inf_amd64_...\c_firmware.inf' to 'c_firmware.inf'. Error = 0x00000005

and:

Failed to publish 'C:\Windows\System32\DriverStore\FileRepository\...\c_firmware.inf'. Error = 0x00000005

Windows attempted that operation repeatedly and failed at the same point.

Later attempts produced the same failure pattern again.

This was extremely important.

Windows was not failing to download the file.

It was not failing to stage the file.

It was failing when trying to remove the existing published INF before creating the replacement hardlink.

You do not necessarily need to see the exact filename:

c_firmware.inf

A potentially similar fault would be SetupAPI repeatedly reporting something like:

Unable to delete existing file 'C:\Windows\INF\something.inf' before creating hardlink.

with:

Error = 0x00000005

or:

Failed to publish ...
Error = 0x00000005

or a pattern where:

1. Windows successfully stages an INF package.
2. Windows begins switching from the previous INF package to the newer one.
3. Windows attempts to remove or replace the published INF under C:\Windows\INF.
4. That operation fails with 0x00000005.
5. Windows rolls the operation back.
6. Windows repeats the same sequence during later update attempts.

That is substantially more specific than simply seeing:

0x80070005

At this point an Access Denied error naturally suggests file permissions.

That possibility should be checked before assuming filesystem corruption.

Still using Administrator PowerShell:

icacls.exe "$env:windir\INF\c_firmware.inf"

In our case the file showed permissions including:

NT SERVICE\TrustedInstaller:(F)
NT AUTHORITY\SYSTEM:(F)
BUILTIN\Administrators:(RX)

TrustedInstaller therefore had Full Control.

SYSTEM also had Full Control.

Administrators had the expected read and execute access.

Check the file owner with:

(Get-Acl "$env:windir\INF\c_firmware.inf").Owner

Our file was owned by:

NT SERVICE\TrustedInstaller

That is normal for this type of protected Windows system file.

Run:

icacls.exe "$env:windir\INF\c_firmware.inf" /verify

In our case this completed successfully.

That meant there was no obvious malformed security descriptor explaining why SetupAPI could not replace the file.

Run:

Get-Item "$env:windir\INF\c_firmware.inf" -Force | Select-Object FullName,Attributes

The file was not simply marked read-only in a way that explained the failure.

Run:

Get-Service TrustedInstaller | Select-Object Name,Status,StartType

In our case TrustedInstaller was running.

Again, that removed another obvious explanation.

This was relevant because SetupAPI specifically said it was trying to create a hardlink.

Run:

fsutil.exe hardlink list "$env:windir\INF\c_firmware.inf"

Our file was linked to the expected Windows locations, including the DriverStore package and WinSxS.

The existing DriverStore copy was:

C:\Windows\System32\DriverStore\FileRepository\c_firmware.inf_amd64_36e4e17f210128ab\c_firmware.inf

We also checked that the files actually referred to the same NTFS file record.

PowerShell can invoke FSUTIL for that as well:

fsutil.exe file queryfileid "$env:windir\INF\c_firmware.inf"

and then:

fsutil.exe file queryfileid "$env:windir\System32\DriverStore\FileRepository\c_firmware.inf_amd64_36e4e17f210128ab\c_firmware.inf"

In our case the file IDs matched.

That meant the hardlink relationship itself appeared consistent.

Before blaming NTFS, we also checked whether the Windows component store itself was corrupt.

Run from the same Administrator PowerShell window:

DISM.exe /Online /Cleanup-Image /ScanHealth

Our result was:

No component store corruption detected.
The operation completed successfully.

So DISM did not find component-store corruption.

That is significant because the problem was eventually found somewhere lower down.

The Windows servicing components themselves were intact.

The filesystem metadata beneath them was not.

This was the decisive diagnostic step.

Still in Administrator PowerShell, run:

chkdsk.exe C: /scan

/scan performs an online NTFS scan.

Windows remains running while the scan takes place.

Do not skip over the detailed output just because CHKDSK reaches the end.

Look for references to:

C:\Windows\INF

your affected INF filename, or filesystem structures such as:

$I30
unindexed
lost file
orphan
reconnection
index
directory

CHKDSK found filesystem metadata corruption directly involving the same area SetupAPI had been failing to modify.

It first reported:

Found an unindexed link ($FILE_NAME: "C_FIRM~1.PNF") in index "$I30" of directory "\Windows\INF"

and repaired that portion online.

More importantly it subsequently reported:

Found lost file "\Windows\INF\c_firmware.inf"

and:

requesting reconnection to index "$I30" of directory "\Windows\INF"

This was the crucial connection.

SetupAPI had been saying:

I cannot delete and replace C:\Windows\INF\c_firmware.inf.

CHKDSK was independently saying:

The NTFS directory/index information involving C:\Windows\INF\c_firmware.inf is damaged.

At that point 0x80070005 stopped looking like an ordinary ACL permissions error.

The filesystem's own metadata describing the file and its directory entry was inconsistent.

On NTFS, directories are indexed structures.

$I30 is associated with the directory index used to keep track of filenames and their directory entries.

So when CHKDSK reports problems such as:

unindexed link

or:

lost file

and names:

$ I30

in the same directory where SetupAPI cannot delete or replace a file, that is highly relevant.

The file can physically exist.

Its permissions can look completely normal.

TrustedInstaller can own it.

Its hardlinks can appear correct.

Yet corrupted directory/index metadata can still prevent Windows from manipulating that file correctly.

That is effectively what happened here.

At this stage the evidence is strong if your machine shows a combination similar to this:

Windows Update
0x80070005

plus CBS showing:

Driver Operations Queue
INF-related failure
E_ACCESSDENIED

plus SetupAPI showing:

Unable to delete existing file
before creating hardlink
Error = 0x00000005

or:

Failed to publish
Error = 0x00000005

plus CHKDSK finding:

index corruption
unindexed entries
lost files
orphaned entries
$I30 errors

in:

C:\Windows\INF

especially where CHKDSK identifies the same INF involved in the SetupAPI failure.

That is the point at which this repair becomes justified.

If CHKDSK says:

Windows has scanned the file system and found no problems.
No further action is required.

then you have not reproduced the filesystem fault we found.

Do not pretend that you have.

Return to the servicing logs and investigate the actual failing object.

This is precautionary.

It does not repair the fault.

Because we are about to perform an offline filesystem repair, having a current restore point is sensible.

You can open System Protection directly from Administrator PowerShell with:

SystemPropertiesProtection.exe

This does not change shell.

You are still using PowerShell.

It simply opens the Windows System Protection graphical interface.

Select the system drive, normally:

C:

and create a restore point.

A useful name would be:

Before CHKDSK Repair

Once it reports that the restore point was successfully created, close the System Protection window.

You are now back at your existing:

Administrator PowerShell

window.

No Command Prompt has been opened.

Return to the Administrator PowerShell window.

Run:

chkdsk.exe C: /f

Because C: is the active Windows system volume, CHKDSK cannot obtain exclusive access to it while Windows is running.

It should therefore ask whether the volume should be checked during the next restart.

Answer:

Y

and press Enter.

You can restart directly from the same Administrator PowerShell session:

Restart-Computer

The computer will restart.

Windows should run CHKDSK before the normal operating system startup completes.

Allow it to finish.

Do not interrupt it.

Do not force the computer off.

Once back at the Windows desktop:

open Windows PowerShell as Administrator again.

This is important because the PowerShell session used before restarting no longer exists.

From this point onward we are again using:

Administrator PowerShell

Run:

chkdsk.exe C: /scan

On our repaired system the result was:

Windows has scanned the file system and found no problems.
No further action is required.

It also reported:

0 KB in bad sectors

That confirmed that CHKDSK no longer detected the directory/index corruption.

At this point retry the update normally through Windows Update if Windows has not already resumed it automatically.

In our case KB5122878 subsequently installed successfully.

The same update that had repeatedly failed while the C:\Windows\INF index was damaged now completed normally.

Return to Administrator PowerShell.

For our particular update:

Get-HotFix -Id KB5122878 -ErrorAction SilentlyContinue

Our machine subsequently showed KB5122878 as installed.

You can also check the Windows build:

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
    Select-Object CurrentBuild,UBR

After the successful installation our Windows 10 system reported:

CurrentBuild : 19045
UBR          : 7725

That corresponds to:

19045.7725

The conclusion does not come merely from CHKDSK finding an unrelated error.

There is a direct sequence of evidence.

Before repair:

KB5122878 repeatedly failed

with:

0x80070005

CBS then identified:

c_firmware.inf

as the INF involved when the Driver Operations Queue failed.

SetupAPI independently showed that Windows could stage the replacement package but failed when attempting to delete:

C:\Windows\INF\c_firmware.inf

before creating the replacement hardlink.

The normal ACL permissions were present.

TrustedInstaller ownership was correct.

TrustedInstaller was operational.

The hardlinks existed.

DISM found no component-store corruption.

CHKDSK then found damaged NTFS directory/index information in:

C:\Windows\INF

including the exact file:

c_firmware.inf

The offline CHKDSK repair corrected the filesystem.

Afterwards:

chkdsk C: /scan

reported a clean filesystem.

And KB5122878 then installed successfully.

That gives a much stronger causal chain than simply saying:

We ran CHKDSK and afterwards Windows Update worked.

For somebody who wants to determine quickly whether they have the same problem, the useful route is:

Open:

Windows PowerShell as Administrator

Then search CBS:

Select-String -Path "$env:windir\Logs\CBS\CBS.log" -Pattern '80070005','E_ACCESSDENIED','Access is denied'

If CBS identifies c_firmware.inf, search SetupAPI:

Select-String -Path "$env:windir\INF\setupapi.dev.log" -Pattern 'c_firmware.inf'

If SetupAPI shows Windows failing to delete or publish the INF with:

Error = 0x00000005

run:

chkdsk.exe C: /scan

If CHKDSK then reports index corruption, lost files, unindexed links or $I30 problems involving C:\Windows\INF or the same affected INF, schedule the repair:

chkdsk.exe C: /f

Answer:

Y

then restart:

Restart-Computer

After Windows starts again:

open:

Windows PowerShell as Administrator

again and verify:

chkdsk.exe C: /scan

Only when the filesystem reports clean should you treat the filesystem repair as complete.

Do not apply this diagnosis simply because you have:

0x80070005

That code has many possible causes.

If CBS does not identify the same or a similar Driver Operations Queue failure, or SetupAPI does not show the corresponding INF publication/deletion failure, or CHKDSK finds no relevant filesystem corruption, then your problem is different.

Rather than randomly changing permissions or deleting Windows directories, analyse the actual log failure.

A useful ChatGPT prompt would be:

Windows Update fails with 0x80070005. I have included the relevant CBS.log and/or setupapi.dev.log entries below. Identify the first operation that genuinely fails and the object involved. Do not give generic Windows Update troubleshooting. Work backwards from the first 0x80070005 or E_ACCESSDENIED and tell me whether the failure involves a file, INF, directory, registry key, service, package, hardlink or another servicing operation. Separate the original failure from later errors that are simply consequences of it.

That is essentially the method that found this fault.

The important lesson from this case is not that 0x80070005 means “run CHKDSK”.

It is:

0x80070005 tells you that access was denied.
The logs tell you what access was denied to.
That is where the diagnosis should start.

• Windows Update log filesIdentifies CBS.log as the servicing log to use when an update fails to install.
• SetupAPI Device Installation Log EntriesExplains where setupapi.dev.log lives and what it records.
• Troubleshooting Driver Signing InstallationExplains the ! and !!! markers in setupapi.dev.log: a warning and a failure.
• chkdskDocuments /scan, an online scan of an NTFS volume, and /f, which fixes errors and schedules the repair for the next restart if the volume cannot be locked.
• Locate and correct disk space problems on NTFS volumesCovers NTFS corruption repaired with chkdsk /f, and explains what an NTFS hard link is.