Share via

Failed to CoCreate profiler

  • Article

Sometimes support cases are like buses. You never see one and then two or three the same come along all at once. Recently one of my team mates asked me about an error his customer was getting in their event log:

Source: CLR
Category: None
Event ID: 0

Description: The description for Event ID (0) in Source (CLR) cannot be found. The local computer may not have the necessary registry information or message DLL files...
The following information is part of the event: Failed to CoCreate profiler..

I’d not come across it or at least if I had then I had forgotten it. So I had no quick answer to what might be causing it. Then the next day, a different colleague asked me about the same error for a different customer.

What is this error telling us exactly?

The error is coming from the CLR (a.k.a. the Common Language Runtime, the core engine of the .NET Framework). CoCreate here refers to the CoCreateInstance or CoCreateInstanceEx APIs which are the way in COM of creating an object instance (Remember COM, that funny thing we used to use before the days of .NET? not sure? never heard of it? you could always grab yourself a copy of “ Mr Bunny’s guide to ActiveX ” or perhaps Don Box ’s classic “ Essential COM ”).

The profiler it is referring to here is any registered CLR profiler. The CLR will check to see if a profiler is registered and load it if it is. It does this check when the process starts. The method of registration is quite simple – it looks for two environment variables COR_ENABLE_PROFILING and COR_PROFILER. If COR_ENABLE_PROFILING is set to a non-zero value then we are saying that profiling is enabled. If it is, the CLR reads the COR_PROFILER variable to find out the COM GUID of the CoClass of the profiler. You can read more here.

But if you are a non-interactive process such as the w3wp.exe that hosts ASP.NET applications, where is this environment variable defined? Well one place is along with all the other system environment variables. However that was checked – typing SET at a command prompt will show you the amalgamation of user specific environment variables for the currently logged on user as well as all the system environment variables (which apply to all processes including non-interactive processes and processes running under other user identities). 

One way you can check if a process has got a profiler active is from a memory dump taken at some time after it has started. In the !peb output you should clearly see the environment variables in effect for this process, coming from all places in which they might be defined.

One other place an environment variable can be defined for a w3wp.exe is in the environment of the Windows Service that spawns the process. In this case the customer had it defined in two places:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW3SVC
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesIISADMIN

both had a REG_MULTI_SZ value called “Environment” defined in which the two COR* environment variables were present.

Removing these (just the two variables in question, not the whole ‘Environment’ value - and carefully please – if you don’t IIS may fail to start !) fixed the problem for the customer.

Note that the reasons the specified profiler may have failed to CoCreate could be many. If could be that the profiler was uninstalled but the environment variables somehow got left behind. It could be that the profiler DLL associated with the CoClass was not registered correctly. It could be that one of the dependencies of the profiler DLL was missing (try doing a REGSVR32 on it to find out). Or perhaps there was a permissions issue accessing the profiler DLL or one of its dependencies. Process Monitor would always be a good way to trouble shoot this kind of issue.

I’ve seen “forgotten” profilers cause other issues over the years. For example, I’ve seen them cause slows downs on production systems because customers had either forgotten or never knew that someone had installed a profiler. I’ve seen them interfere with line number alignment when performing interactive debugging with Visual Studio in test environments. All sorts. Profilers are very useful and have their place but you have to remember where you have installed and enabled them.

By the way, searching for this error on the web only pops up a handful of hits so it would not appear to be very common:

Forum posting about “Failed to CoCreate profiler”
RedGate Software article about this error in relation to their profiler

So maybe it was just coincidence that I came across this problem two days in a row!

HTH

Doug

Comments

  • Anonymous
    September 16, 2014
    Thank you Sir! The event log was full off errors like NET Runtime version 4.0.30319.296 - Loading profiler failed during CoCreateInstance. Profiler CLSID: '{FF68FEB9-E58A-4B75-A2B8-90CE7D915A26}'.

  • Anonymous
    September 16, 2014
    The comment has been removed

  • Anonymous
    September 16, 2014
    Thanks Narcis for the extra information!

  • Anonymous
    January 22, 2017
    Thanks

  • Anonymous
    July 04, 2017
    Removing all references to the CLSID didn't work.I have added an environment variables of COR_ENABLE_PROFILING=0 which stopped the alerts.

    • Anonymous
      July 05, 2017
      Hello Oren, thanks for sharing your experience - useful to know. The mechanism for invoking the profiler has evolved over the years and it is some time since I wrote this post.