Handling STATUS_NOTIFY_ENUM_DIR for directory change during driver shutdown

Hi guys,

I have an issue that I believe I may be able to solve if I have a better understanding of how the IO manager interacts with my driver.

I have a KeWaitForMultipleObjects setup which will react when either the shutdown event is signaled or when a directory is changed and I set the event within my own completion routine. The issue is when both of these happen simultaneously.

Typically, when I see that KeWaitForMultipleObjects reacted to the directory notification change, I enumerate the files in that directory (after my completion routine has been called). But since the shutdown event is the 0th object for KeWaitForMultipleObjects, that takes precedence and I attempt to cancel the other IRP for directory notification. Usually this works, but if not, my understanding is because it’s either completing or completed.

The issue is that I have a bug check at the end of all of this after I call KeWaitForMultipleObjects again to ensure that everything is “complete”, but the status in the IO_STATUS_BLOCK shows STATUS_PENDING whenever the IRP’s IoStatus is returned as STATUS_NOTIFY_ENUM_DIR (as opposed to STATUS_SUCCESS or STATUS_CANCELLED). I haven’t been able to identify how the IO_STATUS_BLOCK eventually changes values from STATUS_PENDING to STATUS_SUCCESS so I’m wondering if this is somehow happening behind the scenes. Do I necessarily have to enumerate the files of the directory using system calls for the value in the IO_STATUS_BLOCK to change to STATUS_SUCCESS? I’ve heard that this might be somehow handled by the “IO Manager” but i’m not entirely sure how that works.

Any help in resolving this would be greatly appreciated!

If you have a bug check provide us with an output from !analyze -v