CreateProcessW + JOB_LIST: child lifetime if the caller terminates before the API returns

Question

CreateProcessW + JOB_LIST: child lifetime if the caller terminates before the API returns

Mateusz Paradiuk 0

I am seeking clarification of the supported Windows API contract for one process-lifetime scenario. No orphaned process has been observed or reproduced; this is a documentation question.

Assume the following valid setup:

A user-mode caller creates an unnamed, private Job Object and successfully enables JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE through JOBOBJECT_EXTENDED_LIMIT_INFORMATION.
The caller owns the only user-mode handle to that job. The handle is not inheritable and is never duplicated or passed to another process.
The caller supplies that job through PROC_THREAD_ATTRIBUTE_JOB_LIST in a valid STARTUPINFOEX and calls CreateProcessW with EXTENDED_STARTUPINFO_PRESENT and CREATE_SUSPENDED. No breakaway is requested or permitted. All other parameters, permissions and any applicable job-nesting constraints are valid.
The entire calling process is abruptly terminated while CreateProcessW is still in progress, before it returns. The caller therefore cannot inspect PROCESS_INFORMATION, close returned handles, resume the child, or perform any post-call cleanup. This is process termination, not merely a terminated thread, a hung caller, or an operating-system crash.

Does Windows provide a supported guarantee that this interrupted operation cannot leave a child process alive outside the effective protection of the job, including a suspended child with no surviving supervisor?

For this single guarantee, please clarify: A. Whether any child execution can occur outside the required job association in this interrupted call. B. Whether a partially created, unassigned or otherwise unprotected suspended child can remain after the caller has terminated. C. How job association and closure of the caller's last job handle are ordered for this case, including the effect of any internal references acquired during creation. D. Whether the child is either effectively covered by job termination or creation is unwound, without requiring CreateProcessW to return to the caller.

The documentation describes job-list assignment during creation and termination of associated processes on last-handle closure. I have not established how those rules jointly settle the exact interruption-before-return case:

Please identify the documented contract or an authoritative Windows API clarification, including applicable Windows versions and conditions. If this exact outcome is unspecified or not guaranteed, please state that boundary explicitly. An explanation of the ordinary successful return path alone would not resolve this question. No fixed cleanup-time guarantee or review of application code is being requested.

0 comments

1 answer

Your answer

Answer 1

Hi @Mateusz Paradiuk

Under your stated valid-setup assumptions, I could not identify a public Microsoft API contract or authoritative clarification that explicitly guarantees the complete outcome when the caller terminates before CreateProcessW returns. That exact interrupted-call outcome is not explicitly specified in the references below. This is a boundary of what those sources establish, rather than evidence that an unprotected child can survive.

Regarding execution in point A, Raymond Chen’s article presents PROC_THREAD_ATTRIBUTE_JOB_LIST as the solution to the orphan window between separately creating a suspended process and assigning it to a job. It states that assignment occurs before the initial thread is allowed to run. Additionally, the process creation flags documentation states that CREATE_SUSPENDED prevents the primary thread from running until ResumeThread is called. These statements support the initial-thread ordering, but do not expressly settle every child-execution outcome when the caller terminates inside the API.

For the suspended-child and unwind questions in B and D, the CreateProcessW reference documents successful and failed returns, but does not specify rollback when the caller terminates before the function returns. I found no explicit statement requiring every partially created child to be either effectively covered by job termination or torn down without returning control to the caller. Suspension alone does not establish that cleanup guarantee.

Regarding point C, the process termination documentation states that the terminating process’s open handles are automatically closed. The job limit documentation specifies that JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE terminates all processes associated with the job when its last handle closes. A child associated with the job at that point is covered, including a suspended child, without requiring the caller to resume it or perform post-call cleanup. The unresolved part is how that closure is ordered against an assignment still pending inside CreateProcessW.

For internal references, Microsoft’s object lifetime documentation distinguishes open-handle counts from object-reference counts. A kernel pointer reference can keep an object allocated after its last handle closes; it does not constitute another open handle. This general lifetime rule does not specify which references CreateProcessW acquires, when they are released, or their effect on the assignment and termination ordering in your scenario.

The startup attribute documentation lists Windows 10 and Windows Server 2016 or later as the supported versions for PROC_THREAD_ATTRIBUTE_JOB_LIST. These are feature-availability requirements. With the handle ownership, extended-startup configuration, and applicable job-nesting conditions assumed valid as in your question, I still could not identify a documented version or build that explicitly resolves the complete interrupted-call guarantee.

Within the scope of this forum, this is the extent of the clarification I can substantiate from public documentation. For further clarification of the interrupted-call guarantees, you can submit a request through Windows Developer Support, select the support option that best matches your situation, and describe the scenario you need clarified. Please note that technical support through this channel is paid, incident-based, and requires a Microsoft support contract.

I hope this helps clarify what the available documentation establishes and where further confirmation is needed. If you find this explanation helpful, you’re welcome to follow this guidance so others with the same question find the relevant information.

Thank you.