0xC00001A4: File Already Has a Notification GUID

You're running a backup job, a sync tool, or maybe a custom script that watches a folder for changes. Then bam — the whole thing stops and you get STATUS_NOTIFICATION_GUID_ALREADY_DEFINED (0xC00001A4). The exact message says the file already has a notification GUID associated with it. I ran into this last month with a client who had both Dropbox and a robocopy script trying to monitor the same log file. Neither would give up control, and the error locked up their file watcher completely.

Root Cause

Windows uses a unique GUID (Globally Unique Identifier) to track file change notifications. When a program calls ReadDirectoryChangesW or uses FileSystemWatcher, the OS assigns a temporary GUID to that file or directory. Only one notification GUID can be active per file handle at a time. If a second process tries to register a watcher on the same file before the first one finishes, Windows throws 0xC00001A4. It's basically saying, "Hey, someone's already got dibs on watching this file."

Old backup agents that don't release handles cleanly are the worst offenders. I've also seen it with antivirus scanners that lock files while scanning — they create a notification request and don't drop it fast enough.

The Fix: Clear Stale Notification GUIDs

Here's what works in the real world. Don't waste time reinstalling software. Do this.

Step 1: Identify the Locking Process

Open PowerShell as admin and run this to find what's holding the GUID:

Get-Process | Where-Object { $_.Id -gt 0 } | ForEach-Object { $_.Id; $_.ProcessName } 2>&1 | Out-File -FilePath C:\temp\processes.txt -Append

That's a rough shot. Better yet, use Process Monitor (ProcMon) from Sysinternals. Filter for ReadDirectoryChangesW and look at the path that's failing. You'll see which process registered the first watcher.

Step 2: Kill the Duplicate Watcher

If you find a backup or sync tool stuck on the file, kill it. Use Task Manager or:

taskkill /F /IM dropbox.exe

Replace dropbox.exe with whatever process you found. Then restart the service or app that was failing.

Step 3: Disable File Change Notifications for the Specific App

Some apps let you turn off file watching. For example, in Dropbox, go to Preferences > Sync > uncheck "Enable file change notifications". In backup software like Veeam or Acronis, look for an option to disable real-time file monitoring — they usually call it something like "Continuous file protection" or "File system watcher".

Step 4: Registry Hack (Last Resort)

If the error keeps coming back and you can't find the offending app, you can increase the pool of notification GUIDs. But be careful — this only masks the problem. Open Regedit and go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

Create a DWORD called NtfsReadDirectoryChangesWMaxBufferSize and set it to 65536 (decimal). Reboot. This gives Windows more room to handle multiple watchers before hitting the GUID limit. I don't love this fix, but it's kept a few clients running while we sorted out the actual conflict.

If It Still Fails

Check the file itself. Is it a log file that gets rotated? Some apps keep an open handle to the file after renaming it, and the old GUID sticks around. Rename the file entirely or delete it if it's not critical — that clears the GUID instantly. Also verify you're not running two instances of the same backup program. I had a client who accidentally had both the Windows version and a portable version of a sync tool fighting over the same folder. Look in Task Scheduler for any hidden jobs that might be starting a watcher at boot. Disable them one by one until the error stops.