I have an application in C# Framework 4.0. Like many app this one connects to a data base to get information. In my case this database is SqlServer 2008 Express.

The database is in my machine

In my data layer I’m using Enterprise Library 5.0

When I publish my app in my local machine (App Pool Classic)

  • Windows Professional

  • IIS 7.5

The application works fine. I’m using this query to check the number of connections my application is creating when I’m testing it.

SELECT db_name(dbid) as DatabaseName, count(dbid) as NoOfConnections,
       loginame as LoginName
FROM sys.sysprocesses
WHERE dbid > 0 AND db_name(dbid) = 'MyDataBase'
GROUP BY dbid, loginame

When I start testing the number of connection start growing but at some point the max number of connection is 26. I think that’s ok because the app works

When I publish the app to TestMachine1

• XP Mode Virtual Machine (Windows XP Professional)

• IIS 5.1

It works fine, the behavior is the same, the number of connections to the database increment to 24 or 26, after that they stay at that point no matter what I do in the application.

The problem:

When I publish to TestMachine2 (App Pool Classic)

• Windows Server 2008 R2

• IIS 7.5

I start to test the application the number of connection to the database start to grow but this time they grow very rapidly and don’t stop growing at 24 or 26, the number of connections grow till the get to be 100 and the application stop working at that point.

I have check for any difference on the publications, especially in Windows Professional and Windows Server and they seem with the same parameters and configurations.

Any clues why this could be happening? , any suggestions?

  • 4
    Why is your App Pool set to "Classic" if this is a .NET 4.0 app? – Top__Hat Dec 6 '11 at 17:45

Sounds like you need to look into your code to find out where the connections are being opened and not closed.


I agree with the other answers that it sounds like you are not disposing a connection (or command or other disposable resource) somewhere.
Using a profiler is a good idea.
Carefully reviewing the code looking just for possible un-disposed resources can work. (It worked for us, after three reviews).
While you are testing, I would suggest adding pooling=false to your connection string. This way, when your application closes the connection it will actually close, rather than hanging around at the discretion of the pooling algorithm.


Use a memory profiler frunnning on a repro of the server to figure out where the connection objects that dont get disposed are being generated. Fix the code. Point.I havd the same in a little larger scenario (8000+ connnections within minutes). Helped me.

I now use http://memprofiler.com/ extensively - probably the bbest memroy profilder and the ONLY one I know of with an API for unit testing ;)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.