When does windows signal a process handle?

The process signals when the application code exits. It may take the OS a little more time to unload the process completely. The point of signalling is to say "I'm done doing what I need to do", its more effecient to release other code that may have really useful stuff to do instead of making that code wait while the OS does some housekeeping.

As another answer points out, the process handle gets signalled when the process has stopped execution, and the operating system might take a bit longer to release DLLs.

You are right that relying on Sleep(100) is a bad idea. You should rather wrap overwriting your DLLs in a loop like this:

BOOL UpdateDll(LPCTSTR dll_name, WHATEVER whatever) {  int tries = 150;  while (tries--) {    if (TryUpdateDll(dll_name, whatever))      return TRUE;    Sleep(200);  }  return FALSE;}

This keeps trying to unload your DLL for 30 seconds and then gives up. 30 seconds should be enough even when the system is under heavy load, but still will protect your updater from hanging forever. (In case UpdateDll returns FALSE, be sure to present a meaningful error message to your user, stating the name of offending DLL.)

If you are messing with COM, a call to CoFreeUnusedLibraries before quitting might also be helpful. (http://msdn.microsoft.com/en-us/library/ms679712.aspx) Frankly I don't know if COM might hold on to DLLs even after your process exits, but better be safe.

Bottom line is that there's a lot of strangeness in Win32 API. You don't have to deal with every case as long as you can find an acceptable solution. Obviously Sleep(100) might break, but a 30-second polling loops seems acceptable to me.

It could be that the DLL's are locked by some other process at the time. One way to test this would be to generate a report of whatever is holding onto the DLL when this happens.