Problems using the Profiler API

[yegor-pelykh]

These are more questions about using the Profiler API, rather than a bug report.

I don't know where one can contact the dotnet developers directly, also I didn't find information about this in the documentation and on the internet, so the best way I've found is here.

Could you please clarify these two things, which are important to me (and I suspect also to many others):

1. How can we debug a DLL that contains a profiler class (that implements the ICorProfilerCallback) and a class factory (that implements the IClassFactory) in Visual Studio, so as not to attach the debugger to an already running process, but to gain control immediately when loading the DLL?
   I'd like to have control at the very beginning of the execution of the DllGetClassObject callback inside the DLL. It will already be executed if we simply attach to the process.
   Could you help find a way to do this please?

2. Does process profiling run if the process is under debug in Visual Studio?
   I did the following test: placed the MessageBox call at the very beginning of DllGetClassObject.
   If I start a dotnet process, I see the message box shown.
   But if I start debugging the same process under the Visual Studio debugger, message box is not shown.
   It seems that the DllGetClassObject function is not called when debugging.
   But I can't check this because I can't find the answer to question 1.
   Could you help and clarify this please?

[dotnet-policy-service]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

[EgorBo]

How can we debug a DLL that contains a profiler class (that implements the ICorProfilerCallback) and a class factory (that implements the IClassFactory) in Visual Studio, so as not to attach the debugger to an already running process, but to gain control immediately when loading the DLL?

Just put a breakpoint function in your profiler code ( __debugbreak()) so when it's hit you attach and continue?

Another option is you can open your MSVC project with the profiler and modify project's settings to run your dotnet app as a command line on debug.

[yegor-pelykh]

Hi @EgorBo,
Yes, both of these methods work in the general case of DLL debugging.
When the debuggable dotnet process loads this DLL using LoadLibrary, I can get into DLL's DllMain under the debugger by changing the debugger settings, as you described.

But that doesn't work in the case I'm asking about, concerning specifically debugging the DllGetClassObject function and the profiler inside the DLL, which was loaded into the process by the CLR environment during the profiling process.
As far as I understand it, the DLL is loaded not by the process itself, but by the CLR environment.
And I can't get inside the DllGetClassObject function.
Maybe I'm seeing it wrong, but anyway I can't get into DllGetClassObject function using these options.

[yegor-pelykh]

I'll probably say something stupid, but now after restarting Visual Studio everything works.
I think the reason was that I had set the CORECLR_* environment variables and they weren't being "applied" correctly to Visual Studio process and its debugger.
So now it works and I close this issue.
Thanks for trying to help!