By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,918 Members | 2,162 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,918 IT Pros & Developers. It's quick & easy.

TcpListener inherited by child processes when UseShellExecute = false

P: n/a
i'm using .NET 2.0, and i've made a lot of tests
i've come to the conclusion that TCP servers (tcplistener), started by
a father process, are somewhat inherited by child processes if using
UseShellExecute = false

why is that ?

try it ! even if the TcpListener is started *after* the
childProcess.Start, the TCP server is still registered in netstat -ao
and connectable with telnet, even if the father process stopped (or
crashed, or was killed)
As long as the child process is living, the TCP server is there, with
the old PID of the father process
When the child process ends, the TCP server disappears and telnet
connection is stopped

This is annoying because it prevent another app from listening on this
port (for example, if you stopped debugging in Visual and you want to
restart debugging your app)

can someone explain this? or is this a bug of .NET 2.0 beta ?

thanks

Nov 17 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a

"Wizou" <Wi*****@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
i'm using .NET 2.0, and i've made a lot of tests
i've come to the conclusion that TCP servers (tcplistener), started by
a father process, are somewhat inherited by child processes if using
UseShellExecute = false

why is that ?

try it ! even if the TcpListener is started *after* the
childProcess.Start, the TCP server is still registered in netstat -ao
and connectable with telnet, even if the father process stopped (or
crashed, or was killed)
As long as the child process is living, the TCP server is there, with
the old PID of the father process
When the child process ends, the TCP server disappears and telnet
connection is stopped

This is annoying because it prevent another app from listening on this
port (for example, if you stopped debugging in Visual and you want to
restart debugging your app)

can someone explain this? or is this a bug of .NET 2.0 beta ?

thanks


No, it's not a bug, it's by design.
The child process inherits all open handles of the parent process when using
Process.Start, this is the default and cannot be changed.
You can prevent this by starting the child process before you create the
TcpListerner object.

Willy.
Nov 17 '05 #2

P: n/a
Well,

Under Windows API, you could specify, either through
SECURITY_ATTRIBUTES or through a parameter to CreateProcess if your
child processes would inherit open handles or not.
I haven't find a way to do so under .NET.
I find it a security hole that child process always have access to the
father process' handles.
(and UseShellExecute = true disables some features interesting to the
father process)

I thought *starting* the TcpListener after the child process would be
enough, but I also had to move the TcpListener object creation after
it, in order to solve my problem

Olivier

Nov 17 '05 #3

P: n/a
Inline

Willy.
"Wizou" <Wi*****@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
Well,

Under Windows API, you could specify, either through
SECURITY_ATTRIBUTES or through a parameter to CreateProcess if your
child processes would inherit open handles or not.
That's right, it's the CreateProcess API argument bInheritHandles that
specifies whether you want the child to inherit open handles and this is set
to true in .NET, the SECURITY_ATTRIBUTES have nothing to do with this.
I haven't find a way to do so under .NET. If you need this you wil have to call CreateProcess using PInvoke.
I find it a security hole that child process always have access to the
father process' handles. What makes you think it's a security hole?
(and UseShellExecute = true disables some features interesting to the
father process) Not sure what features you mean here. > I thought *starting* the TcpListener after the child process would be
enough, but I also had to move the TcpListener object creation after
it, in order to solve my problem No, the handle is created with the creation of the TcpClient object.

Olivier

Nov 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.