Windows CreateProcessW with PROC_THREAD_ATTRIBUTE_JOB_LIST: documented guarantees if the caller terminates before the API returns

Question

Windows CreateProcessW with PROC_THREAD_ATTRIBUTE_JOB_LIST: documented guarantees if the caller terminates before the API returns

Win32Researcher-3667 0

Hello,

I would like to clarify the documented Windows API guarantees for process creation using CreateProcessW, STARTUPINFOEXW, and PROC_THREAD_ATTRIBUTE_JOB_LIST.

We are evaluating this mechanism for reliable process containment. No particular Windows version or build has been selected for deployment. The following is a hypothetical configuration, not an implemented or approved design.

Assumed configuration

A process creates a single Job Object and successfully enables JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE using SetInformationJobObject.

The process successfully configures a STARTUPINFOEXW attribute list using UpdateProcThreadAttribute, specifying PROC_THREAD_ATTRIBUTE_JOB_LIST with exactly one valid Job Object handle.

The process calls CreateProcessW with EXTENDED_STARTUPINFO_PRESENT and the configured startup information.

The calling process terminates unexpectedly while CreateProcessW is in progress, before the API returns to the caller.

For the purpose of isolating the process-creation behavior, assume that another process retains a valid handle to the same Job Object. Therefore, the caller's termination does not itself close the last Job Object handle or trigger JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE.

Assume the relevant API calls and attribute configuration completed successfully before the CreateProcessW call, and that the operating system supports PROC_THREAD_ATTRIBUTE_JOB_LIST.

1. Process creation and Job membership

Is there a documented Windows API guarantee that, if a newly created process survives the caller's termination and can execute its initial thread, it must already be associated with the specified Job Object?

Could a newly created process survive and become executable without being associated with that Job Object when the caller terminates before CreateProcessW returns?

2. Cleanup and rollback

Are there documented guarantees regarding cleanup or rollback if the calling process terminates while CreateProcessW is still in progress?

Specifically, is the outcome guaranteed to be limited to either:

No surviving newly created process; or

A surviving newly created process that has been assigned to the specified Job Object before its initial thread can execute?

If no such guarantee is documented, please indicate whether this failure scenario falls outside the published API contract.

3. Applicability and documentation

For which supported Windows versions or builds, if any, is this behavior explicitly guaranteed for CreateProcessW with PROC_THREAD_ATTRIBUTE_JOB_LIST?

Could you please provide references to Microsoft documentation that establishes the applicable guarantees or their limitations?

I am asking specifically about the documented operating system contract, not behavior observed in testing or inferred from implementation details.

Thank you.Hello,

I would like to clarify the documented Windows API guarantees for process creation using CreateProcessW, STARTUPINFOEXW, and PROC_THREAD_ATTRIBUTE_JOB_LIST.

We are evaluating this mechanism for reliable process containment. No particular Windows version or build has been selected for deployment. The following is a hypothetical configuration, not an implemented or approved design.

Assumed configuration

A process creates a single Job Object and successfully enables JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE using SetInformationJobObject.

The process successfully configures a STARTUPINFOEXW attribute list using UpdateProcThreadAttribute, specifying PROC_THREAD_ATTRIBUTE_JOB_LIST with exactly one valid Job Object handle.

The process calls CreateProcessW with EXTENDED_STARTUPINFO_PRESENT and the configured startup information.

The calling process terminates unexpectedly while CreateProcessW is in progress, before the API returns to the caller.

For the purpose of isolating the process-creation behavior, assume that another process retains a valid handle to the same Job Object. Therefore, the caller's termination does not itself close the last Job Object handle or trigger JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE.

Assume the relevant API calls and attribute configuration completed successfully before the CreateProcessW call, and that the operating system supports PROC_THREAD_ATTRIBUTE_JOB_LIST.

1. Process creation and Job membership

Is there a documented Windows API guarantee that, if a newly created process survives the caller's termination and can execute its initial thread, it must already be associated with the specified Job Object?

Could a newly created process survive and become executable without being associated with that Job Object when the caller terminates before CreateProcessW returns?

2. Cleanup and rollback

Are there documented guarantees regarding cleanup or rollback if the calling process terminates while CreateProcessW is still in progress?

Specifically, is the outcome guaranteed to be limited to either:

No surviving newly created process; or

A surviving newly created process that has been assigned to the specified Job Object before its initial thread can execute?

If no such guarantee is documented, please indicate whether this failure scenario falls outside the published API contract.

3. Applicability and documentation

For which supported Windows versions or builds, if any, is this behavior explicitly guaranteed for CreateProcessW with PROC_THREAD_ATTRIBUTE_JOB_LIST?

Could you please provide references to Microsoft documentation that establishes the applicable guarantees or their limitations?

I am asking specifically about the documented operating system contract, not behavior observed in testing or inferred from implementation details.

Thank you.

0 comments

1 answer

Your answer

Answer 1

Hi @Win32Researcher-3667 ,

Thank you for detailed post.

Microsoft documents job assignment before initial-thread execution, but I could not find an explicit API-reference guarantee covering the complete outcome when the caller terminates during CreateProcessW. Those are distinct claims.

On each of your questions:

First, The UpdateProcThreadAttribute reference documents PROC_THREAD_ATTRIBUTE_JOB_LIST as specifying the jobs to which the child process is assigned. Microsoft also publishes a more explicit explanation in Raymond Chen’s article, “A more direct and mistake-free way of creating a process in a job object”.

It states that assignment occurs before the initial thread is allowed to run. The article specifically discusses the risk of orphaned processes when the creator crashes between creating a suspended process and assigning it to a job and presents this attribute as the solution.

Therefore, assignment before execution is supported by published Microsoft guidance. However, the article does not expressly define the outcome at every interruption point when the caller dies inside CreateProcessW. Under your requirement for an explicit API contract addressing that exact scenario, I cannot cite such a statement. This documentation gap does not establish that a surviving child can actually run outside the specified job. Claiming that it can would also require evidence.

Second, the CreateProcessW reference does not specify a transactional cleanup or rollback guarantee for termination of the calling process while the call is in progress. I could not find an explicit statement restricting that scenario to your two proposed outcomes. General process-termination documentation says the terminating process’s handles are closed and that terminating a parent does not itself terminate its children. These rules do not establish what happens to every partially completed process-creation operation.

Your retained-handle assumption is also correct: JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE triggers when the last job handle closes. With another process retaining a handle, it supplies no automatic termination in response to the caller’s death.

Consequently, the exact interrupted-call cleanup outcome is not explicitly specified by these API references.

And Microsoft documents support for PROC_THREAD_ATTRIBUTE_JOB_LIST beginning with Windows 10 and Windows Server 2016, and continuing in newer versions. These are feature-availability requirements, not a separate guarantee about caller termination during creation. See the attribute’s entry in UpdateProcThreadAttribute.

I could not identify a Microsoft API reference naming a Windows version or build that expressly guarantees your exact two-outcome property. If your design requires that property as an explicit operating-system contract, the remaining step is to obtain Microsoft clarification covering this precise failure scenario and the intended deployment versions.

If you found my investigation and direction of my support helpful, I’d really appreciate it if you could follow this guide so others with similar issue can benefit as well.

Thank you.

Win32Researcher-3667 0 Reputation points

2026-10-09T12:23:47.6166667+00:00

Thank you very much for your detailed and helpful response, particularly for pointing me to Raymond Chen's article.

Your explanation helps clarify the documented guarantee regarding job assignment before initial-thread execution.

I also appreciate your distinction between that guarantee and the unresolved question of what happens if the caller terminates while CreateProcessW is still in progress.

Since our primary concern is the explicit operating-system contract for that interruption scenario, I would like to leave the question open for any further clarification or authoritative Microsoft documentation.

Thank you again for your time and assistance.