| Previous | Next |
| ERROR_CHILD_MUST_BE_VOLATILE | ERROR_DEPENDENT_SERVICES_RUNNING |
ERROR_NOTIFY_ENUM_DIR
A notify change request is being completed and the information is not being returned in the caller's buffer. The caller now needs to enumerate the files to find the changes.
ERROR_NOTIFY_ENUM_DIR means that directory change notification overflowed or lost detail, so the caller must rescan the directory to rebuild a correct view. In this case, the decisive context is ReadDirectoryChangesW and related filesystem notification consumers, together with watched directory, subtree flag, filter mask, buffer size, and completion mode.
Where the result appears
- ReadDirectoryChangesW and related filesystem notification consumers.
- file indexers, synchronizers, backup tools, IDEs, and antivirus products.
- high-change directories or small notification buffers.
- network redirectors and providers that cannot return every individual change.
Typical causes
- more changes occurred than fit in the supplied buffer.
- events were coalesced or discarded by the filesystem/provider.
- the watch was interrupted by rename, reconnect, overflow, or directory transition.
- processing lag allowed the producer to outrun the consumer.
Evidence to collect
- watched directory, subtree flag, filter mask, buffer size, and completion mode.
- rate and type of changes during the loss window.
- filesystem/provider type and whether the path is local or remote.
- the application’s last known consistent snapshot or journal position.
For this condition, begin the investigation with watched directory, subtree flag, filter mask, buffer size, and completion mode. Correlate it with rate and type of changes during the loss window and check whether more changes occurred than fit in the supplied buffer. Capture the original this result immediately after the failing call so later cleanup does not replace the thread-local error value.
Handling and recovery
Treat the notification stream as invalid until a complete enumeration reconciles current state with the application’s model. Do not merely continue with later notifications, because missed creates, deletes, and renames can leave persistent divergence. After reconciliation, restart or re-arm the watch according to the API contract.
Any retry policy for it should be tied to evidence that events were coalesced or discarded by the filesystem/provider has changed. Before another attempt, verify filesystem/provider type and whether the path is local or remote. If processing lag allowed the producer to outrun the consumer still applies, stop the retry sequence and preserve the first diagnostic event.
Common misinterpretation
The result is not an empty change set. It explicitly says detailed changes are unavailable and enumeration is required.
Guidance for developers
When surfacing this result through another layer, retain its Win32 domain, numeric value, and the operation described by file indexers, synchronizers, backup tools, IDEs, and antivirus products. A useful telemetry record also includes the application’s last known consistent snapshot or journal position. For directory-related handling, decisions must use the numeric value and documented API contract rather than localized wording.
A focused test should reproduce the condition in which the watch was interrupted by rename, reconnect, overflow, or directory transition, assert this result, and confirm that the program releases resources associated with high-change directories or small notification buffers. The recovery test should also verify that watched directory, subtree flag, filter mask, buffer size, and completion mode is refreshed before the operation resumes.
References
Looking for a different code? Search another status or error code.