2

I have a native Win32 application that hosts the CLR to use C# as a sophisticated 'scripting' language.

I've got a memory leak and I decided to try Microsoft's CLR Profiler to investigate. (I'm not sure if the leak is managed or not and was hoping this tool might help reveal that, for one thing.)

However, when I tell CLRProfiler to start my (native) application, although my application always within the first second or so of running starts up the CLR, CLRProfiler continues to display the prompt Waiting for application to start common language runtime even though my application is obviously running its managed code.

Is CLRProfiler only able to connect to the CLR if it was started by the stub that managed-only programs use to start the CLR, and not if the application explicitly loaded and started up MSCOREE.DLL? Or am I simply doing something wrong?

Or is there something (hopefully simple) my native application needs to do while starting the CLR to have CLRProfiler get along with it?

valiano
  • 16,433
  • 7
  • 64
  • 79
Kevin
  • 1,179
  • 7
  • 18

1 Answers1

1

I got it working, after doing two things:

  1. Using the .NET Framework 2.0 version of the CLR Profiler - there's a separate .NET Framework 1.1 version, which is the one I had found initially. It probably doesn't work with CLR 2.0 and up; and

  2. Running the CLR Profiler and application under an administrator account.

So, just to confirm, yes, the CLR Profiler (at least the Framework 2.0 version) does work for native applications hosting the CLR (it only inspects managed code, naturally.)

Kevin
  • 1,179
  • 7
  • 18