Have a overloaded method for process.start so it does not inherit handles

Have a overloaded method for process.start so it does not inherit handles by Noktruene

Resolved

as Won't Fix Help for as Won't Fix

Type:	Bug
ID:	771517
Opened:	11/17/2012 6:33:34 PM
Access Restriction:	Public

Workaround(s)

view

User(s) can reproduce this bug

Would it be possible in the next version of .net to include an overloaded method of process.start so it DOES NOT inherit the handles of the starting process? We have a network application that is starting a child process and when it crashes the ports are not closed as the child process is still running (most cases we have to reboot the box to get the application working again).

Example:
1. Process A starts.
2. Process A opens a TCP port.
3. Process A starts Process B using System.Diagnostics.Process.Start
4. Process A terminates unexpectedly, and does not properly close its TCP port.
5. Process B maintains a copy of the handle to the TCP port.
6. As there is an existing open handle, the Operating System does not close the port when cleaning up dead resources for process A.

This URL goes it better detail

http://weblogs.asp.net/jdennany/archive/2007/08/28/leaky-abstractions-system-diagnostics-process-and-1-bottle-of-mountain-dew.aspx

Details (expand)

.NET Framework 4.5

1. Process A starts.
2. Process A opens a TCP port.
3. Process A starts Process B using System.Diagnostics.Process.Start
4. Process A terminates unexpectedly, and does not properly close its TCP port.
5. Process B maintains a copy of the handle to the TCP port.
6. As there is an existing open handle, the Operating System does not close the port when cleaning up dead resources for process A.

English

Windows Server 2008 R2

English

Process started with Process.Start always inherit handles of the parent (including network handles).

Process started with Process.Start should either not inherit handles or have overload the method not to include a switch so you can deiced not to inherit.

0 attachments

Posted by Microsoft on 2/21/2013 at 7:23 AM

Thank you for your feedback. We are not going to be able to address this issue in our next release due to other priorities.

Regards,
Immo Landwerth
.NET Framework team

Posted by Microsoft on 11/19/2012 at 9:56 PM

Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Microsoft Visual Studio Connect Support Team for triage and resolution. These specialized experts will follow-up with your issue

Posted by Microsoft on 11/19/2012 at 9:50 AM

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)