none
Running Profiler inside certain IIS ASP.NET 4.0 apps results in error (Exception from HRESULT: 0x80131401) RRS feed

  • Question

  • I have a IL rewriting profiler which uses the profiling API to intercept JITs and writes prologue\epilogues calling a supporting C# assembly(HP.Diagnostics).

    We have been running our product(HP Diagnostics)successfully in many customer environments with success but have recently observed the following problem.

    The supporting C# Profiler Assembly(HP.Diagnostics gets the following error when running in certain IIS hosted ASP.NET (.NET 4.0) applications on Windows 2008 R2.

       System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)

    The supporting profiler DLL(HP.Diagnostics) is installed and loaded from GAC and should have full trust.

    The Profiler logs show that the supporting C# Assembly(HP.Diagnostics) is loaded in multiple application domains, first in the Appdomain of the IIS application and then the "EE Shared Assembly Repository". This seems to be the cause of the problem.

    The logs below are generated by the ICorProfilerCallback::AssemblyLoadFinished callback.

    2013.02.14.14.48.57.295  [000019C4]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(067CC730) appDomainName(/LM/W3SVC/2/ROOT-1-130053449274613565) assemblyId(06A87D00) assemblyName(HP.Diagnostics)
    2013.02.14.14.48.57.310  [000019C4]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA2862B0) appDomainName(EE Shared Assembly Repository) assemblyId(06A87EC0) assemblyName(HP.Diagnostics)
    

    How can we work around this problem ? Is there a fix for this issue ?

    In certain IIS applications, e.g. SharePoint 2013, the behavior can be altered by changing the "trust" setting as shown below in the web.config file.

    <trust level="Full" originUrl="" legacyCasModel="false" />

        <!--<trust level="Full" originUrl="" legacyCasModel="true" />-->

    This does not work for all applications so we have no work around in certain scenarios.

    Can somebody explain why changing the legacyCasModel="false"  changes the way the assemblies are loaded in different appdomains ?

    Regards,

    Sanjay


    Sanjay Mehta

    Wednesday, February 20, 2013 9:57 PM

All replies

  • I have never seen an assembly from the GAC load into a named AppDomain, in my experience they load into the SharedDomain (EE Shared Assembly Repository) on first load and are then referenced from all future app domains there.  Do you have a simple reproduction case that causes the assembly to load from the GAC into the named AppDomain rather than the SharedDomain?

    Are you explicitly loading your assembly using Assembly.Load or Assembly.LoadFrom or are you just adding a reference and letting the CLR load the assembly using its normal assembly loading procedure?

    Wednesday, February 20, 2013 10:07 PM
  • Thanks for your response.

    I just add a reference to the assembly using the IMetaDataEmit interface as part of our IL rewriting code.

    Since we are a profiling tool, we do not have control or change the application source directly(only as part of IL Rewriting), so no Assembly.Load or Assembly.LoadFrom calls. We let the CLR load the assembly using its normal assembly loading procedure.

    We do expect that our assembly(HP.Diagnostics.dll) which is installed in the GAC is always loaded in the Shared Domain (EE Shared Assembly Repository) but as described in the problem scenario above, we see that in certain cases, it is first loaded in the application Appdomain and then reloaded in the Share Domain.

    I have not been able to write a simple program to reproduce this but can easily reproduce it with a SharePoint 2013 installation and our product HP.Diagnostics. Is there a way I can attach my profiler logs showing the different way the CLR loads the assemblies with and without the legacyCasModel set?

    Regards,

    Sanjay


    Sanjay Mehta

    Wednesday, February 20, 2013 11:18 PM
  • I don't know the answer to your problem but just brainstorming:

    Is it possible that an untrusted assembly is the first thing that calls into your profiler?  For example, in a normal CLR application the first calls are going to be to mscorlib and then once everything is setup the users code is then called.  Perhaps your profiler in this situation is not instrumenting any of the calls to mscorlib or mscorlib is simply not called until later on in execution.  In this scenario (untrusted code loading trusted code) I am uncertain which application domain it would load into.

    A theoretical way to test this would be to instrument something in mscorlib that is guaranteed to be executed first (before any user code).  Something like AppDomain constructor I would imagine is called very early on in the CLR application lifecycle.  In such a scenario do you still experience the problem?

    Also, is it possible to get a CLR stack trace at the time of the crash?  You should be able to attach as a native & managed debugger to the w3wp.exe process and when the exception is thrown get dropped into a debugger and see what the call stack looks like.  I'm not sure if this will resolve your problem but it may provide additional insight into the problem.

    I have seen this problem before with my own profiler, but for me it was caused by attempting to load the assembly from outside the GAC which meant it was loaded into named AppDomain instead of the shared AppDomain.  It can also be caused if you try to load the assembly using Assembly.LoadFrom since assemblies loaded manually won't be put into the shared domain.

    Wednesday, February 20, 2013 11:28 PM
  • I don't instrument any code in mscorlib because of performance and timing issues.

    In the case of SharePoint 2013 your assumption is partially right. See the extract from the profiler log file at the bottom of this post(Log Extract from SharePoint 2013 Start-up)

    Notice that the first method to get instrumented is
    System.Void System.Data.SqlClient.SqlConnection.Open() :
    Contained in assembly System.Data
    Loaded in AppDomain(/LM/W3SVC/763985882/ROOT-1-130044868734739044)
    This triggers the load of the HP.Diagnostics assembly into the same AppDomain as this assembly(System.Data).

    Later another method gets instrumented
    System.Net.HttpWebRequest.GetRequestStream()
    Contained in assembly System
    loaded in AppDomain(EE Shared Assembly Repository).
    This triggers the re-load of the HP.Diagnostics assembly into the Shared Appdomain.

    So, I say you are partially right for 2 reasons.

    1. Don't understand why the System.Data assembly also in the GAC is loaded into the (/LM/W3SVC/763985882/ROOT-1-130044868734739044) Appdomain when <trust level="Full" originUrl="" legacyCasModel="true" />?

    2. Why does changing the web.config setting to <trust level="Full" originUrl="" legacyCasModel="false" /> change the Appdomain into which the System.Data assembly is loaded. This works around the SharePoint 2013 problem but ...

    I also have logs from a customer where the first instrumented method is in the Shared AppDomain but the HP.Diagnostics assembly gets loaded into a different AppDomain and then immediately gets re-loaded into the Shared AppDomain. see adjacent extract below, notice the appDomainIds are different.

    First instrumented method in Shared Domain Log Extract

    2013.01.25.10.49.25.325  [00001DE8]  INFO     ---- Instrumented: private final virtual hideBySig System.Void System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() ----- appDomainId(EAD362B0) assemblyId(0106BC80)    ---------------------
    2013.01.25.10.49.25.341  [00001DE8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(02663E50) appDomainName(/LM/W3SVC/2/ROOT-1-130036025557630244) assemblyId(050F7960) assemblyName(HP.Diagnostics)
    2013.01.25.10.49.25.341  [00001DE8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(EAD362B0) appDomainName(EE Shared Assembly Repository) assemblyId(050F7B20) assemblyName(HP.Diagnostics)
    ======================================================

    Log Extract from SharePoint 2013 Start-up

    2013.02.04.13.27.53.074  [00001C88]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA1C6100) appDomainName(EE Shared Assembly Repository) assemblyId(017A8340) assemblyName(System)
    2013.02.04.13.27.57.508  [00001C88]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(016C69A0) appDomainName(/LM/W3SVC/763985882/ROOT-1-130044868734739044) assemblyId(1D47DD30) assemblyName(System.Data)
    2013.02.04.13.28.01.685  [00001C88]  INFO     ---- Instrumented: public virtual hideBySig System.Void System.Data.SqlClient.SqlConnection.Open() ----- appDomainId(016C69A0) assemblyId(1D47DD30)    ---------------------
    2013.02.04.13.28.01.694  [00001C88]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(016C69A0) appDomainName(/LM/W3SVC/763985882/ROOT-1-130044868734739044) assemblyId(2AD6D110) assemblyName(HP.Diagnostics)
    2013.02.04.13.28.01.694  [00001C88]  INFO     Marking assembly as uninstrumentable.  appDomainId(016C69A0) appDomainName(/LM/W3SVC/763985882/ROOT-1-130044868734739044) assemblyId(2AD6D110) assemblyName(HP.Diagnostics)
    2013.02.04.13.28.02.047  [00001C88]  INFO     CCorProfiler::reloadDynamicProperties!
    2013.02.04.13.28.02.749  [00001C88]  INFO     ---- Instrumented: public hideBySig System.Data.SqlClient.SqlDataReader System.Data.SqlClient.SqlCommand.ExecuteReader() ----- appDomainId(016C69A0) assemblyId(1D47DD30)    ---------------------
    2013.02.04.13.28.02.753  [00001C88]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(016C69A0) appDomainName(/LM/W3SVC/763985882/ROOT-1-130044868734739044) assemblyId(2ADFB7A0) assemblyName(System.Data.OracleClient)
    2013.02.04.13.28.02.759  [00001C88]  INFO     ---- Instrumented: assembly hideBySig System.Data.SqlClient.SqlDataReader System.Data.SqlClient.SqlCommand.ExecuteReader(System.Data.CommandBehavior,System.String) ----- appDomainId(016C69A0) assemblyId(1D47DD30)    ---------------------
    2013.02.04.13.28.02.882  [00001C88]  INFO     ---- Instrumented: public virtual hideBySig System.Void System.Data.SqlClient.SqlConnection.Close() ----- appDomainId(016C69A0) assemblyId(1D47DD30)    ---------------------
    2013.02.04.13.28.02.924  [00001C88]  INFO     ---- Instrumented: public hideBySig System.Data.SqlClient.SqlDataReader System.Data.SqlClient.SqlCommand.ExecuteReader(System.Data.CommandBehavior) ----- appDomainId(016C69A0) assemblyId(1D47DD30)    ---------------------
    2013.02.04.13.28.03.162  [00001C88]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA1C6100) appDomainName(EE Shared Assembly Repository) assemblyId(2ADFB8C0) assemblyName(System.Numerics)
    2013.02.04.13.28.04.019  [00001C88]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(016C69A0) appDomainName(/LM/W3SVC/763985882/ROOT-1-130044868734739044) assemblyId(2AFE4180) assemblyName(Microsoft.Office.Access.Server)
    2013.02.04.13.28.04.073  [00001C88]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(016C69A0) appDomainName(/LM/W3SVC/763985882/ROOT-1-130044868734739044) assemblyId(2B101670) assemblyName(Microsoft.Office.Server.PowerPoint)
    2013.02.04.13.28.04.383  [00001C88]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(016C69A0) appDomainName(/LM/W3SVC/763985882/ROOT-1-130044868734739044) assemblyId(2B0FFDB0) assemblyName(Microsoft.SharePoint.IdentityModel)
    2013.02.04.13.28.04.390  [00001C88]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA1C6100) appDomainName(EE Shared Assembly Repository) assemblyId(2B0FFC90) assemblyName(SMDiagnostics)
    2013.02.04.13.28.04.722  [00001C88]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA1C6100) appDomainName(EE Shared Assembly Repository) assemblyId(2B0FF810) assemblyName(System.ServiceModel.Internals)

    thread switch!
    2013.02.04.13.28.05.256  [000008FC]  INFO     ---- Instrumented: public virtual hideBySig System.IO.Stream System.Net.HttpWebRequest.GetRequestStream() ----- appDomainId(FA1C6100) assemblyId(017A8340)    ---------------------
    2013.02.04.13.28.05.258  [000008FC]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA1C6100) appDomainName(EE Shared Assembly Repository) assemblyId(2B0FF270) assemblyName(HP.Diagnostics)
    2013.02.04.13.28.05.259  [000008FC]  INFO     Marking assembly as uninstrumentable.  appDomainId(FA1C6100) appDomainName(EE Shared Assembly Repository) assemblyId(2B0FF270) assemblyName(HP.Diagnostics)

    Regards,

    Sanjay


    Sanjay Mehta

    Thursday, February 21, 2013 12:24 AM
  • Is the case you see in the first example not the common case?  I will admit, I haven't paid that close of attention to *working* assembly loads and it wouldn't surprise me if any given assembly was first loaded into the executing AppDomain and then after loading was complete it was marked as shared.

    I believe the whole "shared AppDomain" thing is just a facade and in reality a module is loaded in a given execution context (one of the named app domains) and then the memory it is loaded into is marked as "shared" meaning that other AppDomains can read from it.  I could be totally off on this though, this is just the mental model I have built up in my head about how things work.  If this model is accurate, then seeing it load in one and then immediately into the other (shared) makes sense.  If all of the above is true then the first log exceprt of the two above is a red herring and unrelated to the problem of your assembly first loading into a named AppDomain (not shared) and then later trying to load the same assembly into the shared AppDomain.

    Thursday, February 21, 2013 12:44 AM
  • No, the common case is when the assembly get loaded once in the Shared Domain only.

    Nice Log

    2013.02.19.14.08.29.325  [000053BC]  INFO     ---- Instrumented: private final virtual hideBySig System.Void System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() ----- appDomainId(FA3B6100) assemblyId(0184DC90)    ---------------------
    2013.02.19.14.08.29.419  [000053BC]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(0FFB6870) assemblyName(HP.Diagnostics)

    ===============================================

    When the assembly is loaded multiple times in different AppDomains, we have the problem in the title of this post viz.
    System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401).

    when the assembly tries to access code in other assemblies,. A typical stack of error
    System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)
       at System.Net.HttpWebRequest.GetRequestStream()
       at Mercury.Capture.ProbeMetricsAgent.Request()

    Regards,

    Sanjay


    Sanjay Mehta

    Thursday, February 21, 2013 1:07 AM
  • Thursday, February 21, 2013 8:56 PM
  • I have looked at those articles but does not apply in these cases as the application is running in a .NET Framework version (4.0.30319.17929).

    I also checked the .NET 2.0 versions for the heck of it and they were 2.0.50727.5466 which is greater than the patched versions described in the articles (2.0.50727.5021 and 2.0.50727.4005)


    Sanjay Mehta

    Thursday, February 21, 2013 11:06 PM
  • Hi Sanjay,

    So this issue may still in current version, submit a bug.


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

    Thursday, February 28, 2013 1:29 PM
  • Hi, Sanjay.

    I'm looking into this.  I hope to be able to reply with some info for you next week.

    Thanks,
    Dave

    Saturday, March 2, 2013 2:12 AM
  • Hi, Sanjay.

    First off, which assembly is failing to load?  It appears that HP.Diagnostics is NOT failing to load, as the first shaded log in your initial post shows S_OK for AssemblyLoadFinished callbacks for the loads of HP.Diagnostics (one unshared, and one shared).  When answering this question, you should trust a native debugger like windbg more than you should trust profiler callbacks (as the profiler's load callback can be called very late in the process of loading).  I would gather a call stack (both native, and a managed one via SOS.!clrstack) when the exception is first thrown (first-chance notification).  You should then see the referring assembly on the stack, along with the method it was executing that presumably referenced the assembly that's failing to load.

    For some background, in case you haven't come across these articles, You may want to brush up on ASP.NET-specific, and CLR-general, changes in the security model that occurred with V4:

    ASP.NET: http://msdn.microsoft.com/en-us/library/dd984947(v=VS.100).aspx
    CLR: http://msdn.microsoft.com/en-us/magazine/ee677170.aspx

    I *think* that the legacyCasModel=true setting brings you back down to the older CLR / ASP.NET security model.  I believe this older security model allowed for more variations in security permission sets in a set of IIS web sites, which leads to less shareability (and generally poorer performance).  And less shareability may have caused you to avoid this issue, since it seems to be related to how the sharing decisions are made and verified.

    Two possibilities come to mind that might affect shareability of an assembly.  One is Conditional APTCA (new in CLR V4).  Search for that in this post for more info
    http://blogs.msdn.com/b/davbr/archive/2010/01/07/clr-v4-stuff-that-may-break-your-profiler.aspx.

    Another possibility is more complicated, and involves the way the CLR caches closure sets of assemblies. 

    Before reading on, please note that the following describes internal implementation details of the CLR, which are subject to change at any time without notice.  You should not rely on these details, unless you are prepared to break without warning.  I'm describing this only in the hopes that it might explain what's going on, and give you an idea how to protect your code.

    If assembly A references assembly B, and A is loaded shared, then B must be loaded shared as well.  That's pretty standard.  The interesting part comes in when the CLR verifies that it's actually ok to load B as shared by verifying that B's "closure set" (i.e.,  "the transitive closure of assemblies that B references either directly or indirectly") is the same as the closure set the CLR calculated and cached the first time B was loaded shared.  If this differs you can get that exception (that the grant sets would differ).  And the closure sets can differ if HP added an AssemblyRef to B after the CLR cached the closure set of B.

    Note that this issue does not always arise.  For example, the Default Domain will not use the cached closure set (it recalculates the closure set).  Also, if A loads before B, then neither would be shared, and this problem would not arise.

    So I think you need to be in a scenario like the following for this to happen:

    Assembly A: This is some assembly that normally gets loaded by the application (not profiler-specific).  This could be a user assembly or system assembly (e.g., System.Web.dll).  A references B.

    Assembly B: Another assembly that normally gets loaded by the application (referenced by A).  The profiler wants to instrument B.

    HP.Diagnostics: Profiler managed assembly that is shipped as part of the profiler (instrumented code calls into HP.Diagnostics).

    1. B loads naturally into non-default domain 1
      a. CLR reads and caches B’s closure.  Say the closure is empty.  [Ok, the closure always contains mscorlib, but let’s keep it simple, and assume it’s empty.]
      b. Inside ModuleLoadFinished for B, HP adds an AssemblyRef inside B’s metadata that points to HP.Diagnostics
    2. A loads naturally into non-default domain 1
      a. CLR reads and caches A’s closure: B, HP.Diagnostics.
    3. A loads naturally into non-default domain 2
      a. CLR reads and caches A’s closure: B, HP.Diagnostics.
      b. CLR compares this with the cached closure of A in domain 1 (step 2a), which is also B, HP.Diagnostics.
      c. Closures match, so A is officially shared between domains 1 & 2.
    4.  Since A depends on B, B must now load into domain 2 (and B had better be shareable).
      a. CLR reads and caches B’s closure: HP.Diagnostics
        i. The CLR sees HP.Diagnostics in B’s closure due to step 1b above.
      b. CLR compares this with the cached closure of B in domain 1 (step 1a), which is empty.
        i. Uh oh, the closures don’t match!  ({HP.Diagnostics} != empty)
      c. CLR complains that A, which is shared between 1 & 2, depends on B, which cannot be shared between 1 & 2, because of the closure mismatch.  This may well be the exception you observed (“Loading this assembly would produce a different grant set from other instances”)

    It would be helpful if you can determine exactly which assembly is failing to load (and what was triggering it to load in the first place).  That could point us in the right direction to understanding the problem, and whether it's conditional APTCA, the closure caching, or maybe even something else.

    Thanks,
    Dave

    Tuesday, March 5, 2013 6:06 PM
  • Hi Dave,
    Thanks for the response. This has been a lot to absorb and I am trying to narrow down the possibilities from what you have enumerated.

    But here are some evidences to add.

    I kind of reproduced the problem with a simple Web Aplication by setting the legacyCasModel="true" in the web.config.
     <trust level="Full" originUrl="" legacyCasModel="true" />.
    In this case the HP.Diagnostics assembly fails to access the System.Net.HttpWebRequest.GetRequestStream method.
    In this case, the Web app continues to run but the HP.Diagnostics profiler managed assembly is not able to execute the above method.
    We see the same symptoms with SharePoint and customer app.

    2013.03.07.14.29.35.566  [0012]  SEVERE          ProbeMetrics   ProbeMetricsAgent(42659827) caught exception when sending metrics to uri    System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)
       at System.Net.HttpWebRequest.GetRequestStream()
       at Mercury.Capture.ProbeMetricsAgent.Request()

    Stacks from windbg show the same information

    (5304.36b0): C++ EH exception - code e06d7363 (first chance)
    (5304.36b0): CLR exception - code e0434352 (first chance)
    (5304.58a4): Break instruction exception - code 80000003 (first chance)
    ntdll!DbgBreakPoint:
    00000000`77ab0530 cc              int     3
    0:089> sxe e06d7363
    0:089> g
    (5304.3024): C++ EH exception - code e06d7363 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    KERNELBASE!RaiseException+0x39:
    000007fe`fd9dbccd 4881c4c8000000  add     rsp,0C8h
    0:054> !lcrstack
    No export lcrstack found
    0:054> !clrstack
    OS Thread Id: 0x3024 (54)
            Child SP               IP Call Site
    0000000014e1c3e8 000007fefd9dbccd [ContextTransitionFrame: 0000000014e1c3e8]
    0000000014e1e2d8 000007fefd9dbccd [PrestubMethodFrame: 0000000014e1e2d8] System.Net.HttpWebRequest.GetRequestStream()
    0000000014e1e340 000007fe9b3ba206 Mercury.Capture.ProbeMetricsAgent.Request() [C:\SVNSrc\dotnet\src\wkld\ProbeMetricsAgent.cs @ 492]
    0000000014e1e6e0 000007fe9b3b996e Mercury.Capture.ProbeMetricsAgent.WorkItemCallback(System.Object) [C:\SVNSrc\dotnet\src\wkld\ProbeMetricsAgent.cs @ 661]
    0000000014e1e730 000007fe9b211a37 Mercury.Util.ThreadPool+WorkItem.DoWork() [C:\SVNSrc\dotnet\src\util\ThreadPool.cs @ 147]
    0000000014e1e770 000007fe9afcc619 Mercury.Util.ThreadPool+WorkerThread.DoWork() [C:\SVNSrc\dotnet\src\util\ThreadPool.cs @ 111]
    0000000014e1e810 000007fe9af433e2 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
    0000000014e1e940 000007fe9af42d4a System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
    0000000014e1e970 000007fe9af42c6f System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
    0000000014e1e9c0 000007fe9af42bcd System.Threading.ThreadHelper.ThreadStart()
    0000000014e1ecd8 000007fef9b4f713 [GCFrame: 0000000014e1ecd8]
    0000000014e1f008 000007fef9b4f713 [DebuggerU2MCatchHandlerFrame: 0000000014e1f008]
    0000000014e1f1e8 000007fef9b4f713 [ContextTransitionFrame: 0000000014e1f1e8]
    0000000014e1f3d8 000007fef9b4f713 [DebuggerU2MCatchHandlerFrame: 0000000014e1f3d8]
    0:054> k
    Child-SP          RetAddr           Call Site
    00000000`14e1bf20 000007fe`f9a341ac KERNELBASE!RaiseException+0x39
    00000000`14e1bff0 000007fe`f9fea55a MSVCR110_CLR0400!CxxThrowException+0xd4
    00000000`14e1c060 000007fe`f9d4d7e9 clr!ThrowHR+0xe7
    00000000`14e1c0c0 000007fe`f9c0f343 clr!AppDomain::LoadDomainNeutralModuleDependency+0x160
    00000000`14e1c1f0 000007fe`f9ba7430 clr!DomainFile::PropagateActivationInAppDomain+0x271
    00000000`14e1c450 000007fe`f9b9ded8 clr!DomainFile::PropagateNewActivation+0x97
    00000000`14e1c4d0 000007fe`f837d531 clr!CEEInfo::resolveToken+0x15aa
    00000000`14e1cba0 000007fe`f837c91b clrjit!GenIR::GenIR_FgCall+0x330
    00000000`14e1ccc0 000007fe`f8376ccb clrjit!ReaderBase::fgBuildPhase1+0x29b
    00000000`14e1cd90 000007fe`f837bee6 clrjit!ReaderBase::fgBuildBasicBlocksFromBytes+0x8b
    00000000`14e1cde0 000007fe`f837f22c clrjit!ReaderBase::buildFlowGraph+0x26
    00000000`14e1ce10 000007fe`f8380c65 clrjit!ReaderBase::MSILToIR+0x9c
    00000000`14e1ce70 000007fe`f8380c06 clrjit!ReadProc+0x26
    00000000`14e1d040 000007fe`f8365d27 clrjit!THX_dop2_ReadProc+0x36
    00000000`14e1d070 000007fe`f837732b clrjit!THX_dop2+0x77
    00000000`14e1d0f0 000007fe`f9c207ee clrjit!PreJit::compileMethod+0x67
    00000000`14e1d170 000007fe`f9c2073f clr!invokeCompileMethodHelper+0x6a
    00000000`14e1d1c0 000007fe`f9c2062e clr!invokeCompileMethod+0x8f
    00000000`14e1d230 000007fe`f9c2050c clr!CallCompileMethodWithSEHWrapper+0x46
    00000000`14e1d2c0 000007fe`f9b9e88a clr!UnsafeJitFunction+0x23c
    00000000`14e1d840 000007fe`f9b50971 clr!MethodDesc::MakeJitWorker+0x4ea
    00000000`14e1da90 000007fe`f9b4fecb clr!MethodDesc::DoPrestub+0xb1c
    00000000`14e1df70 000007fe`f9b024da clr!PreStubWorker+0x3eb
    00000000`14e1e270 000007fe`9b3ba206 clr!ThePreStub+0x5a
    00000000`14e1e340 000007fe`9b3b996e 0x000007fe`9b3ba206
    00000000`14e1e6e0 000007fe`9b211a37 0x000007fe`9b3b996e
    00000000`14e1e730 000007fe`9afcc619 0x000007fe`9b211a37
    00000000`14e1e770 000007fe`9af433e2 0x000007fe`9afcc619
    00000000`14e1e810 000007fe`9af42d4a 0x000007fe`9af433e2
    00000000`14e1e940 000007fe`9af42c6f 0x000007fe`9af42d4a
    00000000`14e1e970 000007fe`9af42bcd 0x000007fe`9af42c6f
    00000000`14e1e9c0 000007fe`f9b4f713 0x000007fe`9af42bcd
    00000000`14e1ea10 000007fe`f9b4f242 clr!CallDescrWorkerInternal+0x83
    00000000`14e1ea50 000007fe`f9b4f30b clr!CallDescrWorkerWithHandler+0x4a
    00000000`14e1ea90 000007fe`f9d16291 clr!MethodDescCallSite::CallTargetWorker+0x2e6
    00000000`14e1ec40 000007fe`f9bf6d80 clr!ThreadNative::KickOffThread_Worker+0x105
    00000000`14e1ee80 000007fe`f9bf6d0e clr!Frame::Push+0xa0
    00000000`14e1eec0 000007fe`f9bf6c85 clr!Frame::Pop+0x86
    00000000`14e1efc0 000007fe`f9bfadb4 clr!ManagedPerAppDomainTPCount::DispatchWorkItem+0x2bd
    00000000`14e1f050 000007fe`f9bfae46 clr!ReturnToPreviousAppDomainHolder::Init+0x39
    00000000`14e1f080 000007fe`f9bfad72 clr!Thread::DoADCallBack+0x234
    00000000`14e1f250 000007fe`f9bf6d0e clr!Frame::Push+0xd6
    00000000`14e1f290 000007fe`f9bf6c85 clr!Frame::Pop+0x86
    00000000`14e1f390 000007fe`f9bf6dbb clr!ManagedPerAppDomainTPCount::DispatchWorkItem+0x2bd
    00000000`14e1f420 000007fe`f9d16175 clr!ManagedPerAppDomainTPCount::DispatchWorkItem+0x23b
    00000000`14e1f480 000007fe`f9c866ae clr!ThreadNative::KickOffThread+0xbd
    00000000`14e1f550 00000000`7795652d clr!Thread::intermediateThreadProc+0x7d
    00000000`14e1fa10 00000000`77a8c521 kernel32!BaseThreadInitThunk+0xd
    00000000`14e1fa40 00000000`00000000 ntdll!RtlUserThreadStart+0x21


    Sanjay Mehta


    • Edited by Sanjay_HP Thursday, March 7, 2013 11:27 PM
    Thursday, March 7, 2013 11:26 PM
  • The loading sequence of Assemblies as seen by the profiler API is as follows

    2013.03.07.14.28.50.189  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(017D4950) assemblyName(System.Web)
    2013.03.07.14.28.50.215  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(017D4A70) assemblyName(System)
    2013.03.07.14.28.50.739  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(017D4B90) assemblyName(System.Configuration)
    2013.03.07.14.28.50.745  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(017D4CB0) assemblyName(System.Core)
    2013.03.07.14.28.51.136  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(017D4DD0) assemblyName(System.Xml)
    2013.03.07.14.28.51.511  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(017D4EF0) assemblyName(System.Web.Extensions)
    2013.03.07.14.28.52.763  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(017D5370) assemblyName(WindowsBase)
    2013.03.07.14.28.52.878  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(03FD9AA0) appDomainName(/LM/W3SVC/1/ROOT/CallChain-1-130071689307708572) assemblyId(017D5490) assemblyName(System.Web)
    2013.03.07.14.28.53.162  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(03FD9AA0) appDomainName(/LM/W3SVC/1/ROOT/CallChain-1-130071689307708572) assemblyId(04184FC0) assemblyName(System.Runtime.Caching)
    2013.03.07.14.28.53.379  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(03FD9AA0) appDomainName(/LM/W3SVC/1/ROOT/CallChain-1-130071689307708572) assemblyId(041850E0) assemblyName(System.Web.Extensions)
    2013.03.07.14.28.53.786  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(04185200) assemblyName(Microsoft.Build.Utilities.v4.0)
    2013.03.07.14.28.54.291  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(04184D80) assemblyName(Microsoft.JScript)
    2013.03.07.14.28.54.387  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(03FD9AA0) appDomainName(/LM/W3SVC/1/ROOT/CallChain-1-130071689307708572) assemblyId(04185B00) assemblyName(System.Web.WebPages.Deployment)
    2013.03.07.14.28.54.695  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(03FD9AA0) appDomainName(/LM/W3SVC/1/ROOT/CallChain-1-130071689307708572) assemblyId(04186400) assemblyName(App_Code.dy6yw9ye)
    2013.03.07.14.28.54.712  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(03FD9AA0) appDomainName(/LM/W3SVC/1/ROOT/CallChain-1-130071689307708572) assemblyId(017D60F0) assemblyName(System.Data)
    2013.03.07.14.28.54.746  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(03FD9AA0) appDomainName(/LM/W3SVC/1/ROOT/CallChain-1-130071689307708572) assemblyId(04185F80) assemblyName(App_global.asax.z1-swvqb)
    2013.03.07.14.28.54.905  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(03FD9AA0) appDomainName(/LM/W3SVC/1/ROOT/CallChain-1-130071689307708572) assemblyId(0FC74FC0) assemblyName(System.ServiceModel.Activation)
    2013.03.07.14.28.55.328  [00001EC8]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(0FC762E0) assemblyName(System.ServiceModel.Internals)

    2013.03.07.14.28.55.789  [0000544C]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(03FD9AA0) appDomainName(/LM/W3SVC/1/ROOT/CallChain-1-130071689307708572) assemblyId(0FC757A0) assemblyName(HP.Diagnostics)
    2013.03.07.14.28.57.249  [0000544C]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(0FC76880) assemblyName(lwcryptonet1)
    2013.03.07.14.28.57.263  [0000544C]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(0FC75320) assemblyName(BouncyCastle.Crypto)
    2013.03.07.14.28.57.412  [0000544C]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(03FD9AA0) appDomainName(/LM/W3SVC/1/ROOT/CallChain-1-130071689307708572) assemblyId(0FC76AC0) assemblyName(System.ServiceModel)
    2013.03.07.14.28.57.449  [0000544C]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(0FC75C20) assemblyName(SMDiagnostics)
    2013.03.07.14.28.57.644  [0000544C]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(03FD9AA0) appDomainName(/LM/W3SVC/1/ROOT/CallChain-1-130071689307708572) assemblyId(0FC750E0) assemblyName(System.Xaml.Hosting)
    2013.03.07.14.28.57.961  [0000544C]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(03FD9AA0) appDomainName(/LM/W3SVC/1/ROOT/CallChain-1-130071689307708572) assemblyId(0FF31860) assemblyName(App_Web_oi4brt11)
    2013.03.07.14.28.58.235  [0000544C]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(03FD9AA0) appDomainName(/LM/W3SVC/1/ROOT/CallChain-1-130071689307708572) assemblyId(0FF32040) assemblyName(System.Web.Mobile)
    2013.03.07.14.28.58.309  [0000544C]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(0FF32280) assemblyName(System.Web.RegularExpressions)
    2013.03.07.14.28.58.393  [0000544C]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(0FF32160) assemblyName(System.Drawing)
    2013.03.07.14.28.59.289  [00003024]  INFO     AssemblyLoadFinished hrStatus(00000000) appDomainId(FA3B6100) appDomainName(EE Shared Assembly Repository) assemblyId(0FF31E00) assemblyName(HP.Diagnostics)

    I was starting to think it was in the realm of tthe second option you suggested but I am running a number of tests with windbg and catching the load of all modules
    may be difficult as I am attaching to the w3wp process.
    On Occasion I have seen the APTCA warnings you mention and now I am not sure. :-(
    CLR:(C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.SharePoint.Portal\v4.0_15.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.Portal.dll) Rejecting code sharing because a dependent assembly did not match the conditional APTCA share mode
    ModLoad: 00000000`6dea0000 00000000`6e466000   C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.SharePoint.Portal\v4.0_15.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.Portal.dll

    ModLoad: 00000000`5a920000 00000000`5a9a8000   HP.Diagnostics.dll
    ModLoad: 00000000`2c070000 00000000`2c0f8000   HP.Diagnostics.dll
    ModLoad: 00000000`5b720000 00000000`5b728000   HP.RemotingCorrelation.dll
    ModLoad: 00000000`022b0000 00000000`022b8000   HP.RemotingCorrelation.dll
    ModLoad: 00000000`1d9b0000 00000000`1d9b8000   image00000000`1d9b0000
    ModLoad: 00000000`1d9c0000 00000000`1d9c8000   image00000000`1d9c0000
    ModLoad: 00000000`1d9b0000 00000000`1d9be000   image00000000`1d9b0000
    ModLoad: 00000000`1d9e0000 00000000`1d9ee000   image00000000`1d9e0000
    ModLoad: 00000000`2c710000 00000000`2c83c000   image00000000`2c710000
    ModLoad: 00000000`2c840000 00000000`2c96c000   image00000000`2c840000
    ModLoad: 00000000`1d9b0000 00000000`1d9bc000   image00000000`1d9b0000
    ModLoad: 00000000`1f390000 00000000`1f39c000   image00000000`1f390000
    ModLoad: 00000000`1d9b0000 00000000`1d9b8000   image00000000`1d9b0000
    ModLoad: 00000000`29980000 00000000`29988000   image00000000`29980000
    ModLoad: 00000000`2a980000 00000000`2a9ce000   image00000000`2a980000
    ModLoad: 00000000`2bd20000 00000000`2bd6e000   image00000000`2bd20000
    ModLoad: 00000000`2a720000 00000000`2a740000   image00000000`2a720000
    ModLoad: 00000000`2a980000 00000000`2a9a0000   image00000000`2a980000
    ModLoad: 00000000`2c710000 00000000`2c7a4000   image00000000`2c710000
    ModLoad: 00000000`2c970000 00000000`2ca04000   image00000000`2c970000
    ModLoad: 00000000`2a9a0000 00000000`2a9d0000   image00000000`2a9a0000
    ModLoad: 00000000`2bd70000 00000000`2bda0000   image00000000`2bd70000
    CLR:(C:\Windows\assembly\GAC_MSIL\HP.Diagnostics\9.21.129.48769__01ffcd81292a3125\HP.Diagnostics.dll) Rejecting code sharing because a dependent assembly did not match the conditional APTCA share mode
    ModLoad: 00000000`5a920000 00000000`5a9a8000   C:\Windows\assembly\GAC_MSIL\HP.Diagnostics\9.21.129.48769__01ffcd81292a3125\HP.Diagnostics.dll

    Thanks,
    Sanjay


    Sanjay Mehta

    Thursday, March 7, 2013 11:28 PM
  • Hi,

    For your question, you could also visit the below link to see the various paid support options that are available to better meet your needs if you requires a more in-depth level of support.

    http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone 
     

     
    Regards

    Thursday, June 6, 2013 8:53 AM
  • Hi Sanjay,

    Did you ever found a resolution to this issue? It prevents me from using any APM profiling agent for my application, as I also use the ReportViewer in local mode. Due to a performance bug in the ReportViewer component, which I don't think Microsoft is going to fix anytime soon, I need to enforce the legacy CAS model.

    But having a profiler installed and legacyCasModel=true results in the exception you mentioned in some parts of my application (e.g. when calling an external webservice) in several methods of the System.Net.HttpWebRequest class. In fact, some APM agents are even unable to contact their collecting endpoint as they probably experience the same exception internally.

    Love to hear about any progress you've made regarding this issue.

    Thanks,

    Michiel

    Friday, July 26, 2013 10:16 AM
  • While I can't speak for Sanjay, the way we dealt with this issue was to not load our assembly from the GAC into the shared domain.  Our assembly now loads into every individual application domain.  Switching to this method of loading required a lot of work so I don't really recommend it to just fix a couple customers.  Unfortunately, we needed it in order to support an entire class of customers (code running in sandboxed environments without access to the GAC) so we went through the trouble.
    Friday, July 26, 2013 4:44 PM