Failed to initialize the Common Language Runtime (CLR) v2.0.50727 with HRESULT 0×800

Failed to initialize the Common Language Runtime (CLR) v2.0.50727 with HRESULT 0×800

If you’re experiencing this issue on a Windows 2003 Server, make sure you read UPDATE 3!

So today I’m posting about an issue with SQL Server replication. This particular posting is with regards to a SQL Server 2008 Enterprise 64-bit platform and transactional replication.

The story goes like this:

I was asked to add some new tables in a published DB to the transactional publication on the publisher to get replicated to the subscriber servers. Simple request, right? Right. Wait. Wrong. Yes, the request should have been simple to action. But upon attempting to generate the publication snapshot for the subscribers to consume, the snapshot fails with the following error:

“Failed to initialize the Common Language Runtime (CLR) v2.0.50727 with HRESULT 0x80070005. You need to restart SQL server to use CLR integration features.”

Upon checking the status of the CLR (mind you we don’t have/use any CLR assemblies here and CLR is disabled on all of the servers here), it states “CLR initialization permanently failed“. I’m checking that status with:

SELECT * FROM sys.dm_clr_properties

Ok, but who cares…we don’t need CLR, right? Right. Wait. Wrong again. Microsoft is using internal CLR assemblies for replication.
How’d I fix it? Like the original error stated, restarted SQL Server. I hate that that’s the solution. Especially in a production environment. But that’s the solution. As soon as SQL starts up, and before any CLR integration is necessary, querying the state of CLR again, it’s now “loaded CLR version with mscoree“.

Ok, it’s loaded again and not “permanently failed”. So we try the snapshot again, monitoring the CLR state through the snapshot generation. Guess what…..near the end of the snapshot generation the CLR state changed from “loaded CLR version with mscoree” to “CLR is initialized” and listed the directory (C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\) and version (v2.0.50727). So it’s now allowing the internal CLR for replication to run again.

Could it be that our .NET 2.0 installation is corrupt? Possibly. The other rationale behind this behaviour, at least in many similar posts (not exactly like our situation) is that memory pressure causes the problem.

Will post back with updates as they become available.

-Patrick

Leave a Reply

Your email address will not be published. Required fields are marked *