none
TypeLoadException class not in mscorlib RRS feed

  • Question

  • I'm getting up to speed with the .NET profiling api and trying to figure out why a TypeLoadException would report trying to load one of my classes from mscorlib. The class is clearly not in mscorlib. Do you have any advice for where to look for such a problem? One additional thing: I cannot reproduce this -- it's from someone else whose code I don't have access to.
    Thursday, May 3, 2012 5:02 PM

Answers

  • Hi,

    Activator is looking type NewReic.Agent.Core.AgentShim in wrong assembly (mscorlib). It seems this is bug from NewRelicAgent. 

    check from the thread discussion

    http://support.appharbor.com/discussions/problems/3677-intermittent-newrelic-related-type-load-errors-typeloadexception-could-not-load-type-newrelicagentcoreagentshim-from-assembly-mscorlib

    Hope this helps you..


    If this post answers your question, please click "Mark As Answer". If this post is helpful please click "Mark as Helpful".

    Monday, May 7, 2012 7:45 AM
  • ok, I've found a fix for the Type Load Exception, and that is to not use a cache of assembly tokens. We had some code that cached the assembly tokens returned from a call to IMetaDataAssemblyEmit's DefineAssemblyRef. The last parameter, as shown below, is what we were caching. Using a hash table keyed by the module ID, we stored that assembly token. 

    metaDataAssemblyEmit->DefineAssemblyRef(
    			keyECMA, keySize,
    			assemblyName, &assemblyMetaData, NULL, 0, 0, &assemblyToken));

    What is maddening is that, although removing all of the caching, and always going back to this function call to retrieve the token works, I cannot verify why it works. I logged all of the assembly tokens stored in the cache and all of the ones retrieved from the cache. Unfortunately I don't have a reliable way to validate an assembly token (like you can with a Win32 window handle). 

    Does anyone know if there is a way to reliably validate that an assembly token is still valid?

    Bob

    Wednesday, May 16, 2012 10:21 PM

All replies

  • Hi Bob,

    If there is no way to reproduce this issue, I think I have no idea about this question.

    Have a nice day.


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

    Friday, May 4, 2012 9:56 AM
  • Hi, Bob.

    We'll need a lot more information on *exactly* what you're doing to be able to offer ideas.  IL rewriting is extremely difficult and there are a lot of traps one can fall into.  The CLR rarely provides useful information to diagnose problems with IL rewriting, and typically one has to do some intense debugging to figure out where the problem lies.  In particular, you'll want to get at least a full dump from your user at the point where the exception is first thrown.  If the exception gets caught and rethrown several times, you want to investigate the point where it is first thrown.  Preferably, you'll want a reproducing scenario that you can run and investigate.

    Thanks,
    Dave

    Friday, May 4, 2012 4:09 PM
  • Thanks Dave. I have just a stack trace at this point. Here is part of it (below). I'll attempt to get more information, especially a dump so that I can do some post-mortem analysis.

    Bob

    [TypeLoadException: Could not load type 'NewRelic.Agent.Core.AgentShim' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.]
       at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(ControllerContext controllerContext, ActionDescriptor actionDescriptor, IDictionary`2 parameters)
       at System.Web.Mvc.Async.AsyncControllerActionInvoker.InvokeSynchronousActionMethod(ControllerContext controllerContext, ActionDescriptor actionDescriptor, IDictionary`2 parameters)
       at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass42.<BeginInvokeSynchronousActionMethod>b__41()
       at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass8`1.<BeginSynchronous>b__7(IAsyncResult _)
       at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResult`1.End()
       at System.Web.Mvc.Async.AsyncResultWrapper.End[TResult](IAsyncResult asyncResult, Object tag)
       at System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethod(IAsyncResult asyncResult)
       at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass37.<>c__DisplayClass39.<BeginInvokeActionMethodWithFilters>b__33()
       at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass4f.<InvokeActionMethodFilterAsynchronously>b__49()
       at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass37.<BeginInvokeActionMethodWithFilters>b__36(IAsyncResult asyncResult)
       at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResult`1.End()
       at System.Web.Mvc.Async.AsyncResultWrapper.End[TResult](IAsyncResult asyncResult, Object tag)
       at System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethodWithFilters(IAsyncResult asyncResult)
       at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass25.<>c__DisplayClass2a.<BeginInvokeAction>b__20()
       at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass25.<BeginInvokeAction>b__22(IAsyncResult asyncResult)

    Friday, May 4, 2012 4:30 PM
  • Bob 

    To repeat it try

    ngen install /Profile "mscorlib"

    and see if that helps you repeat it.

    I have started to have a few people raise issues with my own profiler due to the above command being run on their systems. It is the sort of command that would be run on a production system IMO and that would be the exact sort of environment where NewRelic would be running.

    As for a fix - i don't think there is one except to

    ngen uninstall /Profile "mscorlib"
    or to have alternative instrumentation that does not inject types into mscorlib.


    Sunday, May 6, 2012 10:00 AM
  • Some code on the stack is looking for the type in wrong assembly (mscorlib). Check out callers of Async* stuff, or the first non-Microsoft code on the stack.

    -Karel

    Monday, May 7, 2012 5:45 AM
    Moderator
  • Hi,

    Activator is looking type NewReic.Agent.Core.AgentShim in wrong assembly (mscorlib). It seems this is bug from NewRelicAgent. 

    check from the thread discussion

    http://support.appharbor.com/discussions/problems/3677-intermittent-newrelic-related-type-load-errors-typeloadexception-could-not-load-type-newrelicagentcoreagentshim-from-assembly-mscorlib

    Hope this helps you..


    If this post answers your question, please click "Mark As Answer". If this post is helpful please click "Mark as Helpful".

    Monday, May 7, 2012 7:45 AM
  • I ran the ngen command and am still not able to reproduce the problem. By the way, after running that ngen command, is a "profile-supported" version of mscorlib permanently installed or will a reboot reset it?

    Thanks for your help!

     Bob

    Friday, May 11, 2012 12:14 AM
  • I was able to reproduce the problem of a TypeLoadException. I have to be "pretending" to deploy my app by changing the web site's location using the IIS API, and hitting the site at the same time. Although this may seem like a strange thing to do, the problem is happening to my customers when they do a standard deployment. 

    I created a full dump from Microsoft's Debug Diagnostics Tool, and here is the stack it reports when I opened the dump file with WinDbg (below). I'm still not sure what is going on, but I'm suspicious that there is some form of partial name managed assembly lookup going on that is causing the problem. The reason I think this is that it happens, at least for one customer, when they have the System.Web.Mvc.dll in the same directory as the applications running, rather than in the GAC. On other servers with it in the GAC, they don't get the problem. 

    I installed ASP.NET MVC version 4 by adding the AspNetMvc NuGet package to a sample mvc application in Visual Studio. When I run the app, it works ok, even though the MVC assembly is local and not in the GAC. However, when doing my pretend deployment at the same time, I sometimes see the TypeLoadException. It's really hard to nail down exactly when it is going to happen.

    I'm continuing to look at different ways of debugging this (e.g., Process Monitor monitoring mvc assembly files) but no luck identifying the root cause yet. If anyone sees anything in this stack trace that looks suspicious, let me know.

    Thanks!

     Bob

    0:030> .ecxr
    eax=0b4fcdd8 ebx=00000005 ecx=00000005 edx=00000000 esi=0b4fce84 edi=07abe058
    eip=74a0b9bc esp=0b4fcdd8 ebp=0b4fce28 iopl=0         nv up ei pl nz ac pe nc
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216
    KERNELBASE!RaiseException+0x58:
    74a0b9bc c9              leave
    0:030> kb
      *** Stack trace for last set context - .thread/.cxr resets it
    ChildEBP RetAddr  Args to Child              
    0b4fce28 70e91140 e0434352 00000001 00000005 KERNELBASE!RaiseException+0x58
    0b4fceb8 70eabb1b 033bbbe4 00000000 00000000 clr!RaiseTheExceptionInternalOnly+0x276
    0b4fcef4 7104c5f9 0b4fdf80 06a2d430 f88f60e6 clr!UnwindAndContinueRethrowHelperAfterCatch+0x60
    0b4fcf4c 69cb7e1e 0b4fdae8 00877480 0a0006ed clr!CEEInfo::getCallInfo+0x162
    0b4fcf74 69cb8507 0a0006ed 00000000 00000019 clrjit!Compiler::eeGetCallInfo+0x39
    0b4fd66c 69cb2d28 00d03018 ffe3ac5d 00d03770 clrjit!Compiler::impImportBlockCode+0x2ffa
    0b4fd6e8 69cb2e58 00d03018 00000000 00d00010 clrjit!Compiler::impImportBlock+0xf1
    0b4fd700 69cb2ea2 00d03018 00d00010 69cb2ed3 clrjit!Compiler::impImport+0xe8
    0b4fd70c 69cb2ed3 0b4fda14 00d00010 0b4fd758 clrjit!Compiler::fgImport+0x22
    0b4fd71c 69cb32a2 0b4fd8c4 0b4fdb60 00007010 clrjit!Compiler::compCompile+0x37
    0b4fd758 69cb3396 0b4fdaa0 004fda14 0b4fd8c4 clrjit!Compiler::compCompileHelper+0x2df
    0b4fd7c8 69cb34c9 00877480 00000000 0b4fda14 clrjit!Compiler::compCompile+0x1ac
    0b4fd8a4 69cb5e4b 0b4fdaa0 0b4fda14 0b4fd8c4 clrjit!jitNativeCode+0x14e
    0b4fd8c8 70e62389 69d0c288 0b4fdaa0 0b4fda14 clrjit!CILJit::compileMethod+0x27
    0b4fd930 70e62415 017dac58 0b4fda94 0b4fda14 clr!invokeCompileMethodHelper+0x65
    0b4fd978 70e6245b 017dac58 0b4fda94 0b4fda14 clr!invokeCompileMethod+0x31
    0b4fd9e0 70e62230 017dac58 0b4fda94 0b4fda14 clr!CallCompileMethodWithSEHWrapper+0x2e
    0b4fdd9c 70e6b87b 088f22c4 07ae3ff8 00007010 clr!UnsafeJitFunction+0x3f9
    0b4fde7c 70e6ba28 07ae3ff8 00000000 f88f7146 clr!MethodDesc::MakeJitWorker+0x284
    0b4fdeec 70db52d5 088f24ac f88f70fa 0b4fe380 clr!MethodDesc::DoPrestub+0x45d
    0b4fdf50 010d0842 088f22c4 f60dd1cb 033b5d30 clr!PreStubWorker+0x12c
    WARNING: Frame IP not in any known module. Following frames may be wrong.
    0b4fdf68 091822ce 033bb9b0 033bb92c 03235bec 0x10d0842
    0b4fe068 70db530e 010d0842 088f3730 f60dd1cb 0x91822ce
    0b4fe0c4 0b4fe0e8 091818ca 00000000 033b6274 clr!PreStubWorker+0x165
    0b4fe100 091819be 033b5b0c 0b4fe14c 091818ca 0xb4fe0e8
    00000000 00000000 00000000 00000000 00000000 0x91819be

    Friday, May 11, 2012 10:17 PM
  • This callstack just says some exception is being rethrown from TypeLoader at the TypeLoader-JIT boundary ("UnwindAndContinueRethrowHelperAfterCatch"). It does not have the first chance original exception. In your case the first-chance exception dump might help us (you would have to run it under debugger with catching all first-chance exceptions).

    If it is trouble with loading partial-name assembly, FusLogVW.exe might help a bit, although in the case of mscorlib it is unlikely.

    -Karel

    Friday, May 11, 2012 10:33 PM
    Moderator
  • Thanks, Karel. I have been logging fusion log errors and although there are errors, there doesn't appear a smoking gun. I had setup Debug Diagnostics Tool to specifically catch TypeLoadExceptions (from all version of CLR) as first-chance exceptions. So I'm a little confused about your comment. 

    I will attach Visual Studio again to the w3wp.exe process, however, and turn on catching all first-chance exceptions.

    Bob

    Friday, May 11, 2012 11:13 PM
  • Hi Bob,

    How about the result?

    Have a nice day.


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

    Monday, May 14, 2012 3:20 AM
  • I'm still working on it. When I attach a debugger and cause the exception to happen, I've been able to get the debugger to break in a managed-code class method that is called by unmanaged code (that injects the byte code per the Profiler API). The exception is passed along as a parameter to this managed code method. I'm trying to trace it back to where it originates.

    Bob

    • Proposed as answer by Bob-Uva Friday, May 18, 2012 5:16 AM
    Monday, May 14, 2012 3:30 AM
  • Hi Bob,

    Is there no stack in that exception?

    Have a nice day.


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

    Wednesday, May 16, 2012 12:33 PM
  • ok, I've found a fix for the Type Load Exception, and that is to not use a cache of assembly tokens. We had some code that cached the assembly tokens returned from a call to IMetaDataAssemblyEmit's DefineAssemblyRef. The last parameter, as shown below, is what we were caching. Using a hash table keyed by the module ID, we stored that assembly token. 

    metaDataAssemblyEmit->DefineAssemblyRef(
    			keyECMA, keySize,
    			assemblyName, &assemblyMetaData, NULL, 0, 0, &assemblyToken));

    What is maddening is that, although removing all of the caching, and always going back to this function call to retrieve the token works, I cannot verify why it works. I logged all of the assembly tokens stored in the cache and all of the ones retrieved from the cache. Unfortunately I don't have a reliable way to validate an assembly token (like you can with a Win32 window handle). 

    Does anyone know if there is a way to reliably validate that an assembly token is still valid?

    Bob

    Wednesday, May 16, 2012 10:21 PM
  • Hi Bob,

    Since this issue is resolved by yourself, so please mark yourself reply as anwser and start a new thread for your further question.

    Have a nice day.


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

    Thursday, May 17, 2012 4:18 AM
  • ok, thanks, but how do I mark it as an answer?
    Friday, May 18, 2012 5:17 AM
  • ok, thanks, but how do I mark it as an answer?

    Hi Bob,

    I marked your reply as answer, so you can feel free to start a new thread.

    Thank you for posting on this forum.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, May 18, 2012 6:56 AM
    Moderator