On one of the testing machines (XP sp2, .NET 2.0) I'm seeinga "Failed to CoCreate profiler"error in the Application event log when trying to profile an ASP.NET application. I've checked the access rights for the SYSTEM and ASPNET accounts and they look ok, the profiler is registered properly and any user mode application (not services)are profiled OK. The same code works on other machines without problems for ASP.NET applications too.

I've used RegMon to see what aspnet_wp does and the profiling keys (COR_ENABLE_PROFILING and COR_PROFILER) are read properly but the process doesn't make any attempts to actually instantiate the component (I cannot see any read for HKCR \CLSID \<My component>). Debugging the worker process shows the profiler DLL is not loaded into the process at all.

Any ideas what else I should try ? How can get a more detailed error explanation or at least an error codebecause the event log message is not very helpful

Thanks

Paul

Hi, Paul. The only supported way to invoke a profiler is by setting environment variables (using system environment variables for services). You may find other methods that work for you, but they may not always work and we don't support them. So you may want to eliminate that variable first, and set system environment variables and do a full reboot of the box.

Otherwise, if that's not the problem, then from what you're telling me, this smells very much like a security issue. If the CLR isn't even getting to the point of successfully reading the registry keys (much less loading your profiler's module), it sounds likely that the account under which the CLR is loaded is unable to access the registry keys. There are a bunch of security settings in IIS Manager that allow you to control the identity of various application pools, the account to impersonate for web sites, and there are also the accounts under which the services run. I'd go through each one to verify which accounts are actually in use. For example, on my own box I see an account not mentioned in this thread("Network Service") as the account under which the application pool runs.

Hi, Paul. First off, please make sure to reboot the box after setting the system environment variables COR_ENABLE_PROFILING and COR_PROFILER (note that you want to set system, not user, environment variables). asp.net reads its envvars from a cache, and a full reboot of the entire box is often necessary to ensure asp.net is seeing the latest.

You said "I cannot see any read for HKCR \CLSID \<My component>". The CLR should attempt to look for the CLSID under HKLM\Software\Classes and HKCU\Software\Classes. HKCR is sort of a logical view that combines both of those paths, so I'm not sure whether RegMon will report reads under HKCR or the HKLM & HKCR paths.

You might try temporarily granting all accounts used by IIS & asp.net admin privileges just to rule out a security issue. (Don't forget to restore the original privileges when you're done!)

Finally, is this a 64 bit box by chance? 64 bit Windows complicates the issue further by having 64-bit and 32-bit versions of the Classes keys (see http://blogs.msdn.com/davbr/archive/2006/11/13/wow64-and-your-profiler.aspx).

As for better diagnostics--you're right that the existing event log entries could be more helpful. Unfortunately, there isn't a way to request that the CLR give more verbose diagnostics for profiler loading.

Hi David,

Currently I'm not using the system environment variables but the registry keys from SOFTWARE/Microsfot/.NETFramework (I've also tried directly setting the env vars in HKLM\System\CurrentControlSet\Control\Session Manager\Environment but that doesn't make any difference for ASP.NET).

The test machine is 32 bit and RegMon does log access to HKCR because that's how I've tried to debug - by doing a diff between the "bad" a "good" machine. I'm not sure what other access rights should I grant to ASPNET and IIS users because HKCR looks good to me, they should have read rights. They also have full access to the folder where the profiler is installed.
What else should I look for?

Thanks

Paul

Hi, Paul. The only supported way to invoke a profiler is by setting environment variables (using system environment variables for services). You may find other methods that work for you, but they may not always work and we don't support them. So you may want to eliminate that variable first, and set system environment variables and do a full reboot of the box.

Otherwise, if that's not the problem, then from what you're telling me, this smells very much like a security issue. If the CLR isn't even getting to the point of successfully reading the registry keys (much less loading your profiler's module), it sounds likely that the account under which the CLR is loaded is unable to access the registry keys. There are a bunch of security settings in IIS Manager that allow you to control the identity of various application pools, the account to impersonate for web sites, and there are also the accounts under which the services run. I'd go through each one to verify which accounts are actually in use. For example, on my own box I see an account not mentioned in this thread("Network Service") as the account under which the application pool runs.

This is rather all an old post, but I did ran into the same problem.

I my case I was testing the Softprodigy profiler and it was giving me the same error.

When reading about to register the profiler, I didsome research on the web. On several places, they were talking about registering thexxx.Core.xxx dll from the profiler.

So I did register my dll again with the regsrv32 and this was the solution, the profiler did do his job now.

You actually don't need to restart the system to hook to ASP.NET. All you need to do is restart IIS. Here is the code I use to hook/unhookmy profiler. You can simply call Run() and Stop(). The PROJECT_NAME and LOG_FILENAME are related to my own profiler and are not used by the .net profiling api.

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Win32;
using System.Diagnostics;

namespace ASPProfiler
{
delegate void ProfilerStartHandler();
delegate void ProfilerEndHandler();

class ProfilerRunner
{

#region *** Fields ***
private string m_profilerGuid;
private string m_logFile;
private string m_projectName;
#endregion

#region *** Events ***
public event ProfilerStartHandler Start;
public event ProfilerEndHandler End;
#endregion

#region *** Constructor ***
public ProfilerRunner(string profilerGuid, string logFile, string projectName)
{
m_profilerGuid = profilerGuid;
m_logFile = logFile;
m_projectName = projectName;
}
#endregion

#region *** Methods ***

#region *** Public ***
public void Run()
{
SetRegistry();
StartIISreset();

AnnounceStart();
}

public void Stop()
{
DeleteRegistry();
StartIISreset();

AnnounceEnd();
}
#endregion

#region *** Private ***
private void SetRegistry()
{
using (RegistryKey regKey = Microsoft.Win32.Registry.LocalMachine.OpenSubKey(@"SYSTEM\CurrentControlSet\Control\Session Manager\Environment", true))
{
regKey.SetValue("COR_PROFILER", m_profilerGuid, RegistryValueKind.String);
regKey.SetValue("COR_ENABLE_PROFILING", "1", RegistryValueKind.String);
regKey.SetValue("LOG_FILENAME", m_logFile, RegistryValueKind.String);
regKey.SetValue("PROJECT_NAME", m_projectName, RegistryValueKind.String);
}
}

private void DeleteRegistry()
{
using (RegistryKey regKey = Microsoft.Win32.Registry.LocalMachine.OpenSubKey(@"SYSTEM\CurrentControlSet\Control\Session Manager\Environment", true))
{
regKey.DeleteValue("COR_PROFILER");
regKey.DeleteValue("COR_ENABLE_PROFILING");
regKey.DeleteValue("LOG_FILENAME");
regKey.DeleteValue("PROJECT_NAME");
}
}

private void StartIISreset()
{
ProcessStartInfo pStartInfo;

pStartInfo = new ProcessStartInfo("iisreset.exe");

Process p = new Process();
p.StartInfo = pStartInfo;
p.Start();
p.WaitForExit();
}

private void AnnounceStart()
{
if (Start != null)
Start();
}

private void AnnounceEnd()
{
if (End != null)
End();
}
#endregion

#endregion

}
}