Hi All,
  I realize this is a very peculiar situation, and I was sceptical about
this "finding" also, but after days of debugging, this is what things have
narrowed down to:

I have an app (originaly a Web app, but I am able to replicate the issue in
a WinForm app also) that calls on a 3rd party DLL through PInvoke. The
library connects to a remote 3rd party server thorough TCP/IP to perform some
EDI data processing. We started noticing that every one of these TCP
connections remain in the "CLOSE_WAIT" state until the process is shut down.
At first, we assumed it's a problem with the 3rd party ilibrary. However,
after further investigation, we found that this only happens if we connect to
a SQL server first!

 To clarify, if we use the 3rd party library without ever connecting to the
SQL server, then the TCP connections close properly in a timely manner.
However, once a SqlConnection.Open() call is made (and loaded modules in VS
show System.EnterpriseServices.dll, and System.EnterpriseServices.thunk.dll
loaded), any subsequent call to the 3rd party DLL starts to hang in the
CLOSE-WAIT state indefinitely.

 I tried to see if turning off the connection pooling would affect this,
but it did not. Please note that I do not have to run any commands agains the
database for this to occur. As long as I do SqlConnection.Open(), this
problem starts!

 I am beyong confused! I know this 3rd party DLL is written in VC++. I have
a unsubstiated theory that perhaps perhaps the SQL DLL and this 3rd party DLL
have the same base address, and the 3rd party DLL gets rebased by he OS
loader, and thus cannot be unloaded, causing the bug to appear. (I am
grabbing at straws).

Any ideas/suggestions? Please help!!!

Thanks,
Muj Beg