Additional notes on controlling which handles are inherited by Create­Process

# Additional notes on controlling which handles are inherited by Create­Process - The Old New Thing Source: [https://devblogs.microsoft.com/oldnewthing/20260511-00?p=112313](https://devblogs.microsoft.com/oldnewthing/20260511-00?p=112313) Some time ago, I wrote about[programmatically controlling which handles are inherited by new processes in Win32](https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873)by using the`PROC\_THREAD\_ATTRIBUTE\_HANDLE\_LIST`to limit exactly which handles are inherited\. That way, when you create a new process, you have precise control over which handles get inherited and don’t accidentally inherit handles created by unrelated components in your process\. A collegue of mine pointed out that you still have the reverse problem: Since handles must be marked as inheritable for them to participate in`PROC\_THREAD\_ATTRIBUTE\_HANDLE\_LIST`, if another thread calls`Create­Process`with`bInheritHandles`=`TRUE`but without using`PROC\_THREAD\_ATTRIBUTE\_HANDLE\_LIST`, then they will accidentally inherit all of*your*handles\. This problem could have been avoided if the`PROC\_THREAD\_ATTRIBUTE\_HANDLE\_LIST`allowed you to include non\-inheritable handles, in which case they would be non\-inheritable by normal`Create­Process`but inheritable if explicitly opted back in\. But alas, that’s not how it was designed\. Instead, you can create a helper process\. All this helper process does is wait for the main process to exit, and then exit itself\. ``` WaitForSingleObject(hMainProcess, INFINITE); ExitProcess(0); ``` This process doesn’t sound like it’s doing anything useful, and it’s not\. But what makes it useful is not what it’s doing but rather what is done*to*it\. The components in the main process create their handles as non\-inheritable\. When they wants to create a process with specific inherited handles, they duplicate the desired handles into the helper process \(as inheritable\), and then build a`PROC\_THREAD\_ATTRIBUTE\_HANDLE\_LIST`that lists those duplicates as handles to inherit\. They also use the`PROC\_THREAD\_ATTRIBUTE\_PARENT\_PROCESS`to specify that the*helper*process is the parent process that the handles should be inherited from\. Then they pass those thread attributes to`Create­Process`, and the new process will inherit exactly those handles\. Then they clean up by closing the handles in the helper process with the help of`Duplicate­Handle`and`DUPLICATE\_CLOSE\_SOURCE`\. Notice that multiple threads can simultaneously be operating on the helper process in this way, so you need only one helper process to service all your handle\-inheritance\-control needs\. This avoids the accidental inheritance problem because the handles that belong to the components in the main process are still marked non\-inheritable, so any other code in the main process that does a`Create­Process`will not inherit them\. ### Category ### Topics ## Author  Raymond has been involved in the evolution of Windows for more than 30 years\. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie\-jeebies\. The Web site spawned a book, coincidentally also titled The Old New Thing \(Addison Wesley 2007\)\. He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information\.