Fix StartAndForget_StartsProcessAndReturnsValidPid by mapping ProcessStartInfo.Arguments for the string+args overload

[Copilot]

StartAndForget_StartsProcessAndReturnsValidPid was failing intermittently for useProcessStartInfo: false because the test passed template.StartInfo.ArgumentList, while RemoteExecutor populates Arguments. This could launch dotnet with effectively empty/incorrect arguments and exit early.

• What changed

  • Reverted the prior SIGKILL-based liveness workaround and restored the original HasExited assertion path and cleanup.
  • Updated the useProcessStartInfo: false branch to map template.StartInfo.Arguments into List<string> and pass that list to Process.StartAndForget(string, IList<string>?).
  • Added a local argument parsing helper in StartAndForget.cs (based on the referenced logic from PR Add new process management APIs to SafeProcessHandle #124375) to split the Arguments string into a list.
  • Inlined MapToArgumentList(template.StartInfo) directly in the StartAndForget call so mapping is only computed when useProcessStartInfo is false.
  • Added a clarifying comment above MapToArgumentList explaining why this helper is needed in this test (RemoteExecutor uses Arguments, while this overload requires a list).

• Code shape

usingProcesstemplate=CreateSleepProcess((int)TimeSpan.FromHours(1).TotalMilliseconds);intpid=useProcessStartInfo?Process.StartAndForget(template.StartInfo):Process.StartAndForget(template.StartInfo.FileName,MapToArgumentList(template.StartInfo));usingProcesslaunched=Process.GetProcessById(pid);try{Assert.False(launched.HasExited);}finally{launched.Kill();launched.WaitForExit();}

• Validation
  • Ran targeted System.Diagnostics.Process tests for this area with no failures.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[adamsitnik]

@copilot address my feedback

[Copilot]

@copilot address my feedback

Addressed in b4ecac2. I applied the requested feedback to StartAndForget.cs and pushed the update.

[adamsitnik]

From the logs:

System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(useProcessStartInfo: False) [FAIL]
Assert.True() Failure
Expected: True
Actual: False
Stack Trace:
/_/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs(30,0): at System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Boolean useProcessStartInfo)
at System.Object.InvokeStub_StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Object, Span`1)
/_/src/libraries/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.cs(95,0): at System.Reflection.MethodBaseInvoker.InvokeWithOneArg(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

It fails when useProcessStartInfo: False and I think I know why. RemoteExecutor is using dotnet to invoke the process using Arguments, not ArgumentsList. When we pass the ArgumentsList here:

runtime/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs

Line 22 in b4ecac2

:Process.StartAndForget(template.StartInfo.FileName,template.StartInfo.ArgumentList);

we pass an empty string, and invoke dotnet which prints sth like this:

PS C:\Users\adsitnik> dotnet
Usage: dotnet [path-to-application]
Usage: dotnet [commands]
path-to-application:
The path to an application .dll file to execute.
commands:
-h|--help Display help.
--info Display .NET information.
--list-runtimes [--arch <arch>] Display the installed runtimes matching the host or specified architecture. Example architectures: arm64, x64, x86.
--list-sdks [--arch <arch>] Display the installed SDKs matching the host or specified architecture. Example architectures: arm64, x64, x86.

And exits. That is why the process is sometimes gone when we get to HasExited check.

@copilot please do the following:

• revert all the changes you have done here in this PR so far
• take this logic from #124375 and simply map template.StartInfo to List<string> and pass them to StartAndForget

[adamsitnik]

LGTM

[Copilot]

Pull request overview

Fixes intermittent failures in StartAndForget_StartsProcessAndReturnsValidPid by ensuring the string + args overload receives arguments derived from ProcessStartInfo.Arguments (which RemoteExecutor populates), rather than relying on ArgumentList (which may be empty).

Changes:

• Maps ProcessStartInfo.Arguments into a List<string> for the Process.StartAndForget(string, IList<string>?) path.
• Adds a local helper to split the Arguments string into an argument list for the test.

[Copilot]

StartAndForget_StartsProcessAndReturnsValidPid was failing intermittently for useProcessStartInfo: false because the test passed template.StartInfo.ArgumentList, while RemoteExecutor populates Arguments. This could launch dotnet with effectively empty/incorrect arguments and exit early.

• What changed

  • Reverted the prior SIGKILL-based liveness workaround and restored the original HasExited assertion path and cleanup.
  • Updated the useProcessStartInfo: false branch to map template.StartInfo.Arguments into List<string> and pass that list to Process.StartAndForget(string, IList<string>?).
  • Added a local argument parsing helper in StartAndForget.cs (based on the referenced logic from PR Add new process management APIs to SafeProcessHandle #124375) to split the Arguments string into a list.
  • Inlined MapToArgumentList(template.StartInfo) directly in the StartAndForget call so mapping is only computed when useProcessStartInfo is false.
  • Added a clarifying comment above MapToArgumentList explaining why this helper is needed in this test (RemoteExecutor uses Arguments, while this overload requires a list).

• Code shape

usingProcesstemplate=CreateSleepProcess((int)TimeSpan.FromHours(1).TotalMilliseconds);intpid=useProcessStartInfo?Process.StartAndForget(template.StartInfo):Process.StartAndForget(template.StartInfo.FileName,MapToArgumentList(template.StartInfo));usingProcesslaunched=Process.GetProcessById(pid);try{Assert.False(launched.HasExited);}finally{launched.Kill();launched.WaitForExit();}

• Validation
  • Ran targeted System.Diagnostics.Process tests for this area with no failures.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[adamsitnik]

@copilot address my feedback

[Copilot]

@copilot address my feedback

Addressed in b4ecac2. I applied the requested feedback to StartAndForget.cs and pushed the update.

[adamsitnik]

From the logs:

System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(useProcessStartInfo: False) [FAIL]
Assert.True() Failure
Expected: True
Actual: False
Stack Trace:
/_/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs(30,0): at System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Boolean useProcessStartInfo)
at System.Object.InvokeStub_StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Object, Span`1)
/_/src/libraries/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.cs(95,0): at System.Reflection.MethodBaseInvoker.InvokeWithOneArg(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

It fails when useProcessStartInfo: False and I think I know why. RemoteExecutor is using dotnet to invoke the process using Arguments, not ArgumentsList. When we pass the ArgumentsList here:

runtime/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs

Line 22 in b4ecac2

:Process.StartAndForget(template.StartInfo.FileName,template.StartInfo.ArgumentList);

we pass an empty string, and invoke dotnet which prints sth like this:

PS C:\Users\adsitnik> dotnet
Usage: dotnet [path-to-application]
Usage: dotnet [commands]
path-to-application:
The path to an application .dll file to execute.
commands:
-h|--help Display help.
--info Display .NET information.
--list-runtimes [--arch <arch>] Display the installed runtimes matching the host or specified architecture. Example architectures: arm64, x64, x86.
--list-sdks [--arch <arch>] Display the installed SDKs matching the host or specified architecture. Example architectures: arm64, x64, x86.

And exits. That is why the process is sometimes gone when we get to HasExited check.

@copilot please do the following:

• revert all the changes you have done here in this PR so far
• take this logic from #124375 and simply map template.StartInfo to List<string> and pass them to StartAndForget

[adamsitnik]

LGTM

[Copilot]

Pull request overview

Fixes intermittent failures in StartAndForget_StartsProcessAndReturnsValidPid by ensuring the string + args overload receives arguments derived from ProcessStartInfo.Arguments (which RemoteExecutor populates), rather than relying on ArgumentList (which may be empty).

Changes:

• Maps ProcessStartInfo.Arguments into a List<string> for the Process.StartAndForget(string, IList<string>?) path.
• Adds a local helper to split the Arguments string into an argument list for the test.

[Copilot]

StartAndForget_StartsProcessAndReturnsValidPid was failing intermittently for useProcessStartInfo: false because the test passed template.StartInfo.ArgumentList, while RemoteExecutor populates Arguments. This could launch dotnet with effectively empty/incorrect arguments and exit early.

• What changed

  • Reverted the prior SIGKILL-based liveness workaround and restored the original HasExited assertion path and cleanup.
  • Updated the useProcessStartInfo: false branch to map template.StartInfo.Arguments into List<string> and pass that list to Process.StartAndForget(string, IList<string>?).
  • Added a local argument parsing helper in StartAndForget.cs (based on the referenced logic from PR Add new process management APIs to SafeProcessHandle #124375) to split the Arguments string into a list.
  • Inlined MapToArgumentList(template.StartInfo) directly in the StartAndForget call so mapping is only computed when useProcessStartInfo is false.
  • Added a clarifying comment above MapToArgumentList explaining why this helper is needed in this test (RemoteExecutor uses Arguments, while this overload requires a list).

• Code shape

usingProcesstemplate=CreateSleepProcess((int)TimeSpan.FromHours(1).TotalMilliseconds);intpid=useProcessStartInfo?Process.StartAndForget(template.StartInfo):Process.StartAndForget(template.StartInfo.FileName,MapToArgumentList(template.StartInfo));usingProcesslaunched=Process.GetProcessById(pid);try{Assert.False(launched.HasExited);}finally{launched.Kill();launched.WaitForExit();}

• Validation
  • Ran targeted System.Diagnostics.Process tests for this area with no failures.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[adamsitnik]

@copilot address my feedback

[Copilot]

@copilot address my feedback

Addressed in b4ecac2. I applied the requested feedback to StartAndForget.cs and pushed the update.

[adamsitnik]

From the logs:

System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(useProcessStartInfo: False) [FAIL]
Assert.True() Failure
Expected: True
Actual: False
Stack Trace:
/_/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs(30,0): at System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Boolean useProcessStartInfo)
at System.Object.InvokeStub_StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Object, Span`1)
/_/src/libraries/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.cs(95,0): at System.Reflection.MethodBaseInvoker.InvokeWithOneArg(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

It fails when useProcessStartInfo: False and I think I know why. RemoteExecutor is using dotnet to invoke the process using Arguments, not ArgumentsList. When we pass the ArgumentsList here:

runtime/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs

Line 22 in b4ecac2

:Process.StartAndForget(template.StartInfo.FileName,template.StartInfo.ArgumentList);

we pass an empty string, and invoke dotnet which prints sth like this:

PS C:\Users\adsitnik> dotnet
Usage: dotnet [path-to-application]
Usage: dotnet [commands]
path-to-application:
The path to an application .dll file to execute.
commands:
-h|--help Display help.
--info Display .NET information.
--list-runtimes [--arch <arch>] Display the installed runtimes matching the host or specified architecture. Example architectures: arm64, x64, x86.
--list-sdks [--arch <arch>] Display the installed SDKs matching the host or specified architecture. Example architectures: arm64, x64, x86.

And exits. That is why the process is sometimes gone when we get to HasExited check.

@copilot please do the following:

• revert all the changes you have done here in this PR so far
• take this logic from #124375 and simply map template.StartInfo to List<string> and pass them to StartAndForget

[adamsitnik]

LGTM

[Copilot]

Pull request overview

Fixes intermittent failures in StartAndForget_StartsProcessAndReturnsValidPid by ensuring the string + args overload receives arguments derived from ProcessStartInfo.Arguments (which RemoteExecutor populates), rather than relying on ArgumentList (which may be empty).

Changes:

• Maps ProcessStartInfo.Arguments into a List<string> for the Process.StartAndForget(string, IList<string>?) path.
• Adds a local helper to split the Arguments string into an argument list for the test.

[Copilot]

StartAndForget_StartsProcessAndReturnsValidPid was failing intermittently for useProcessStartInfo: false because the test passed template.StartInfo.ArgumentList, while RemoteExecutor populates Arguments. This could launch dotnet with effectively empty/incorrect arguments and exit early.

• What changed

  • Reverted the prior SIGKILL-based liveness workaround and restored the original HasExited assertion path and cleanup.
  • Updated the useProcessStartInfo: false branch to map template.StartInfo.Arguments into List<string> and pass that list to Process.StartAndForget(string, IList<string>?).
  • Added a local argument parsing helper in StartAndForget.cs (based on the referenced logic from PR Add new process management APIs to SafeProcessHandle #124375) to split the Arguments string into a list.
  • Inlined MapToArgumentList(template.StartInfo) directly in the StartAndForget call so mapping is only computed when useProcessStartInfo is false.
  • Added a clarifying comment above MapToArgumentList explaining why this helper is needed in this test (RemoteExecutor uses Arguments, while this overload requires a list).

• Code shape

usingProcesstemplate=CreateSleepProcess((int)TimeSpan.FromHours(1).TotalMilliseconds);intpid=useProcessStartInfo?Process.StartAndForget(template.StartInfo):Process.StartAndForget(template.StartInfo.FileName,MapToArgumentList(template.StartInfo));usingProcesslaunched=Process.GetProcessById(pid);try{Assert.False(launched.HasExited);}finally{launched.Kill();launched.WaitForExit();}

• Validation
  • Ran targeted System.Diagnostics.Process tests for this area with no failures.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[adamsitnik]

@copilot address my feedback

[Copilot]

@copilot address my feedback

Addressed in b4ecac2. I applied the requested feedback to StartAndForget.cs and pushed the update.

[adamsitnik]

From the logs:

System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(useProcessStartInfo: False) [FAIL]
Assert.True() Failure
Expected: True
Actual: False
Stack Trace:
/_/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs(30,0): at System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Boolean useProcessStartInfo)
at System.Object.InvokeStub_StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Object, Span`1)
/_/src/libraries/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.cs(95,0): at System.Reflection.MethodBaseInvoker.InvokeWithOneArg(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

It fails when useProcessStartInfo: False and I think I know why. RemoteExecutor is using dotnet to invoke the process using Arguments, not ArgumentsList. When we pass the ArgumentsList here:

runtime/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs

Line 22 in b4ecac2

:Process.StartAndForget(template.StartInfo.FileName,template.StartInfo.ArgumentList);

we pass an empty string, and invoke dotnet which prints sth like this:

PS C:\Users\adsitnik> dotnet
Usage: dotnet [path-to-application]
Usage: dotnet [commands]
path-to-application:
The path to an application .dll file to execute.
commands:
-h|--help Display help.
--info Display .NET information.
--list-runtimes [--arch <arch>] Display the installed runtimes matching the host or specified architecture. Example architectures: arm64, x64, x86.
--list-sdks [--arch <arch>] Display the installed SDKs matching the host or specified architecture. Example architectures: arm64, x64, x86.

And exits. That is why the process is sometimes gone when we get to HasExited check.

@copilot please do the following:

• revert all the changes you have done here in this PR so far
• take this logic from #124375 and simply map template.StartInfo to List<string> and pass them to StartAndForget

[adamsitnik]

LGTM

[Copilot]

Pull request overview

Fixes intermittent failures in StartAndForget_StartsProcessAndReturnsValidPid by ensuring the string + args overload receives arguments derived from ProcessStartInfo.Arguments (which RemoteExecutor populates), rather than relying on ArgumentList (which may be empty).

Changes:

• Maps ProcessStartInfo.Arguments into a List<string> for the Process.StartAndForget(string, IList<string>?) path.
• Adds a local helper to split the Arguments string into an argument list for the test.

[Copilot]

StartAndForget_StartsProcessAndReturnsValidPid was failing intermittently for useProcessStartInfo: false because the test passed template.StartInfo.ArgumentList, while RemoteExecutor populates Arguments. This could launch dotnet with effectively empty/incorrect arguments and exit early.

• What changed

  • Reverted the prior SIGKILL-based liveness workaround and restored the original HasExited assertion path and cleanup.
  • Updated the useProcessStartInfo: false branch to map template.StartInfo.Arguments into List<string> and pass that list to Process.StartAndForget(string, IList<string>?).
  • Added a local argument parsing helper in StartAndForget.cs (based on the referenced logic from PR Add new process management APIs to SafeProcessHandle #124375) to split the Arguments string into a list.
  • Inlined MapToArgumentList(template.StartInfo) directly in the StartAndForget call so mapping is only computed when useProcessStartInfo is false.
  • Added a clarifying comment above MapToArgumentList explaining why this helper is needed in this test (RemoteExecutor uses Arguments, while this overload requires a list).

• Code shape

usingProcesstemplate=CreateSleepProcess((int)TimeSpan.FromHours(1).TotalMilliseconds);intpid=useProcessStartInfo?Process.StartAndForget(template.StartInfo):Process.StartAndForget(template.StartInfo.FileName,MapToArgumentList(template.StartInfo));usingProcesslaunched=Process.GetProcessById(pid);try{Assert.False(launched.HasExited);}finally{launched.Kill();launched.WaitForExit();}

• Validation
  • Ran targeted System.Diagnostics.Process tests for this area with no failures.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[adamsitnik]

@copilot address my feedback

[Copilot]

@copilot address my feedback

Addressed in b4ecac2. I applied the requested feedback to StartAndForget.cs and pushed the update.

[adamsitnik]

From the logs:

System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(useProcessStartInfo: False) [FAIL]
Assert.True() Failure
Expected: True
Actual: False
Stack Trace:
/_/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs(30,0): at System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Boolean useProcessStartInfo)
at System.Object.InvokeStub_StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Object, Span`1)
/_/src/libraries/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.cs(95,0): at System.Reflection.MethodBaseInvoker.InvokeWithOneArg(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

It fails when useProcessStartInfo: False and I think I know why. RemoteExecutor is using dotnet to invoke the process using Arguments, not ArgumentsList. When we pass the ArgumentsList here:

runtime/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs

Line 22 in b4ecac2

:Process.StartAndForget(template.StartInfo.FileName,template.StartInfo.ArgumentList);

we pass an empty string, and invoke dotnet which prints sth like this:

PS C:\Users\adsitnik> dotnet
Usage: dotnet [path-to-application]
Usage: dotnet [commands]
path-to-application:
The path to an application .dll file to execute.
commands:
-h|--help Display help.
--info Display .NET information.
--list-runtimes [--arch <arch>] Display the installed runtimes matching the host or specified architecture. Example architectures: arm64, x64, x86.
--list-sdks [--arch <arch>] Display the installed SDKs matching the host or specified architecture. Example architectures: arm64, x64, x86.

And exits. That is why the process is sometimes gone when we get to HasExited check.

@copilot please do the following:

• revert all the changes you have done here in this PR so far
• take this logic from #124375 and simply map template.StartInfo to List<string> and pass them to StartAndForget

[adamsitnik]

LGTM

[Copilot]

Pull request overview

Fixes intermittent failures in StartAndForget_StartsProcessAndReturnsValidPid by ensuring the string + args overload receives arguments derived from ProcessStartInfo.Arguments (which RemoteExecutor populates), rather than relying on ArgumentList (which may be empty).

Changes:

• Maps ProcessStartInfo.Arguments into a List<string> for the Process.StartAndForget(string, IList<string>?) path.
• Adds a local helper to split the Arguments string into an argument list for the test.

[Copilot]

StartAndForget_StartsProcessAndReturnsValidPid was failing intermittently for useProcessStartInfo: false because the test passed template.StartInfo.ArgumentList, while RemoteExecutor populates Arguments. This could launch dotnet with effectively empty/incorrect arguments and exit early.

• What changed

  • Reverted the prior SIGKILL-based liveness workaround and restored the original HasExited assertion path and cleanup.
  • Updated the useProcessStartInfo: false branch to map template.StartInfo.Arguments into List<string> and pass that list to Process.StartAndForget(string, IList<string>?).
  • Added a local argument parsing helper in StartAndForget.cs (based on the referenced logic from PR Add new process management APIs to SafeProcessHandle #124375) to split the Arguments string into a list.
  • Inlined MapToArgumentList(template.StartInfo) directly in the StartAndForget call so mapping is only computed when useProcessStartInfo is false.
  • Added a clarifying comment above MapToArgumentList explaining why this helper is needed in this test (RemoteExecutor uses Arguments, while this overload requires a list).

• Code shape

usingProcesstemplate=CreateSleepProcess((int)TimeSpan.FromHours(1).TotalMilliseconds);intpid=useProcessStartInfo?Process.StartAndForget(template.StartInfo):Process.StartAndForget(template.StartInfo.FileName,MapToArgumentList(template.StartInfo));usingProcesslaunched=Process.GetProcessById(pid);try{Assert.False(launched.HasExited);}finally{launched.Kill();launched.WaitForExit();}

• Validation
  • Ran targeted System.Diagnostics.Process tests for this area with no failures.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[adamsitnik]

@copilot address my feedback

[Copilot]

@copilot address my feedback

Addressed in b4ecac2. I applied the requested feedback to StartAndForget.cs and pushed the update.

[adamsitnik]

From the logs:

System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(useProcessStartInfo: False) [FAIL]
Assert.True() Failure
Expected: True
Actual: False
Stack Trace:
/_/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs(30,0): at System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Boolean useProcessStartInfo)
at System.Object.InvokeStub_StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Object, Span`1)
/_/src/libraries/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.cs(95,0): at System.Reflection.MethodBaseInvoker.InvokeWithOneArg(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

It fails when useProcessStartInfo: False and I think I know why. RemoteExecutor is using dotnet to invoke the process using Arguments, not ArgumentsList. When we pass the ArgumentsList here:

runtime/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs

Line 22 in b4ecac2

:Process.StartAndForget(template.StartInfo.FileName,template.StartInfo.ArgumentList);

we pass an empty string, and invoke dotnet which prints sth like this:

PS C:\Users\adsitnik> dotnet
Usage: dotnet [path-to-application]
Usage: dotnet [commands]
path-to-application:
The path to an application .dll file to execute.
commands:
-h|--help Display help.
--info Display .NET information.
--list-runtimes [--arch <arch>] Display the installed runtimes matching the host or specified architecture. Example architectures: arm64, x64, x86.
--list-sdks [--arch <arch>] Display the installed SDKs matching the host or specified architecture. Example architectures: arm64, x64, x86.

And exits. That is why the process is sometimes gone when we get to HasExited check.

@copilot please do the following:

• revert all the changes you have done here in this PR so far
• take this logic from #124375 and simply map template.StartInfo to List<string> and pass them to StartAndForget

[adamsitnik]

LGTM

[Copilot]

Pull request overview

Fixes intermittent failures in StartAndForget_StartsProcessAndReturnsValidPid by ensuring the string + args overload receives arguments derived from ProcessStartInfo.Arguments (which RemoteExecutor populates), rather than relying on ArgumentList (which may be empty).

Changes:

• Maps ProcessStartInfo.Arguments into a List<string> for the Process.StartAndForget(string, IList<string>?) path.
• Adds a local helper to split the Arguments string into an argument list for the test.

[Copilot]

StartAndForget_StartsProcessAndReturnsValidPid was failing intermittently for useProcessStartInfo: false because the test passed template.StartInfo.ArgumentList, while RemoteExecutor populates Arguments. This could launch dotnet with effectively empty/incorrect arguments and exit early.

• What changed

  • Reverted the prior SIGKILL-based liveness workaround and restored the original HasExited assertion path and cleanup.
  • Updated the useProcessStartInfo: false branch to map template.StartInfo.Arguments into List<string> and pass that list to Process.StartAndForget(string, IList<string>?).
  • Added a local argument parsing helper in StartAndForget.cs (based on the referenced logic from PR Add new process management APIs to SafeProcessHandle #124375) to split the Arguments string into a list.
  • Inlined MapToArgumentList(template.StartInfo) directly in the StartAndForget call so mapping is only computed when useProcessStartInfo is false.
  • Added a clarifying comment above MapToArgumentList explaining why this helper is needed in this test (RemoteExecutor uses Arguments, while this overload requires a list).

• Code shape

usingProcesstemplate=CreateSleepProcess((int)TimeSpan.FromHours(1).TotalMilliseconds);intpid=useProcessStartInfo?Process.StartAndForget(template.StartInfo):Process.StartAndForget(template.StartInfo.FileName,MapToArgumentList(template.StartInfo));usingProcesslaunched=Process.GetProcessById(pid);try{Assert.False(launched.HasExited);}finally{launched.Kill();launched.WaitForExit();}

• Validation
  • Ran targeted System.Diagnostics.Process tests for this area with no failures.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[adamsitnik]

@copilot address my feedback

[Copilot]

@copilot address my feedback

Addressed in b4ecac2. I applied the requested feedback to StartAndForget.cs and pushed the update.

[adamsitnik]

From the logs:

System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(useProcessStartInfo: False) [FAIL]
Assert.True() Failure
Expected: True
Actual: False
Stack Trace:
/_/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs(30,0): at System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Boolean useProcessStartInfo)
at System.Object.InvokeStub_StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Object, Span`1)
/_/src/libraries/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.cs(95,0): at System.Reflection.MethodBaseInvoker.InvokeWithOneArg(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

It fails when useProcessStartInfo: False and I think I know why. RemoteExecutor is using dotnet to invoke the process using Arguments, not ArgumentsList. When we pass the ArgumentsList here:

runtime/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs

Line 22 in b4ecac2

:Process.StartAndForget(template.StartInfo.FileName,template.StartInfo.ArgumentList);

we pass an empty string, and invoke dotnet which prints sth like this:

PS C:\Users\adsitnik> dotnet
Usage: dotnet [path-to-application]
Usage: dotnet [commands]
path-to-application:
The path to an application .dll file to execute.
commands:
-h|--help Display help.
--info Display .NET information.
--list-runtimes [--arch <arch>] Display the installed runtimes matching the host or specified architecture. Example architectures: arm64, x64, x86.
--list-sdks [--arch <arch>] Display the installed SDKs matching the host or specified architecture. Example architectures: arm64, x64, x86.

And exits. That is why the process is sometimes gone when we get to HasExited check.

@copilot please do the following:

• revert all the changes you have done here in this PR so far
• take this logic from #124375 and simply map template.StartInfo to List<string> and pass them to StartAndForget

[adamsitnik]

LGTM

[Copilot]

Pull request overview

Fixes intermittent failures in StartAndForget_StartsProcessAndReturnsValidPid by ensuring the string + args overload receives arguments derived from ProcessStartInfo.Arguments (which RemoteExecutor populates), rather than relying on ArgumentList (which may be empty).

Changes:

• Maps ProcessStartInfo.Arguments into a List<string> for the Process.StartAndForget(string, IList<string>?) path.
• Adds a local helper to split the Arguments string into an argument list for the test.

[Copilot]

StartAndForget_StartsProcessAndReturnsValidPid was failing intermittently for useProcessStartInfo: false because the test passed template.StartInfo.ArgumentList, while RemoteExecutor populates Arguments. This could launch dotnet with effectively empty/incorrect arguments and exit early.

• What changed

  • Reverted the prior SIGKILL-based liveness workaround and restored the original HasExited assertion path and cleanup.
  • Updated the useProcessStartInfo: false branch to map template.StartInfo.Arguments into List<string> and pass that list to Process.StartAndForget(string, IList<string>?).
  • Added a local argument parsing helper in StartAndForget.cs (based on the referenced logic from PR Add new process management APIs to SafeProcessHandle #124375) to split the Arguments string into a list.
  • Inlined MapToArgumentList(template.StartInfo) directly in the StartAndForget call so mapping is only computed when useProcessStartInfo is false.
  • Added a clarifying comment above MapToArgumentList explaining why this helper is needed in this test (RemoteExecutor uses Arguments, while this overload requires a list).

• Code shape

usingProcesstemplate=CreateSleepProcess((int)TimeSpan.FromHours(1).TotalMilliseconds);intpid=useProcessStartInfo?Process.StartAndForget(template.StartInfo):Process.StartAndForget(template.StartInfo.FileName,MapToArgumentList(template.StartInfo));usingProcesslaunched=Process.GetProcessById(pid);try{Assert.False(launched.HasExited);}finally{launched.Kill();launched.WaitForExit();}

• Validation
  • Ran targeted System.Diagnostics.Process tests for this area with no failures.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[adamsitnik]

@copilot address my feedback

[Copilot]

@copilot address my feedback

Addressed in b4ecac2. I applied the requested feedback to StartAndForget.cs and pushed the update.

[adamsitnik]

From the logs:

System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(useProcessStartInfo: False) [FAIL]
Assert.True() Failure
Expected: True
Actual: False
Stack Trace:
/_/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs(30,0): at System.Diagnostics.Tests.StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Boolean useProcessStartInfo)
at System.Object.InvokeStub_StartAndForgetTests.StartAndForget_StartsProcessAndReturnsValidPid(Object, Span`1)
/_/src/libraries/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.cs(95,0): at System.Reflection.MethodBaseInvoker.InvokeWithOneArg(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

It fails when useProcessStartInfo: False and I think I know why. RemoteExecutor is using dotnet to invoke the process using Arguments, not ArgumentsList. When we pass the ArgumentsList here:

runtime/src/libraries/System.Diagnostics.Process/tests/StartAndForget.cs

Line 22 in b4ecac2

:Process.StartAndForget(template.StartInfo.FileName,template.StartInfo.ArgumentList);

we pass an empty string, and invoke dotnet which prints sth like this:

PS C:\Users\adsitnik> dotnet
Usage: dotnet [path-to-application]
Usage: dotnet [commands]
path-to-application:
The path to an application .dll file to execute.
commands:
-h|--help Display help.
--info Display .NET information.
--list-runtimes [--arch <arch>] Display the installed runtimes matching the host or specified architecture. Example architectures: arm64, x64, x86.
--list-sdks [--arch <arch>] Display the installed SDKs matching the host or specified architecture. Example architectures: arm64, x64, x86.

And exits. That is why the process is sometimes gone when we get to HasExited check.

@copilot please do the following:

• revert all the changes you have done here in this PR so far
• take this logic from #124375 and simply map template.StartInfo to List<string> and pass them to StartAndForget

[adamsitnik]

LGTM

[Copilot]

Pull request overview

Fixes intermittent failures in StartAndForget_StartsProcessAndReturnsValidPid by ensuring the string + args overload receives arguments derived from ProcessStartInfo.Arguments (which RemoteExecutor populates), rather than relying on ArgumentList (which may be empty).

Changes:

• Maps ProcessStartInfo.Arguments into a List<string> for the Process.StartAndForget(string, IList<string>?) path.
• Adds a local helper to split the Arguments string into an argument list for the test.