Tracking stray connections using profiler.  Times when this can come into play is in multithreaded apps, or apps where you may be supporting simultanious users like in an ASP.NET application. 

Generally any time you are asking resources from the server it should be using the Try... Catch... Finally pattern for allocating server resources and releasing them as soon as you know you can do without them.  (Nod to Andy Rich on Deterministic Finalization)

One thing that is going to help with this however is to set the appname in your connection string (Application Name={1};) for filtering the Profiler results.

So here is a Profiler trace useful for keeping an eye logins, logouts and stored procs executed inbetween:

Download: deepdark.net_Connection_Monitor_20060112.zip

Something I have been giving thought to is that the .NET Framework exposes perfmon counters for all manner of useful stats. 

An unlikely tool?  Not so much... Of particular use is the feature where perfmon can track exceptions thrown throughout all managed apps or, alternatively for any chosen running managed application.  You can then compare the number of Finally blocks hit after an exception was reached (there is a counter specifically for this!) vs. exceptions thrown.  In normal conditions I don't think I'd like these todiffer significantly.

Really this is using perfmon to track stats from .NET apps provided by the framework; but performance isn't far from the surface.  Throwing and Catching exceptions is a very costly operation for the Framework and is a significant performance hit to a running application.

Three things, and some links: 

1. You don't have to be looking at your dev machine.  If you have administrative access to a test server you can remotely watch any perfmon counters.  Useful if your application runs as a service or for ASP.NET applications. 

Also, create a shortcut to perfmon.exe in your System32 directory to get to quick access to the Run As... command for those running their developer environment with least privilege (nod on this to Don Kiely, Michael Howard).

2. If you need to track these in a running app like a Windows Service or a ASP.NET application consider using MRTG to graph

the results for you.  I've used this before as a make-shift NMS console monitoring server system health. It's more secure than SNMP and very low on resource use.

The official MRTG site has the basics for setting up MRTG on Windows, but Castellan has a _{(slightly dated)} but much more relevant guide.

3. Consider logman to configure the Performance Monitor service.  Again this is worth a blog post by itself.  Open a command prompt and logman /? for more

Where to next?  One day I'd like to automate perfmon logging as part of an NUnit test harness to give another measure of quality parallel to Nunit.  I'll keep you posted.