Process.WaitForExit - COMException: The handle is invalid.

[Evangelink]

On vstest, we updated our logic to give some time to the process to exit (see thread #65377). And we are now seeing random failure on CI (or locally) originating from runtime.

I am not sure if this is a bug or a misuse on our side and I haven't been able to create a reproducer that would always fail.

CI log:

##[error]Unhandled Exception: System.Runtime.InteropServices.COMException: The handle is invalid. (Exception from HRESULT: 0x80070006 (E_HANDLE))
   at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)

  Passed Overloads18 [34 ms]
##[error]   at Interop.Kernel32.ProcessWaitHandle..ctor(SafeProcessHandle processHandle)
   at System.Diagnostics.Process.WaitForExitCore(Int32 milliseconds)
   at Microsoft.VisualStudio.TestPlatform.PlatformAbstractions.ProcessHelper.<>c__DisplayClass1_1.<LaunchProcess>b__4() in D:\a\1\s\src\Microsoft.TestPlatform.PlatformAbstractions\common\System\ProcessHelper.cs:line 107
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.VisualStudio.TestPlatform.PlatformAbstractions.ProcessHelper.<>c__DisplayClass1_0.<<LaunchProcess>b__3>d.MoveNext() in D:\a\1\s\src\Microsoft.TestPlatform.PlatformAbstractions\common\System\ProcessHelper.cs:line 107
--- End of stack trace from previous location where exception was thrown ---
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
   at System.Threading.ThreadPoolWorkQueue.Dispatch()

Local error:

The ProcessHelper type can be found here: https://github.com/microsoft/vstest/blob/main/src/Microsoft.TestPlatform.PlatformAbstractions/common/System/ProcessHelper.cs#L83-L118.

[ghost]

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

Issue Details

---

On vstest, we updated our logic to give some time to the process to exit (see thread #65377). And we are now seeing random failure on CI (or locally) originating from runtime.

I am not sure if this is a bug or a misuse on our side and I haven't been able to create a reproducer that would always fail.

CI log:

##[error]Unhandled Exception: System.Runtime.InteropServices.COMException: The handle is invalid. (Exception from HRESULT: 0x80070006 (E_HANDLE))
   at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)

  Passed Overloads18 [34 ms]
##[error]   at Interop.Kernel32.ProcessWaitHandle..ctor(SafeProcessHandle processHandle)
   at System.Diagnostics.Process.WaitForExitCore(Int32 milliseconds)
   at Microsoft.VisualStudio.TestPlatform.PlatformAbstractions.ProcessHelper.<>c__DisplayClass1_1.<LaunchProcess>b__4() in D:\a\1\s\src\Microsoft.TestPlatform.PlatformAbstractions\common\System\ProcessHelper.cs:line 107
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.VisualStudio.TestPlatform.PlatformAbstractions.ProcessHelper.<>c__DisplayClass1_0.<<LaunchProcess>b__3>d.MoveNext() in D:\a\1\s\src\Microsoft.TestPlatform.PlatformAbstractions\common\System\ProcessHelper.cs:line 107
--- End of stack trace from previous location where exception was thrown ---
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
   at System.Threading.ThreadPoolWorkQueue.Dispatch()

Local error:

The ProcessHelper type can be found here: https://github.com/microsoft/vstest/blob/main/src/Microsoft.TestPlatform.PlatformAbstractions/common/System/ProcessHelper.cs#L83-L118.

Author:	Evangelink
Assignees:	-
Labels:	area-System.Diagnostics.Process, untriaged
Milestone:	-

[tmds]

The exception gets thrown when calling WaitForExit. The message mentions an invalid handle.
The handle may be invalidated because Dispose was called (or is being called) on the Process instance.
Can you check you haven't disposed the process already when you are calling WaitForExit?

[danmoseley]

As an aside, it's unfortunate we throw ComException for something as general as E_HANDLE. It reminds me of #26227, but in that case the exception type is consistent across platforms and reasonable only on Windows, and in this case it's not reasonable on Windows plus it's (I guess?) not consistent across platforms. ComException is something of a catch-all in CoreCLR

runtime/src/coreclr/vm/clrex.h

Line 241 in 4019e83

// every hresult is associated with exactly one reKind (with kCOMException being the catch-all.)

[Evangelink]

@tmds @danmoseley Thank you for the prompt replies. I will look into whether or not the process was already disposed and I will add the ComException to the exceptions we catch there.

[ghost]

This issue has been marked needs-author-action since it may be missing important information. Please refer to our contribution guidelines for tips on how to report issues effectively.

[ghost]

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

[Evangelink]

Looks like we cannot really tell if it was disposed in our context so I have added a try/catch and it seems to be fine for now.