The documentation (books, etc.) claim that an advantage of using UMDF is that much of Windows user mode resources are available. In particular I would like to know if there an any caveats anyone has found with the following system calls:
WaitForSingleObject()
CreateEventA()
InitializeCriticalSection()
CreateThread()
SetEvent()
Using any of the synchronization primitives is fine - no UMDF specific caveats. You must take general care to not cause deadlocks and such.
In the critical path such as pnp/power/cancellation if your wait is too long it might cause reflector to timeout your driver. But with 1 minute timeout this would likely indicate a deadlock in your driver and not a normal wait. If the operation really can take this long, you’d need to move it out of the critical path.
With CreateThread there is an important caveat - and I’m glad that you asked this question.
If you Create a thread you must run it down (cause it to exit) and wait on the thread handle in SelfManagedIoCleanup. Otherwise your driver might get unloaded while your thread is still executing causing a crash. If you only run it down and not perform a wait on the thread handle, thread may still be executing tail instructions when your driver is unloaded, so you must perform a wait.
Please look at the UMDF echo sample in WDK (CMyDevice::OnSelfManagedIoCleanup) for reference.
Praveen
The CreateThread() issue appears to be a an issue when the driver is unloaded. In my case I expect that this scenario will not occur often since it is a software driver. In any case I will make sure that I guard against this possibility.
Thanks!