none
.Net Profiler - Issue in .Net 2.0 Framework RRS feed

  • Question

  • I instrument the web Applications hosted in IIS and get necessary metrics. My profiler works well with mostly all the web application tested so far.! But I have a web application hosted in IIS which is deployed in .Net 2.0 Framework ( Classic Mode) Application Pool. 

    In that v2.0 App Pool , my profiler is working weird. Initially , the modules were not getting loaded also the JIT callbacks were not called. 

    Later from this question, I used "COR_PRF_USE_PROFILE_IMAGES" and i was getting call backs (for instrumenting extra instructions to the functions). 

    The issue is , at the time of the initial request to the web application the w3wp.exe gets crashed by triggering in message below in Event logs .

    This makes the process to crash and again new process gets created which again gets crashed with the same message(continues for some time). After few crashes the same error seen in image comes as "Warning" and from then the process is running smoothly. 

    But when i change the App Pool's framework to v4.0 (Classic or Integrated) , the issue is not occurring and both the Application and profiler runs Smoothly..

    So what is the issue here..? Any thing related to v2.0 with profiler..? Another question is , why do i get callbacks only if i use "COR_PRF_USE_PROFILE_IMAGES" ? (I dont think the assemblies are ngenn-ed)

    Friday, April 28, 2017 5:07 AM

All replies

  • Looks like you have two problems.

    Firstly, COR_PRF_USE_PROFILE_IMAGES was not added until v4.0; so when you pass it to a v2.0 runtime, it won't know what to do with it. The closest approximation in v2.0 is to pass COR_PRF_USE_PROFILE_IMAGES and hope that no profile images have been setup (which is usually the case). You can tell that you are running in a v2.0 runtime if you can successfully query for the ICorProfilerInfo2 interface but querying for the ICorProfilerInfo3 interface returns E_NOINTERFACE.

    Secondly, it sounds like you might be leaking the handle to your log file when things go wrong. Double check the error path after opening the file and make sure that you either close it again or put it somewhere so that you can reuse it next time instead of trying to open the file again.


    Saturday, April 29, 2017 2:36 AM
  • Brian,

    I again confirmed by querying the ICORProfilerInfo3 from my profiler. But it failed.! So it is sure that the application and the profiler runs in Version 2.0.

    And only when COR_PRF_USE_PROFILE_IMAGES is there , the jit call backs and module loaded calls are being received for System.* dlls . If that mask is not set i am not getting calls from those modules. 

    Your second guess is rite, but my profiler never opens or accesses the file whichever in the event log error. That log file is created and accessed by the application. (that error is not triggered when i change the Application Pool's runtime as .Net version 4.0). 

    Tuesday, May 2, 2017 8:57 AM