NotificationCompletion does not clean up properly on error

[jimbeveridge]

In your CReadChangesRequest::NotificationCompletion, in case of error you just delete the CReadChangesRequest object which is fine, except that I took a look at CReadChangesRequest's destructor and there's no trace of uninit calls of any kind in it, even "worse", you assume the object has already been uninit before being destructed by using an assertion onto directory's handle.

So it seems that in that particular case, the CReadChangesServer object (i.e.: the owner) continues to think that the request still exists as it is still registered in its list (vector here). I did see that m_nOutstandingRequests is decremented but it does not seem to be enough for the CReadChangesServer to avoid making assumption onto request's existence...

from http://qualapps.blogspot.com/2010/05/understanding-readdirectorychangesw.html?showComment=1371655064483#c8470618158346962153

[ams-tschoening]

If ERROR_OPERATION_ABORTED can occur for any other reason than because of a call to "RequestTermination", than I would agree with the bug reporter. But currently it reads to me that the bug reporter might have missed that "RequestTermination" is at least the main reason why ERROR_OPERATION_ABORTED can occur and in that case CloseHandle on the directory has already been called and the server oject has cleared all of it list contents.

That would explain why it simply works in your environment. I would close it, if it was my bug, but I might be wrong of course.