STATUS_LOG_CLIENT_NOT_REGISTERED (0xC01A0025) Fix
A log client hasn't registered on the stream. Usually a corrupted Common Log File System (CLFS) client registration or a driver bug. Fix: delete the CLFS base log file for the affected app or service.
Quick Answer
Delete the corrupted CLFS base log file (*.blf) for the failing application or service, then restart the service or the system.
What’s Actually Happening Here
Status code 0xC01A0025 (STATUS_LOG_CLIENT_NOT_REGISTERED) pops up when the Common Log File System (CLFS) – Windows’ internal logging subsystem – can’t find a registered client for a specific log stream. CLFS is used by many core components: the Event Log service, Volume Shadow Copy, Windows Update, and some third-party drivers. The error usually means a CLFS client registration inside the base log file (.blf) got corrupted or the file itself is partially overwritten. I’ve seen this after a forced shutdown during a Windows Update, after a disk check that borked the CLFS metadata, or when a driver uninstall left a dangling registration.
The key detail: this isn’t a generic “something’s wrong” error. It points directly to a missing or broken client record inside a specific stream. The fix is to remove that corrupted stream so CLFS rebuilds it cleanly.
Fix Steps
- Identify which application or service is failing. Check the Windows Application and System event logs (
Event Viewer → Windows Logs → Application). Look for events with source “CLFS” or a mention of0xC01A0025in the details. Common culprits: theTrustedInstallerservice (Windows Update),VSS(Volume Shadow Copy), or a specific driver likestorport.sys. - Find the corresponding CLFS base log file. CLFS stores its data in
C:\Windows\System32\winevt\Logs\for the Event Log service, or inC:\Windows\System32\config\TxR\for transactional registry operations. But the stream name from the event log entry tells you the exact path. For example, if the error mentions “\Device\HarddiskVolume2\Windows\System32\winevt\Logs\Application.evtx”, the base log file is typicallyApplication.evtx.blfin the same folder. Yes, the .blf file sits right next to the .evtx file. - Stop the service owning the stream. You can’t delete a CLFS file while it’s in use. Open an elevated Command Prompt and run:
net stop EventLog
Or, if it’s a different service, find its name in Services.msc and stop it. For TrustedInstaller, use:net stop trustedinstaller - Delete the corrupted .blf file. Navigate to the folder from step 2 and delete the matching
.blffile. For the Application event log, that’s:del C:\Windows\System32\winevt\Logs\Application.evtx.blf
If you’re paranoid, rename it instead (ren Application.evtx.blf Application.evtx.blf.bak). - Restart the service.
net start EventLog - Test the failing action. The service will create a fresh .blf file on next start. Run whatever triggered the error originally – Windows Update, a backup job, etc.
Alternative Fixes If the Main One Fails
- If you can’t stop the service: Boot into Safe Mode (Shift + Restart → Troubleshoot → Startup Settings → Restart → select Safe Mode). Then repeat steps 1-5. Safe Mode runs a minimal set of drivers and services, often letting you delete the .blf file without interference.
- If the error comes back: The corruption might be in a system-protected log like the
Systemevent log. In that case, try a System Restore to a point before the error started. Runrstrui.exefrom an elevated prompt and pick a restore point. If that fails, use DISM to check the system image:DISM /Online /Cleanup-Image /RestoreHealth. - If it’s a third-party driver: Look in Device Manager for any device with a yellow bang. Right-click → Properties → Driver → Roll Back Driver, or uninstall the driver entirely and let Windows reinstall the generic one. The driver’s CLFS client registration could be the problem.
Prevention Tip
The single most reliable way to avoid this error: never force-shut down Windows during an update or a VSS snapshot. CLFS writes are transactional, and a hard power-off in the middle of a transaction leaves the .blf file in an inconsistent state. If you must kill a hung update, try shutdown /r /t 0 from an admin prompt instead of holding the power button. Also, run chkdsk /f only when you’re sure the volume isn’t actively being used for CLFS streams – schedule it for next boot.
Was this solution helpful?