Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have 3 SQL Server instances running on our server (dont ask why)!

2xSQL Server 2008 Workgroup (Default and MSSQLServer2) 1xSQL Server Express 2008 R2 (sqlexpress)

Now I have a Windows Service/App that runs a process in the background. The databases are pretty much the same, however whenever I try and run the service on the MSSQLServer2 instance NHibernate throws an exception.

I have checked my connections strings and it seems fine, as I've been able to copy the others, to be sure.

I've reset the account password I am using and checked that I can connected to it using Management Studio with the new creds.

I dont know what else to test. The app loads (as it creates a Log4View entry) but as soon as it makes its first NHibernate request it crashes, with a the following dump and no additional event log:

Description: Stopped working

Problem signature: Problem Event Name: CLR20r3 Problem Signature 01: R2K3ITVW3VUVRUM1CITUNG1NSZBMATAX
Problem Signature 02:
Problem Signature 03: 4de87428
Problem Signature 04: NHibernate
Problem Signature 05:
Problem Signature 06: 4639a07f
Problem Signature 07: 2ad Problem Signature 08: 78 Problem Signature 09: NHibernate.LazyInitialization OS Version: 6.0.6001. Locale ID: 2057

Read our privacy statement:

share|improve this question

As you mentioned, the log event does not give much information.

LazyInitialization exceptions are thrown if objects are not fully instantiated. Usually, I would expect an error message like cannot connect to the database. Hence, I expect some flaws in the code. At least, I assume that it is not properly checked whether a connection to the database was established successfully before doing other hibernate stuff like instantiating objects.

After talking about some more code-centric stuff, let's consider the cause and possible workarounds. My eye caught one difference: you encounter exceptions only when connecting the the non-default instance. I guess, this one is not on the standard port (1433).

Maybe the port number is hard coded (1433)? It looks as if the applications works only with default instances. You could try to manually configure your instance MSSQLServer2 to use port 1433, just for troubleshooting. Are there config files or registry entries where to specify the port number? Or is the port number given in the connection string? Should the application be really hard coded to use the default instance and / or port 1433, there is in my opinion nothing that you can do as an administrator to make it working with the second instance.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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