none
How do I get ICorProfilerCallback::ModuleLoadFinished to be called? RRS feed

  • Question

  • I have a CLR profiler.  I call ICorProfilerInfo::SetEventMask and give it COR_PRF_MONITOR_MODULE_LOADS in ICorProfilerCallback::Initialize.  I set a breakpoint in Initialize and ModuleLoadFinished.  I debug an app (native & managed debugging) with the profiler attached to it.  The breakpoint in Initialize is hit, the event mask is set correctly, no exceptions are thrown, I return S_OK from Initialize.  The ModuleLoadFinished is callback breakpoint is never hit.

    I have tried COR_PRF_MONITOR_ALL and COR_PRF_ALL event masks.  I have also successfully hit breakpoints in JITCompilationStarted (in fact, I have been developing with only that callback for some time and only recently needed another callback).  I also attempted putting a __debugbreak() in ModuleLoadFinished and that did not result in a crash or break suggesting the code is never called.

    I even created a new profiler that *only* has the code necessary to get ModuleLoadFinished called:

    http://pastebin.com/XiKqnxCY
    http://pastebin.com/5f5ZvH11
    http://pastebin.com/k9EmKS8Y

    The problem reproduces on two machines, both Visual Studio 2012 Win32 debug builds, mostly default settings.  I'm sure I am just missing something terribly stupid but I have been hammering at this for a day now and can't figure out what I am missing so any help would be appreciated.

    Tuesday, March 26, 2013 6:23 PM

Answers

  • "override" is part of the C++11 spec (http://en.wikipedia.org/wiki/C%2B%2B11#Explicit_overrides_and_final)

    The only wrapping I am using is ATL.  After further research I found out that it is actually Visual Studio that is the problem.  The code in ModuleLoad is executing but breakpoints inside it are not getting hit.  __debugbreak() inside of it would result in a deadlock sometimes and other times just nothing would happen.

    I have submitted a bug report to the VS team regarding the issue.  I apologize for the bad report here, I thought the code wasn't executing but it turns out that it was.

    Monday, April 8, 2013 5:10 PM

All replies

  • I see that you just throw an exception when finshed.

    How about output a few log, rather than an exception?

    Have a nice day.


    Ghost,
    Call me ghost for short, Thanks
    To get the better answer, it should be a better question.

    Wednesday, March 27, 2013 2:56 PM
  • The throw was just for my example.  I have set breakpoints, assertions, __debugbreak(), throw, etc. all in that function and none of them are ever hit.  Meanwhile, over in JITCompilationStarted I can just set a breakpoint in Visual Studio and it is hit every time it is called.
    Wednesday, March 27, 2013 4:56 PM
  • Hi Micah,

    I hope this blog will helpful: http://blogs.msdn.com/b/davbr/archive/2010/01/18/clr-v4-profiler-attach-part-2-ok-now-what.aspx 

    If not, you can create a reproduce project and submit it as a bug: https://connect.microsoft.com/visualstudio 

    Have a nice day.


    Ghost,
    Call me ghost for short, Thanks
    To get the better answer, it should be a better question.

    Wednesday, April 3, 2013 5:07 PM
  • Hi, Micah.

    Is this still an issue for you?  I have never heard of a problem like this before.  My only guess is that whatever infrastructure you have set up to implement the ICorProfilerCallback COM object is swallowing this call somehow.  I am not familiar with the keyword "override" in C++, so I'm not exactly sure what your infrastructure is doing.  I'd advise removing extra layers between you and COM to at least eliminate possibility that it's the infrastructure getting in your way.  For example, the callbackbase object supplies its own implementation of MLF which you're presumably trying to override--is it possible you're not overriding it like you'd expect?

    Thanks,
    Dave

    Monday, April 8, 2013 3:43 PM
  • "override" is part of the C++11 spec (http://en.wikipedia.org/wiki/C%2B%2B11#Explicit_overrides_and_final)

    The only wrapping I am using is ATL.  After further research I found out that it is actually Visual Studio that is the problem.  The code in ModuleLoad is executing but breakpoints inside it are not getting hit.  __debugbreak() inside of it would result in a deadlock sometimes and other times just nothing would happen.

    I have submitted a bug report to the VS team regarding the issue.  I apologize for the bad report here, I thought the code wasn't executing but it turns out that it was.

    Monday, April 8, 2013 5:10 PM
  • Ok, thanks for the follow up!
    Monday, April 8, 2013 5:15 PM