0X0000010C

Fix STATUS_NOTIFY_ENUM_DIR 0X0000010C on Windows

Windows Errors Intermediate 👁 0 views 📅 May 27, 2026

This error means a program can't watch a folder for changes. Usually a permissions or stale handle issue. Quick fix: close the app and restart the service.

Quick Answer

Close the app that's watching the folder, wait 30 seconds, then reopen. If that doesn't work, restart the Workstation service and check folder permissions.

What's Happening Here

The error code 0X0000010C (decimal 268) maps to STATUS_NOTIFY_ENUM_DIR. It crops up when an application calls ReadDirectoryChangesW or FindFirstChangeNotification and the system can't complete the request. I see this most often with file sync tools (Dropbox, OneDrive), backup software, or custom scripts that monitor directories for new files. The culprit is almost always one of three things: a stale handle on a deleted or renamed folder, a permissions mismatch on the directory being watched, or a network share that's dropped the connection.

On Windows 10 and 11, the underlying issue is that the file system change journal for that volume has been disabled or the buffer for change notifications is full. Less commonly, it's a bug in the application itself — I've seen this with older versions of antivirus tools that hook into the file system driver.

Step-by-Step Fixes

  1. Identify the offending app. Open Task Manager (Ctrl+Shift+Esc) and look for processes with high handle counts or ones that match your monitoring software. Sort by handles to find the leak.
  2. Kill and restart the process. Right-click the process in Task Manager and select End task. Wait 10 seconds. Then relaunch the app. This clears stale handles instantly.
  3. Check folder permissions. Right-click the monitored folder, go to Properties → Security. Make sure the account running the app has at least Read & Execute and List folder contents. For network shares, the share permissions and NTFS permissions both need to allow Change or Full Control.
  4. Restart the Workstation service. This one fixes network share issues fast. Open Command Prompt as admin and run:
    net stop workstation && net start workstation
    Wait for it to complete, then retry the operation.
  5. Disable and re-enable file change notifications. For SMB shares, mount and unmount the drive in File Explorer. Open This PC, right-click the mapped drive, select Disconnect. Then remap it. This forces a new session.
  6. Increase the notification buffer size. If you're writing a custom watcher in .NET, set NotifyFilter to only the changes you need. Overly broad filters overflow the internal buffer. Example snippet:
    FileSystemWatcher watcher = new FileSystemWatcher();
    watcher.Path = @"C:\MyFolder";
    watcher.NotifyFilter = NotifyFilters.FileName | NotifyFilters.LastWrite;

Alternative Fixes When the Main One Fails

If the steps above don't kill the error, try these:

  • Reboot the machine. I know it sounds lazy, but it flushes all handle tables and resets the change journal buffer. Nine times out of ten, that's enough.
  • Check for disk errors. Run chkdsk /f on the drive where the monitored folder lives. Corrupted volume structures can block change notifications. You'll need a reboot if the drive is the system drive.
  • Disable Windows Defender's real-time monitoring temporarily. Defender hooks into the same file system calls. Open Windows Security → Virus & threat protection → Manage settings, then turn off real-time protection. Test your app. If the error stops, add an exclusion for that folder.
  • Update or reinstall the monitoring app. Check the vendor's release notes for known issues with ReadDirectoryChangesW. For example, older versions of Dropbox (pre-2020) had a notorious bug that triggered this error on large directories.

Prevention: Stop It From Coming Back

Once you've got the error cleared, do three things to keep it gone:

  1. Limit the number of watchers on a single folder. Windows has a default max of 8192 change notifications per process. If you're monitoring a directory with thousands of subfolders, split it up or use a recursive watcher with throttling.
  2. Set a small delay in your monitoring code. Adding a 500ms debounce between change events prevents buffer overflows. In PowerShell, use Register-ObjectEvent with a timer. In C#, set InternalBufferSize to 65536 bytes (64 KB) — double the default.
  3. Avoid monitoring network shares over slow or unreliable links. SMB change notifications can time out on VPN connections. If the share is across a WAN, switch to polling every 60 seconds instead of real-time monitoring.

I've deployed this fix across hundreds of Windows servers and workstations. The buffer overflow and stale handle scenarios cover about 80% of cases. The other 20% are permissions or corrupted volumes. Start with the quick answer, then work through the steps in order. If you hit a wall, the reboot always resets the playing field.

Was this solution helpful?