Windows Job Object reports ActiveProcesses=1 after worker exit and an unexpected PID

Question

Windows Job Object reports ActiveProcesses=1 after worker exit and an unexpected PID

Carlos Garcia 0

I'm developing a paper/simulation-only Python research platform on Windows using CPython 3.13.15 and Win32 APIs.

I'm investigating unexpected Windows Job Object membership and how to establish safe process termination and resource cleanup.

Environment and setup

Windows, 64-bit, non-administrator session.

A fresh unnamed Job Object created using CreateJobObjectW.

One-active-process limit and JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE enabled.

A single intended worker created suspended using CreateProcessW, with PROC_THREAD_ATTRIBUTE_JOB_LIST.

Handle inheritance disabled; breakaway not enabled.

The worker communicates through named-pipe IPC.

Observed results

The original worker completed successfully:

WaitForSingleObject: WAIT_OBJECT_0

GetExitCodeProcess: 0

Strict IPC EOF verified.

No outstanding IPC operation recorded.

Original process and thread handles successfully closed.

However, QueryInformationJobObject with JobObjectBasicAccountingInformation returned:

API success: TRUE

Returned length: 48/48 bytes

TotalProcesses: 2

ActiveProcesses: 1

TotalTerminatedProcesses: 0

I also tested closing the parent-owned named-pipe server handle after verified EOF but before process/thread handle release. Both orderings still returned ActiveProcesses = 1.

A subsequent JobObjectBasicProcessIdList query using the same retained Job Object returned:

API success: TRUE

NumberOfAssignedProcesses: 1

NumberOfProcessIdsInList: 1

Returned length: 16 bytes

Returned PID: 1416

The intended worker PID was 11128 and the parent PID was 16148. Neither matched the returned PID.

These queries occurred at different times, so I cannot assume they represent an atomic snapshot or that the returned PID proves the process is still running.

Questions for Windows API experts

Under what documented conditions can a terminated worker still contribute to ActiveProcesses after its original process and thread handles have been closed?

What could explain TotalProcesses = 2 and a later PID-list result containing an identifier different from the intended worker?

Can failed job associations, nested jobs, or remaining kernel references explain these observations?

What is the recommended way to establish the scope of processes potentially affected by TerminateJobObject or KILL_ON_JOB_CLOSE?

If exclusive termination authority cannot be established, what safer containment architecture should be considered?

The application currently rejects the nonzero accounting result and does not treat the worker as safely quiescent.

I'm looking for documented Windows API semantics and architectural guidance, not a way to bypass containment or weaken the safety checks.

Thank you for any guidance or relevant Microsoft documentation.I'm developing a paper/simulation-only Python research platform on Windows using CPython 3.13.15 and Win32 APIs.

I'm investigating unexpected Windows Job Object membership and how to establish safe process termination and resource cleanup.

Environment and setup

Windows, 64-bit, non-administrator session.

A fresh unnamed Job Object created using CreateJobObjectW.

One-active-process limit and JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE enabled.

A single intended worker created suspended using CreateProcessW, with PROC_THREAD_ATTRIBUTE_JOB_LIST.

Handle inheritance disabled; breakaway not enabled.

The worker communicates through named-pipe IPC.

Observed results

The original worker completed successfully:

WaitForSingleObject: WAIT_OBJECT_0

GetExitCodeProcess: 0

Strict IPC EOF verified.

No outstanding IPC operation recorded.

Original process and thread handles successfully closed.

However, QueryInformationJobObject with JobObjectBasicAccountingInformation returned:

API success: TRUE

Returned length: 48/48 bytes

TotalProcesses: 2

ActiveProcesses: 1

TotalTerminatedProcesses: 0

I also tested closing the parent-owned named-pipe server handle after verified EOF but before process/thread handle release. Both orderings still returned ActiveProcesses = 1.

A subsequent JobObjectBasicProcessIdList query using the same retained Job Object returned:

API success: TRUE

NumberOfAssignedProcesses: 1

NumberOfProcessIdsInList: 1

Returned length: 16 bytes

Returned PID: 1416

The intended worker PID was 11128 and the parent PID was 16148. Neither matched the returned PID.

These queries occurred at different times, so I cannot assume they represent an atomic snapshot or that the returned PID proves the process is still running.

Questions for Windows API experts

Under what documented conditions can a terminated worker still contribute to ActiveProcesses after its original process and thread handles have been closed?

What could explain TotalProcesses = 2 and a later PID-list result containing an identifier different from the intended worker?

Can failed job associations, nested jobs, or remaining kernel references explain these observations?

What is the recommended way to establish the scope of processes potentially affected by TerminateJobObject or KILL_ON_JOB_CLOSE?

If exclusive termination authority cannot be established, what safer containment architecture should be considered?

The application currently rejects the nonzero accounting result and does not treat the worker as safely quiescent.

I'm looking for documented Windows API semantics and architectural guidance, not a way to bypass containment or weaken the safety checks.

Thank you for any guidance or relevant Microsoft documentation.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

1 answer

Your answer

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 1

Percy Nguyen (WICLOUD CORPORATION) 160 Microsoft External Staff Moderator

Hi Carlos Garcia,

Thank you for posting your question.

The first thing I’d separate is the worker’s termination from the job’s accounting state. Your successful wait on the worker’s process handle establishes that the worker terminated. The remaining question is why the job still reports an associated process.

There is a documented case that can produce misleading-looking accounting: an attempted job association that fails because of a limit violation. Microsoft states that this increments TotalProcesses and temporarily increments ActiveProcesses. The latter is decremented after the terminated process exits and all references to it are released. Closing your own process and thread handles does not necessarily release references held elsewhere. That makes a rejected second process a plausible explanation, although it does not establish that this is what happened here. JOBOBJECT_BASIC_ACCOUNTING_INFORMATION

TotalTerminatedProcesses = 0 also deserves attention. That field counts terminations caused by limit violations, so I would not consider the rejected-process explanation confirmed without more evidence. A one-active-process limit does not impose a lifetime limit of one process, either.

The different PID is the most useful clue. Assuming the job handle and structure parsing are correct, references to worker PID 11128 cannot explain an entry identifying PID 1416. You need to identify that process, ideally while reproducing the issue. Open a process handle, record its executable path and creation time, check membership using IsProcessInJob with your retained job handle, and check whether the process handle is signaled. A later lookup by PID alone is vulnerable to PID reuse, and an unsuccessful OpenProcess call does not prove termination. IsProcessInJob

Nested jobs could matter because both accounting and the PID list include descendant jobs. However, an inherited outer job does not automatically bring its other processes into your private child job. Membership and accounting flow through the hierarchy in specific directions; nesting alone does not explain an unrelated process appearing in your job. Also, disabling handle inheritance does not disable inheritance of job membership. Nested Jobs, Job Objects

For troubleshooting, I would focus on a few checks:

Read back the limits and verify that the job is empty before creating the worker.
Query membership while the worker is still suspended, then again after resumption and termination. This should help locate when the second process appears.
Verify the exact executable being launched. CPython’s Windows virtual-environment launcher creates another interpreter process, so “one Python worker” does not always mean one Windows process. This is worth checking, although it does not by itself explain your complete result.
If using ctypes, verify handle types, structure offsets, and attribute-buffer lifetimes. The reported buffer sizes are consistent with x64, but that alone does not validate the binding.
Associate a completion port before adding processes and record process and limit notifications. Treat these as supporting diagnostics: Microsoft does not guarantee delivery of ordinary job notifications. Completion-port documentation

For termination scope, TerminateJobObject affects the selected job and all its descendant jobs. KILL_ON_JOB_CLOSE applies the corresponding scope when the last job handle closes. A PID snapshot cannot guarantee that membership remains unchanged before termination. The stronger approach is to establish ownership by construction: a trusted supervisor, a private job per workload, controlled assignment and handle access, and an explicit policy covering permitted descendants. TerminateJobObject

One practical consequence is that, with kill-on-close already enabled, closing the last handle—or exiting the process that owns it—can trigger termination even if you never call TerminateJobObject. That needs to be part of the failure-handling design.

If you cannot establish an acceptable termination scope in the current environment, I would move the supervisor and workload into a dedicated disposable VM and use that as the teardown boundary.

Your conservative handling makes sense. I would describe the current result as “worker terminated successfully; job membership and cleanup remain unresolved.” The logs support that distinction, but they do not yet establish the cause of the remaining entry.

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.

RLWA32 52,936 Reputation points

2026-10-13T10:07:53.27+00:00

@Percy Nguyen (WICLOUD CORPORATION) @Carlos Garcia

I could not reproduce the issue on Win10 22H2 with a C++ Win32 desktop application. The application created a job object with a 1 process limit and kill on job close. it was also configured to receive job object notifications. No other limits on the job were configured. Child processes were created suspended in the job object and their termination was handled through waiting on the related process handle. I did not include any IPC between the parent process and the child in the job.

When child processes were created and terminated the job object was queried.

First child process created

First process exits

Second process

Second process exits

Third process

Fourth process attempt violating job limit

Job object limit violation notification received and CreateProcess fails.

After the failed fourth process attempt

Note that TotalProcesses remained at 3 and TotalTerminatedProcess remained at 0. The failed fourth process creation never made it into the job.
Carlos Garcia 0 Reputation points

2026-10-13T16:53:22.5466667+00:00
@Percy Nguyen (WICLOUD CORPORATION) @RLWA32

Thank you both for your detailed guidance.

We completed another strictly read-only investigation of our existing Milestone 17 P2 source code, saved reports, and historical transcripts.

Our updated findings:

The prepared diagnostic launched its parent through CPython 3.13.15’s virtual-environment interpreter.

The P2 worker explicitly uses the pinned base Python interpreter through CreateProcessW. The saved report shows: Parent PID: 16148 Worker PID: 11128 TotalProcesses: 2 ActiveProcesses: 1 TotalTerminatedProcesses: 0 Unexpected PID: 1416 The intended worker exited successfully, but PID 1416’s executable identity, ancestry, creation time, and association history remain unknown. We recovered the prepared diagnostic and observer, but cannot independently verify that the exact prepared command was executed.

We have two follow-up questions:

Could this evidence indicate a specific Windows Job Object accounting or nested-job behavior, or is it insufficient to determine the cause? Would a dedicated disposable virtual machine be the safer boundary for future investigation if exclusive process ownership cannot be established?

We are keeping job-wide termination and cleanup experiments blocked until the termination scope can be established safely.

Thank you both again for your time and assistance. Thank you both for your detailed guidance.

We completed another strictly read-only investigation of our existing Milestone 17 P2 source code, saved reports, and historical transcripts.

Our updated findings:

The prepared diagnostic launched its parent through CPython 3.13.15’s virtual-environment interpreter.

The P2 worker explicitly uses the pinned base Python interpreter through CreateProcessW.

The saved report shows:

Parent PID: 16148

Worker PID: 11128 TotalProcesses: 2 ActiveProcesses: 1 TotalTerminatedProcesses: 0 Unexpected PID: 1416 The intended worker exited successfully, but PID 1416’s executable identity, ancestry, creation time, and association history remain unknown. We recovered the prepared diagnostic and observer, but cannot independently verify that the exact prepared command was executed.

We have two follow-up questions:

Could this evidence indicate a specific Windows Job Object accounting or nested-job behavior, or is it insufficient to determine the cause?

Would a dedicated disposable virtual machine be the safer boundary for future investigation if exclusive process ownership cannot be established?

We are keeping job-wide termination and cleanup experiments blocked until the termination scope can be established safely.

Thank you both again for your time and assistance.
RLWA32 52,936 Reputation points

2026-10-13T18:04:53.9733333+00:00

Have you tried using tools like Sysinternals Process Monitor/Process Explore to identify the mystery process?

Is it possible that Python is creating this process on its own?
Carlos Garcia 0 Reputation points

2026-10-13T18:08:38.0533333+00:00
Thank you, @RLWA32

We have not captured a Sysinternals Process Monitor trace or a contemporaneous Process Explorer snapshot identifying the unexpected PID 1416.

Our investigation so far has been limited to reviewing existing source code, saved diagnostic reports, and historical transcripts.

Regarding Python potentially creating another process, we found something relevant:

The recovered prepared diagnostic invokes its parent through CPython 3.13.15’s virtual-environment interpreter.

The Windows virtual-environment launcher can create another Python interpreter process.

However, the P2 worker explicitly launches the pinned base Python interpreter using CreateProcessW.

We cannot independently establish that the exact prepared diagnostic command was executed.

The saved report still shows:

Parent PID: 16148

Intended worker PID: 11128

Unexpected PID: 1416

TotalProcesses: 2

ActiveProcesses: 1

TotalTerminatedProcesses: 0

We agree that Process Monitor could potentially provide useful evidence during a future controlled investigation.

Our concern is that the Job Object has kill-on-close behavior configured, and the identity and ownership of the unexpected process remain unestablished. We therefore do not want to reproduce the issue on our normal workstation without a verified safe termination boundary.

Would you recommend capturing the process-creation events inside a dedicated disposable virtual machine, or is there another non-destructive diagnostic approach you would suggest before attempting a reproduction?

Thank you again for your continued assistance. Thank you, RLWA32.

We have not captured a Sysinternals Process Monitor trace or a contemporaneous Process Explorer snapshot identifying the unexpected PID 1416.

Our investigation so far has been limited to reviewing existing source code, saved diagnostic reports, and historical transcripts.

Regarding Python potentially creating another process, we found something relevant:

The recovered prepared diagnostic invokes its parent through CPython 3.13.15’s virtual-environment interpreter.

The Windows virtual-environment launcher can create another Python interpreter process.

However, the P2 worker explicitly launches the pinned base Python interpreter using CreateProcessW.

We cannot independently establish that the exact prepared diagnostic command was executed.

The saved report still shows:

Parent PID: 16148

Intended worker PID: 11128

Unexpected PID: 1416

TotalProcesses: 2

ActiveProcesses: 1

TotalTerminatedProcesses: 0

We agree that Process Monitor could potentially provide useful evidence during a future controlled investigation.

Our concern is that the Job Object has kill-on-close behavior configured, and the identity and ownership of the unexpected process remain unestablished. We therefore do not want to reproduce the issue on our normal workstation without a verified safe termination boundary.

Would you recommend capturing the process-creation events inside a dedicated disposable virtual machine, or is there another non-destructive diagnostic approach you would suggest before attempting a reproduction?

Thank you again for your continued assistance.
RLWA32 52,936 Reputation points

2026-10-13T18:11:17.14+00:00

@Carlos Garcia

Would you recommend capturing the process-creation events inside a dedicated disposable virtual machine

Yes, I think that's a good approach to take.
Carlos Garcia 0 Reputation points

2026-10-14T00:55:05.6266667+00:00

@RLWA32

Thank you for recommending a dedicated disposable VM.

I found that GitHub Actions offers temporary Windows virtual machines with 8 GB RAM under its free usage allowance.

However, the standard runners use Windows Server rather than my Windows 11 Home environment, and they are designed for automated jobs instead of interactive desktop troubleshooting.

Would a GitHub-hosted Windows runner be suitable for safely investigating the unexpected Job Object PID and collecting process-creation evidence, or would you recommend a separate, fully controlled Windows VM with snapshot and recovery capabilities?

We have not created a workflow or attempted another reproduction. We are keeping P2 blocked until the diagnostic environment and termination boundaries have been reviewed.

Thank you for your guidance.
RLWA32 52,936 Reputation points

2026-10-14T01:09:02.27+00:00

@Carlos Garcia I'm not familiar with the GitHub virtual machine options that you mentioned. I use a standalone virtual machine environment that has "snapshot and recovery capabilities" for testing.
Taki Ly (WICLOUD CORPORATION) 5,710 Reputation points Microsoft External Staff Moderator

2026-10-14T09:50:57.4766667+00:00
Hi @Carlos Garcia ,

I'm covering this thread on behalf of my colleague Percy, who is currently away.

I put together a small reproduction that matches your described setup as closely as I could: Python + ctypes, a fresh unnamed job with ActiveProcessLimit = 1 and KILL_ON_JOB_CLOSE (LimitFlags = 0x2008), and a worker created suspended via PROC_THREAD_ATTRIBUTE_JOB_LIST with bInheritHandles = FALSE. The worker talks to the parent over a named pipe, and the parent waits on the process handle and then closes its handles. I tested on Windows 11 (build 26200) with Python 3.14.6, since 3.13.15 wasn't available to me. For every PID in the job I recorded the image path, parent PID, IsProcessInJob, and the job completion-port messages.

What I observed:

With no creation flags (worker shares the parent's console) or with DETACHED_PROCESS, the job held only the worker. ActiveProcesses dropped to 0 as soon as the worker exited. This matches RLWA32's results.

With CREATE_NO_WINDOW or CREATE_NEW_CONSOLE, Windows also created conhost.exe with the worker as its parent, and it was associated with the same job. JOB_OBJECT_MSG_NEW_PROCESS was reported for it, and IsProcessInJob returned TRUE.

The job showed ActiveProcesses = 2 even with the active-process limit of 1, and there was no limit-violation notification. In my tests, conhost did not count against that limit. This is an observation; I haven't found documentation that describes it.

Querying right after WaitForSingleObject on the worker returned TotalProcesses = 2, ActiveProcesses = 1, TotalTerminatedProcesses = 0, and a PID list that contained only the conhost PID, not the worker PID. This is the same pattern as your report.

In my environment, conhost exited within a few milliseconds of the worker. After the handles were closed the job was always empty. I did not reproduce the entry persisting until a later query, so I can't yet explain why PID 1416 was still listed in your case.

I also tried launching the worker through a venv python.exe. The launcher could not create its child process ("Not enough quota is available"), and TotalProcesses stayed at 1. So the venv launcher alone does not seem to explain the second entry.

Suggested next steps:

Check which creation flags the P2 worker uses (CREATE_NO_WINDOW, CREATE_NEW_CONSOLE, or none). Also check whether the parent has a console of its own; for example, launched via pythonw, an IDE, or a scheduler.

On the next reproduction, record the image path and parent PID of every PID in the job at query time, before releasing the job handle. If PID 1416 turns out to be conhost.exe whose parent is the worker, then the remaining job member belongs to your own worker. KILL_ON_JOB_CLOSE would affect only that console host, not unrelated processes.

Because the IPC is a named pipe, the worker probably does not need a console. Creating it with DETACHED_PROCESS avoids the conhost instance entirely. In either case, I'd consider the job quiescent only after ActiveProcesses reaches 0, or after you receive JOB_OBJECT_MSG_ACTIVE_PROCESS_ZERO, with a bounded timeout. The worker's own exit is not enough.

On the VM question, I agree with RLWA32 that a local VM with snapshot support is a good place to test. Hosted CI runners usually run without an interactive console session, so conhost behavior there may differ from your Windows 11 Home environment.

Please let me know what you find for the creation flags and the identity of PID 1416.
RLWA32 52,936 Reputation points

2026-10-14T10:06:02.7733333+00:00

@Taki Ly (WICLOUD CORPORATION) Testing with console applications was a good idea. Do you think that results might vary if Windows Terminal was used instead of conhost.exe? It would be helpful if @Carlos Garcia clarified the environment in which the issues occurs.
Taki Ly (WICLOUD CORPORATION) 5,710 Reputation points Microsoft External Staff Moderator

2026-10-14T10:51:57.9266667+00:00
Hi @RLWA32 ,

I tested it on Windows 11 (build 26200, Windows Terminal 1.24) by switching the default terminal application between Windows Console Host and Windows Terminal. I ran each setting with CREATE_NEW_CONSOLE and with CREATE_NO_WINDOW.

The job results were the same in all four combinations:

conhost.exe was still created with the worker as its parent and was associated with the job.

Immediately after the worker exited, the job reported TotalProcesses = 2, ActiveProcesses = 1, TotalTerminatedProcesses = 0, with only the conhost PID in the list.

The job became empty a few milliseconds later.

With Windows Terminal as the default and CREATE_NEW_CONSOLE, OpenConsole.exe and WindowsTerminal.exe were also started. Both were launched by svchost.exe (DCOM activation) and IsProcessInJob returned FALSE for them. So in my tests, the terminal choice changes which processes host the UI, but not what ends up in the job.

I agree that the environment details would help. @Carlos Garcia , could you share:

The Windows build number (winver) and your default terminal setting (Settings > System > For developers > Terminal).

How the parent process is started (console window, Windows Terminal tab, IDE, pythonw, scheduled task, etc.).

The dwCreationFlags the P2 worker passes to CreateProcessW.

If possible, the image name and parent PID of PID 1416 (or of whatever PID appears in the job on the next run), captured before the job handle is released.
RLWA32 52,936 Reputation points

2026-10-14T11:20:30.8966667+00:00

@Taki Ly (WICLOUD CORPORATION) Thank you for following-up on my inquiry.
Carlos Garcia 0 Reputation points

2026-10-14T12:57:09.6733333+00:00
@Taki Ly (WICLOUD CORPORATION) (WICLOUD CORPORATION) @RLWA32 RLWA32

Thank you for the detailed reproduction and follow-up investigation. The conhost.exe finding is particularly interesting because it closely matches our saved Job Object accounting results.

I checked my Windows environment:

OS: Windows 11 Home, version 25H2

Build: 26200.9457

Default terminal application: Let Windows decide

Windows Terminal version: 1.24.12741.0

Default terminal profile: Windows PowerShell

Our read-only P2 source review confirms that the worker uses CREATE_NO_WINDOW with suspended process creation and PROC_THREAD_ATTRIBUTE_JOB_LIST. Handle inheritance is disabled.

We recovered a prepared PowerShell diagnostic that launches the parent through a CPython 3.13.15 virtual-environment interpreter. However, we cannot independently confirm the exact command executed during the historical incident or establish the parent’s complete console environment.

The saved report showed TotalProcesses=2, ActiveProcesses=1, TotalTerminatedProcesses=0, with unexpected PID 1416 after the intended worker exited.

Unfortunately, we have no preserved executable path or parent PID for process 1416, so we cannot confirm that it was conhost.exe.

Your reproduction makes conhost.exe a strong hypothesis, but we’re keeping the original safety blocker in place until ownership and cleanup behavior can be verified.

Would you recommend comparing CREATE_NO_WINDOW with DETACHED_PROCESS inside a dedicated disposable Windows VM, while recording process identity and Job Object membership before cleanup?

Thank you both for your continued help.
RLWA32 52,936 Reputation points

2026-10-14T14:36:09.0566667+00:00

@Carlos Garcia I believe you can easily use Process Explorer identify the additional process in the job.

Creating a console application as a child with its own console, with CONSOLE_NO_WINDOW and DETACHED_PROCESS yielded the following-

With own console

Job object properties of ConsoleChild.exe and conhost.exe

ConsoleChild.exe process created with CONSOLE_NO_WINDOW

Process explorer info for CONSOLE_NO_WINDOW

ConsoleChild.exe Process created with DETACHED_PROCESS

Process Explorer for DETACHED_PROCESS
Carlos Garcia 0 Reputation points

2026-10-14T17:32:56.51+00:00

@RLWA32 @Taki Ly (WICLOUD CORPORATION)

Thank you both for your continued investigation.

We completed a read-only review of our P2 worker and confirmed that its current CreateProcessW flags are:

CREATE_SUSPENDED | EXTENDED_STARTUPINFO_PRESENT | CREATE_NO_WINDOW

We are evaluating DETACHED_PROCESS as a replacement for CREATE_NO_WINDOW. Our worker communicates through a named pipe and has no identified application-level console dependency.

However, one safety question remains before we consider implementation.

Our Job Object currently uses KILL_ON_JOB_CLOSE. If the parent process crashes or unexpectedly releases its last job handle while an unidentified process is still associated with the job, Windows could terminate that process automatically.

Even if DETACHED_PROCESS prevents conhost.exe from appearing during normal execution, how would you recommend establishing a safe ownership and termination boundary for unexpected parent death or incomplete worker startup?

Would you recommend establishing exclusive workload ownership by construction before enabling kill-on-close, or a different containment design?

We are not authorizing additional native tests or process termination until that boundary is established. We also recognize that a disposable VM would reduce experimental risk but would not itself prove production safety.

Thank you again for your guidance.