Error message when you run a Transact-SQL query that involves one or more SQL Server CLR Integration (SQLCLR) objects in SQL Server 2005: "Msg 6535" (911310)

CAUSE

• The host escalation policy causes the common language runtime (CLR) to unload the application domain.
  
  SQL Server uses the host escalation policy to change the CLR error handling behavior. Specifically, you can configure SQL Server to instruct the CLR to take a different action when SQL Server will take one action in an error condition. If an error condition is severe enough, SQL Server can instruct the CLR to unload the application domain. For example, if a CLR routine causes stack overflow or still owns a managed lock upon thread exit, the CLR routine unloads the application domain to help protect the stability of SQL Server. Therefore, this action affects other users who are running the code in the same application domain.
  
  The following code example illustrates this condition.

  public partial class StoredProcedures
  {
  	[Microsoft.SqlServer.Server.SqlProcedure]
  	public static void usp_Monitor()
  	{
  		Object obj = new Object();
  		Monitor.Enter(obj);
  	}
  	[Microsoft.SqlServer.Server.SqlProcedure]
  	public static void usp_LongRunning()
  	{
  		Thread.Sleep(Int32.MaxValue);
  	}
  }

  If you open one connection to run the usp_Monitor function, and then you open another connection to run the usp_Monitor function later, you receive the error message that is mentioned in the "Symptoms" section in the first connection. This issue occurs when the second connection unloads the application domain, because the second connection does not release the Monitor object upon thread exit. Additionally, you receive an error message that is similar to the following in the second connection:
  Server: Msg 6534, Level 16, State 49, Procedure usp_Monitor, Line 0 AppDomain CLRTest.dbo[runtime].8 was unloaded by escalation policy to ensure the consistency of your application. Application failed to release a managed lock.
• Inappropriate exception handing occurs.
  
  The following code example causes an out-of-memory error, and then the out-of-memory error causes a ThreadAbortException exception. However, the following code example tries to catch all exceptions including the ThreadAbortException exception and tries to access the SqlPipe object in the catch block.

  [Microsoft.SqlServer.Server.SqlProcedure]
  public static void usp_Test()
  {
  	try
  	{
  		byte[] b = new byte[2024 * 1024 * 1024];
  		//Do something here 
  	}
  	catch 
  	{               
  		SqlContext.Pipe.Send("failed");
  	}
  }

  This condition causes the error message that is mentioned in the "Symptoms" section. Generally, it is not a good idea to use a generic catch block to catch all exceptions. You should only catch the exceptions that you know how to handle.
• You experience the problem that is documented in Microsoft Knowledge Base article 910414.
  
  When this condition is true, parallel threads are inappropriately shut down. This problem is a bug in SQL Server, and a hotfix is available. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

  910414 FIX: You may receive an error message when you try to load data by using CLR functions in a Transact-SQL job in SQL Server 2005