Corrupt Buffer with ReadDirectoryChangesW
Lucky Luke West
I'm running into a somewhat strange issue with calling
ReadDirectoryChangesW() asynchronously. I have used this API for a
couple of weeks now - successfully - but recently started seeing some
odd behavior when two threads appear to monitor the same directory in
the same process - though I am not sure if that is related.
I'm familiar with how the FILE_NOTIFY_INFORMATION structure works and
my code is able to handle multiple entries in the buffer by looking at
the NextEntryOffset member of the structure.
I have one thread that monitors the %SYSTEMROOT%\system32 directory
and all subdirectories, and this thread runs rock-solid without any
problems. Then I have another thread that monitors three directories,
and one of them being the %SYSTEMROOT%\system32\dhcp directory, a
directory used by our Win2k3 DHCP server.
What I am seeing however is that the data returned by
ReadDirectoryChangesW() (through GetQueuedCompletionStatus()) is in
some cases - always in the same directory - corrupt.
I have two things happening, and they always happen in the %SYSTEMROOT%
\system32\dhcp with pretty much always the same files:
1. GetQueuedCompletionStatus() tells me that 32 bytes were returned,
and 32 bytes matches the information that's in the buffer (a file with
10 wide characters (20 bytes) + 12 bytes for the three DWORDs). Yet,
the NextEntryOffset member holds the value 32, when it should be 0.
2. GetQueuedCompletionStatus() tells me that XX bytes were returned,
but after the 2nd or 3rd file name in the buffer the values are
completely random (well, probably not random but random to me).
NextEntryOffset will hold very large values (e.g. 676563) which
obviously is wrong.
Now, of course I have been able to adjust my code based on the number
of bytes GetQueuedCompletionStatus() returns so that I can avoid
overrunning the buffer, but I feel that there is something wrong.
My first thought was that some other code is overwriting the buffer,
but it's a separate thread and I really don't see a cause for the
buffer being overwritten by other parts of the code.
What I find particularly odd is that two threads (with different code
but the same I/O completion technique with ReadDirectoryChangesW())
are monitoring the same directory, yet only one is getting that
invalid data in the exact same directories on a regular basis.
I have a sample app (probably similar to fwatch) running on that same
host that is monitoring the dhcp directory as well and so far I
haven't encountered any problem.
I'm trying to figure out what is wrong in my code, but then I'm not
sure as to why the buffer can be corrupt? It seems to me, assuming
that I'm not messing with the buffer, that it's not being returned
correctly by the OS - maybe due to concurrency issues or because of
"unusual"? behavior in the monitored directory?
If anybody has some ideas then I would appreciate it.
Thank you.
Lucky Luke West
function but instead an error on my part. I called the
ReadDirectoryChangesW() inside the loop processing the buffer (ouch)
and didn't realize this because the code was similar to another thread
but structured differently (if that makes any sense).
Seems to work great now.