No, I said:

Also, this part of the application is pure .Net code, unrelated to the
OCX handling, even running in another thread (each thread does a
distinct job, none of them ever touches any object or variable that
was created by the other, with a String that is initialized to a SQL
connection string as the only exception).

Or do you mean that cleanup of the unmanaged part of the winsock class
(between the CLR and win32) would _also_ be blocked if the OCXes are
not handled correctly?

I didn't mention this before, but commenting out the line that starts
the thread that does the winsock thing, completely stopped the leak.
The OCX part was still running as before, and didn't leak anything.

I said I'd see if I could create a small demo app that reproduces the
problem.  Here it is.

Just begin a new VB.Net windows app in VS 2003, and replace the
auto-generated code with the code below.  I tried to break up lines
with continuation characters where newsreaders would wrap them.

It doesn't use any COM objects so I'm sorry for leading the that
direction first (I assumed that's where the problem would be, but
assuming is always a dangerous activity ;)

As for the TcpClient, it uses it in a way as close as possible to how
the real app does is (esp. threading: what is done in separate
threads).

When I run this program on my home machine, I get the exact same
symptoms as with the other app at work, so it's not limited to one
machine.  [Both machines CLR 1.1 SP1]

The numbers below were obtained with a release build, started outside
of the VS debugger.  I never created two connections at once (i.e.
clicked the "test" button only after the previous attempt had
completely finshed, even though it will attempt as many as you click).

I watched the connections in SysInternals' TCPView to see when each
attempt started and ended, while monitoring the program's handle count
in task manager.

Handle count:
at startup: 66
after first click: 84
after connection failed: 78
after second click: 86
after connection failed: 82
after third click: 90
after connection failed: 86

The series just continues like that: I followed it as far as 94 - 90 -
98 - 94 - 102 - 98.

In my service app at work it ran into the tens of thousands, because
most of the addresses in the test setup were fictitious.
In a real life environment it would be the same, because the machines
it talks to are often switched off for the night while the service
keeps running.

Code:

Imports System.Net
Imports System.Net.Sockets
Imports System.Threading

Public Class Form1
   Inherits System.Windows.Forms.Form

#Region " Windows Form Designer generated code "

   Public Sub New()
       MyBase.New()

       'This call is required by the Windows Form Designer.
       InitializeComponent()

       'Add any initialization after the InitializeComponent() call

   End Sub

   'Form overrides dispose to clean up the component list.
   Protected Overloads Overrides Sub Dispose _
       (ByVal disposing As Boolean)

       If disposing Then
           If Not (components Is Nothing) Then
               components.Dispose()
           End If
       End If
       MyBase.Dispose(disposing)
   End Sub

   'Required by the Windows Form Designer
   Private components As System.ComponentModel.IContainer

   'NOTE: The following procedure is required
   ' by the Windows Form Designer
   'It can be modified using the Windows Form Designer.  
   'Do not modify it using the code editor.
   Friend WithEvents Label1 As System.Windows.Forms.Label
   Friend WithEvents txtIP As System.Windows.Forms.TextBox
   Friend WithEvents cmdTest As System.Windows.Forms.Button

   <System.Diagnostics.DebuggerStepThrough()> _
   Private Sub InitializeComponent()
       Me.cmdTest = New System.Windows.Forms.Button
       Me.Label1 = New System.Windows.Forms.Label
       Me.txtIP = New System.Windows.Forms.TextBox
       Me.SuspendLayout()
       '
       'cmdTest
       '
       Me.cmdTest.Location = New System.Drawing.Point(40, 48)
       Me.cmdTest.Name = "cmdTest"
       Me.cmdTest.TabIndex = 0
       Me.cmdTest.Text = "Test"
       '
       'Label1
       '
       Me.Label1.Location = New System.Drawing.Point(16, 16)
       Me.Label1.Name = "Label1"
       Me.Label1.Size = New System.Drawing.Size(16, 16)
       Me.Label1.TabIndex = 1
       Me.Label1.Text = "IP"
       '
       'txtIP
       '
       Me.txtIP.Location = New System.Drawing.Point(40, 16)
       Me.txtIP.Name = "txtIP"
       Me.txtIP.Size = New System.Drawing.Size(104, 20)
       Me.txtIP.TabIndex = 2
       Me.txtIP.Text = "10.123.234.56"
       '
       'Form1
       '
       Me.AutoScaleBaseSize = New System.Drawing.Size(5, 13)
       Me.ClientSize = New System.Drawing.Size(160, 77)
       Me.Controls.Add(Me.txtIP)
       Me.Controls.Add(Me.Label1)
       Me.Controls.Add(Me.cmdTest)
       Me.FormBorderStyle = _
           System.Windows.Forms.FormBorderStyle.FixedDialog
       Me.MaximizeBox = False
       Me.MinimizeBox = False
       Me.Name = "Form1"
       Me.Text = "IP Leak test"
       Me.ResumeLayout(False)

   End Sub

#End Region

   Private Sub cmdTest_Click(ByVal sender As System.Object, _
       ByVal e As System.EventArgs) Handles cmdTest.Click

       Dim IP As IPAddress = IPAddress.Parse(txtIP.Text)

       ' Generate new address for next attempt
       Dim NewAddr() As Byte = IP.GetAddressBytes
       For i As Integer = 3 To 0 Step -1
           NewAddr(i) += 1
           If NewAddr(i) = 255 Then
               NewAddr(i) = 1
           Else
               Exit For
           End If
       Next
       ' IPAddress constructor accepts byte array,
       ' but won't accept result of .GetAddressBytes ???
       ' txtIP.Text = New IPAddress(NewAddr).ToString
       txtIP.Text = NewAddr(0) & "." & NewAddr(1) _
           & "." & NewAddr(2) & "." & NewAddr(3)

       Dim Tester As New TestConnect(IP)
   End Sub

   Private Class TestConnect
       Private m_socket As TcpClient
       Private m_IP As IPAddress
       Private m_thr As Thread

       Public Sub New(ByVal IP As IPAddress)
           m_IP = IP
           m_thr = New Thread(AddressOf DoTest)
           m_thr.Start()
       End Sub

       Private Sub DoTest()
           Try
               m_socket = New TcpClient
               Debug.WriteLine(m_IP.ToString & ": Connecting")
               m_socket.Connect(m_IP, 1025)
           Catch ex As Exception
               Debug.WriteLine(m_IP.ToString & ": " & ex.Message)
           Finally
               Debug.WriteLine(m_IP.ToString & ": Closing")
               If Not m_socket Is Nothing Then m_socket.Close()
               m_socket = Nothing
           End Try
       End Sub
   End Class

End Class

My plea is "guilty" for using ActiveX because ActiveX was there when I
created those OCXes for use in VB6.  But I blame MS: they made it far too
easy to create an OCX in VC++ 6, compared to other (windowless) COM
projects.

MS engineers must have noticed it too, because VB6 came with OCX components
that didn't have anything to do with a UI (winsock, comm port controls).
I just modeled my code after that.

In VS6 I've always used sort of a layered approach: UI in VB6 for the ease
of design and debugging, and the real work in VC++ for the flexibility and
multithreading capability.  I switched to plain DLL's (not even COM)
instead of OCXes later, but a few of those old tarts still live and are a
bit too large to consider a rewrite :(

I wish :(

The service was starting two threads to perform two distinct functions. The
only thing they had in common is that they're using the same database.

So now I split it up to two separate services.
The part that uses the OCX runs perfectly, no trace of anything leaking.

The other one is now 100% managed code, and feels like tring to carry water
in a sieve.

The CLR profiler shows that all thread objects (per connection as in the
example) just keep existing forever.  I've been trying to find "how come"
for hours today: some reference must still exist or GC would take care of
them, but I found none.

In the code sample I posted, GC does take care of them after a while.
Maybe not as soon as I'd like, but it does.

In the service it doesn't clean them up at all, and I can't image where
there would be a remaining reference that doesn't exist in the sample.
Forcing GC didn't solve it either (not that I expected it to, but it does
shorten the time each new test has to run before I'm sure the problem still
exists).

In a desperate attempt, I'm now half way through translating it from VB to
C#, to see if looking at it in another language sheds some light.