Debugging Your Profiler I: Activation

Interesting Finds: December 12, 2007

Jason Haley — Wed, 12 Dec 2007 18:11:57 GMT

re: Debugging Your Profiler I: Activation

Alex — Thu, 13 Dec 2007 00:52:30 GMT

Hi David,

thank you for the article. We've been developing .NET monitoring solution based on profiler API for a few years so far and we had a couple of cases when profiler just did not start in the customer environment. Both times we've seen this in MCMS 2002 environment. MCMS installs additional ISAPI filters etc.. So may be that was the reason. It is interesting, though, that both times there were no errors from CLR (and that usually happens when CLR has not enough permissions or it can not find profiler for some other reason). And the last time we have confirmed that both env variables are in w3wp process, mscorlib is there.. And still it looked like CLR did not even try to load the profiler. Any chance you've passed through such a scenario?

Thank you,

Alex

re: Debugging Your Profiler I: Activation

davbr — Thu, 13 Dec 2007 01:41:36 GMT

Hi, Alex! It's hard for me to imagine likely causes of what you described, other than what's already in this post. It is true that, in extreme out-of-memory conditions, the CLR won't even bother to try loading your profiler. But these are really extreme--this is when the OS heap manager simply refuses any more requests. So I'd expect you'd see much worse problems if that were the case. Also, I wonder if the CLR itself is simply not loaded into your worker process until the first request it services (I forget if the worker process loads the CLR on startup, or only lazily at first request time). Certainly, if the CLR isn't loaded yet, then your profiler won't either.

re: Debugging Your Profiler I: Activation

Mithun — Thu, 13 Dec 2007 04:37:49 GMT

Very nice and informative post.

In my experience, the most common causes of profiler load failures are -

1. Forgetting to register your COM profiler DLL using regsvr32.

2. Incorrectly implementing your COM profiler DLL's DllRegisterServer() method.

3. Not setting the required environment variables or setting them incorrectly.

Very very rarely have I seen a profiler load failure because of a CLR bug.

re: Debugging Your Profiler I: Activation

Alex — Fri, 04 Jan 2008 19:59:27 GMT

Hi David,

Thanks for the answer. I was out for vacation, then Christmas etc.. The interesting thing is that CLR was loaded. We've checked presense of mscorlib.dll in the process so definetely it should be there. Ok.. Hopefully we'll not see this again)

-Alex

re: Debugging Your Profiler I: Activation

Sriram Devadas — Fri, 03 Oct 2008 22:17:55 GMT

Hi David,

I wrote a profiler (using the API) to trace calls filtered for our namespaces.

It works well on my development box. I can trace our ASP.NET parts of the program (which communicate with some legacy VB6 components).

When I move the program to a perf box - I have no problem tracing a simple .NET console application. All the env variables are set and the profiler works fine.

However for some reason - when I instantiate our program (in dllhost.exe) - the profiler does produce any trace. The same thing works fine on my dev box.

As far as I know the programs running on both boxes are built the same way. A difference is that the perf box runs Win2k3 R2 server while I run XP on my dev box.

Would you have any pointers for me?

Thanks,

Sriram

re: Debugging Your Profiler I: Activation

davbr — Fri, 03 Oct 2008 22:45:33 GMT

Hello, Sriram. Would you please post your question on our forum here?

http://social.msdn.microsoft.com/forums/en-US/netfxtoolsdev/threads/

That’s the best way to ensure we track your question and get it answered.

Thanks,

Dave