conhost.exe command line changes from "0xffffffff -ForceV1" to "0x4" in the same process

Question

conhost.exe command line changes from "0xffffffff -ForceV1" to "0x4" in the same process

Kohei Tagami 0

I am implementing read-only process monitoring on Windows. Microsoft consumer support referred me to Microsoft Q&A for clarification of this Windows API behavior.

I observed a change in the command line returned for the same conhost.exe process, while retaining the same process handle.

My main question is whether the value returned by ProcessCommandLineInformation is guaranteed to remain unchanged during a process's lifetime, including initialization.

OBSERVED BEHAVIOR

API:

NtQueryInformationProcess

Information class:

60 (ProcessCommandLineInformation)

Two queries using the same retained process handle returned different command lines. The following shows only the argument portions, not the full command lines:

First observation:

0xffffffff -ForceV1

Second observation:

0x4

Target PID:

4412

Kernel creation FILETIME:

134334373443576954

The process was identified using the same retained handle and kernel creation FILETIME, not the PID alone. The saved records also contain matching image identity and parent-process identity.

First query interval, UTC:

2026-09-09T14:22:24.358004800Z

to 2026-09-09T14:22:24.358045000Z

Second query interval, UTC:

2026-09-09T14:22:24.370504800Z

to 2026-09-09T14:22:24.370526200Z

Both queries returned NTSTATUS 0.

For each query, I saved an independent copy of the returned UTF-16LE bytes, the returned buffer length, UNICODE_STRING.Length, and the query time interval. Length was handled as a byte count, and the data was copied while the returned buffer was still valid.

I do not assume that the first observation represents the original command line at process creation.

FILE IDENTITY AND ENVIRONMENT LIMITATIONS

Executable:

C:\Windows\System32\conhost.exe

File size at the time of observation:

1003520 bytes

SHA-256 at the time of observation:

7ced551ec8afab3391a3ede5442046558e4799dcfd631ac9252fe93929a3465e

The exact Windows build/UBR and conhost.exe FileVersion/ProductVersion at the time of observation were not captured in the available records.

When the same path was checked on 2026-09-10, its size was unchanged but its SHA-256 was different. Therefore, I have not substituted the current file version for the version that was observed. The reason for the file-content change has not been established.

I recognize that this limits build-specific conclusions. Please indicate the minimum additional information needed and how it should be obtained.

HOW THE OBSERVATION WAS MADE

The conhost process was generated as part of an existing test; I did not launch conhost.exe directly for this observation.

I did not suspend the target, inject code, modify its memory, change console settings, or poll until the strings matched.

I distinguish changes to a parser's local copy of a command line from changes to the value actually returned by the process-information query.

I have not concluded that the observed transition is normal or abnormal, and I have not treated the two argument strings as equivalent.

QUESTIONS

Is there a documented guarantee that the command line returned by information class 60 remains unchanged for a given process instance, including during initialization?
Is the specific transition from "0xffffffff -ForceV1" to "0x4" an expected initialization behavior under any known Windows conditions? If so, does it reflect an update to the process command line, a change in the information returned by the query, or something else? Does the disappearance of ForceV1 imply a change in legacy/V2 selection?
If this value is not guaranteed to be immutable, what documented and supported mechanism should be used to distinguish process identity, command-line information captured at creation, and command-line state queried later? Please include relevant prerequisites and limitations.

I am seeking publicly available documentation or implementation guidance, not disclosure of private internal functions.

No full logs, credentials, or memory dumps are attached. Please specify the minimum additional evidence required.

0 comments

1 answer

Your answer

Answer 1

Hello @Kohei Tagami ,

Thank you for the detailed report and the clear repro data. I looked into this and was able to reproduce the same behavior locally, so let me share what I found along with the relevant documentation.

To give you the short answer first, there is no documentation that guarantees the command line returned by information class 60 (ProcessCommandLineInformation) is immutable for a given process, and the 0xffffffff -ForceV1 to 0x4 change you observed appears to be normal, expected initialization behavior for conhost.exe rather than a defect.

I want to explain why there is no immutability guarantee. Information class 60 (ProcessCommandLineInformation) is not listed in the official NtQueryInformationProcess reference at all. The documented classes stop at values like ProcessSubsystemInformation (75), but class 60 is not among them, so it is effectively undocumented. You can see this in NtQueryInformationProcess function (winternl.h). That same page also states in its Remarks that "The NtQueryInformationProcess function and the structures that it returns are internal to the operating system and subject to change from one release of Windows to another", and the banner notes the function "may be altered or unavailable in future versions of Windows." So even for the documented classes no stability contract is offered, and class 60 has no contract at all.

Let me also describe what the transition actually reflects. The command line reported by class 60 is read from the target process's user mode RTL_USER_PROCESS_PARAMETERS.CommandLine, which lives in the PEB. Both of these structures are documented as internal and writable, and are explicitly marked "may be altered in future versions of Windows", as you can see in PEB (winternl.h) and RTL_USER_PROCESS_PARAMETERS (winternl.h). The conhost.exe process is launched with a placeholder command line (0xffffffff -ForceV1) and, during its own early initialization, the real console handle value (0x4) is written into that PEB field and the -ForceV1 token is dropped. So to answer your sub question, it is closest to option (a): the command line data in the process is genuinely being updated in place during init, and class 60 reflects that live value. It is not a case of the query returning stale or inconsistent data, and both reads returning NTSTATUS 0 is consistent with that.

I was able to reproduce this on my side as well. On Windows 11 (build 26200.9168), by opening a newly created conhost.exe once (a single handle that I never reopened) and burst polling class 60, I captured the exact transition you described:

[t+   11 us] NTSTATUS=0  [\??\C:\Windows\system32\conhost.exe 0xffffffff -ForceV1]
[t+23648 us] NTSTATUS=0  [\??\C:\Windows\system32\conhost.exe 0x4]

The transition window is very narrow (a few milliseconds during conhost startup), which matches why it is only occasionally observed.

Based on this, my recommendation is that for a read only monitor you do not treat the class 60 command line as stable during a process's early lifetime, especially for conhost.exe. If you need a value you can rely on, it is safer to sample it after the target has finished initializing, and to treat any value read during the very first milliseconds as potentially transient. Since class 60 is undocumented, its exact behavior can also change between Windows releases.

Please let me know if a documented, supported alternative for your specific scenario would help, and I can look into options. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

RLWA32 52,816 Reputation points

2026-09-11T08:13:50.38+00:00

Includes some commentary by Raymond Chen with respect to the contractual nature of obtaining the command line arguments of a process other than your own - How do I get the command line of another process?