Feature request: Create job user's local profile on win32

[ddneilson]

Use Case

If a user is running Windows with active directory and the user that jobs are run as is a domain user, then the local profile (e.g. %LOCALAPPDATA% directory) does not seem to exist for that user until the user has done an interactive logon. So, if a job that is run by the worker agent makes use of the user's local profile (e.g. putting fonts in %LOCALAPPDATA%) then that job will fail and the root cause is unlikely to be obvious.

Proposed Solution

There does seem to be a workaround, but it would be nice if users didn't have to employ the workaround.

In the worker agent, before creating the logon token (or when creating the openjd.sessions.SessionUser for a username/password combo outside of the service context) do a call to the Win32 CreateProfile API.

Alternative solution to investigate may involve loading the domain user's roaming profile in the LoadProfileW API call; that appears to require setting the lpProfilePath property of the lpProfileInfo structure.

[aleksnikolaev]

We are hitting a closely-related class of failure on service-managed fleets (SMF) with Windows + T4 GPU, where the user running jobs is the SMF built-in local job-user (not a domain user). Posting our production data here in case it's the same root cause, but on a re-read the surface we see may be adjacent to (rather than identical to) the one this issue describes — please advise whether to track under this issue or open a separate one.

Symptom

Steady-state failure on per-task conda-queue-env-exit / cleanup phase. Session log:

openjd_fail: Could not run Python as user job-user to find executable python in PATH.
The host configuration must allow users to run c:\program files\python311\python.exe.
openjd_fail: Could not run Python as user job-user to find executable conda-queue-env-exit in PATH.
Process failed to start: [WinError 6] The handle is invalid.
Files within temporary directory C:\Sessions\session-<...>\... could not be deleted.

Python is present at the standard c:\program files\python311\python.exe location and conda-queue-env-exit is on the AMI by default, so the "can't find in PATH" line is the user-facing message from openjd-sessions-for-python (_locate_executable.py::_locate_for_other_user) when its discovery subprocess produces no output. The actual low-level fault is Process failed to start: [WinError 6] The handle is invalid — i.e. CreateProcessAsUser receiving or using an invalid handle/token. (We're not claiming a specific privilege gap, since a privilege failure on CreateProcessAsUser typically surfaces as ERROR_PRIVILEGE_NOT_HELD (1314), not WinError 6 (ERROR_INVALID_HANDLE).)

Why we believe this is adjacent to, but possibly distinct from, #409

This issue (as written) is about Win32 CreateProfile / LoadProfileW not being called for the SessionUser, so the user's local profile and %LOCALAPPDATA% are absent — the example given is a domain user that never had an interactive logon.

In our case, job-user is a local SMF-built-in user, and the low-level failure is CreateProcessAsUser itself failing with WinError 6. The low-level failure is CreateProcessAsUser receiving or using an invalid handle/token, not a missing Python package and not simply a missing user profile.

It's plausible that adding CreateProfile / LoadProfileW to the SessionUser bootstrap (the fix proposed in this issue) would also close our case as a side effect, since LoadProfileW materializes the user-scoped environment which CreateProcessAsUser then operates against. But the load-bearing question for our case is the validity of the handle/token at CreateProcessAsUser time, not the profile materialization step per se.

(Microsoft reference: CreateProcessAsUserW.)

Configuration

• Service-Managed Fleet, Windows + T4 GPU (spot)
• Queue jobRunAsUser = { "runAs": "WORKER_AGENT_USER" } — i.e. we are explicitly NOT using a queue-configured user, yet OpenJD attempts to launch the env exit step under job-user.
• Conda queue environment with AE-based packages:
  aftereffects=26 aftereffects-textbox2 aftereffects-deepglow aftereffects-deepglow2
• Custom Conda channel hosted on a private S3 bucket.

Scale and randomness (last 7 days, one fleet, single queue)

• 877 openjd_fail occurrences
• 633 [WinError 6] The handle is invalid occurrences
• 614 distinct sessions affected
• 614 distinct SMF workers affected — not a stuck-worker problem, every fresh spot instance can hit it.
• Across 30 jobs in a representative 24h window: 26 SUCCEEDED + 4 FAILED, with identical submitted CondaPackages parameter and same queue/fleet. Two same-language jobs on the same day, same config, ended with opposite outcomes. So failure is not project, package-set, or fleet-host correlated — it's per-process-token randomness.

When it started

Began immediately after our migration from a customer-managed fleet to SMF in late April 2026. Zero openjd_fail occurrences during ~40 days of prior CMF activity (same workload, same Conda packages where applicable). The transition coincided with switching to WORKER_AGENT_USER runAs mode and to the SMF AMI where job-user is the impersonation target.

Workaround status

We have not found a customer-side workaround on SMF: queue jobRunAsUser is already WORKER_AGENT_USER, the AMI is service-managed, and the conda packages are required for the workload. Switching to QUEUE_CONFIGURED_USER with an explicit windowsUser is the obvious next experiment but requires a different credential model and may not apply on SMF in the same way.

Question

1. Is this within scope of this issue (would the CreateProfile / LoadProfileW fix also cover the CreateProcessAsUser WinError 6 case on SMF Windows), or should we open a separate issue specifically for the invalid handle/token path?
2. Any known supported workaround for the SMF case in the meantime?

Happy to share a sanitized session log snippet or additional repro detail if helpful.

---

Edit: trimmed an earlier sentence that speculated about SE_TCB_NAME — CreateProcessAsUser privilege gaps typically surface as ERROR_PRIVILEGE_NOT_HELD (1314), not WinError 6, so that was the wrong family of cause to point at. Reframed to "invalid handle/token at CreateProcessAsUser time" without claiming a specific privilege.