none
Unusual MSIL fault RRS feed

  • Question

  • We have code that gens a dynamic method to do some special reflection on fields in classes.

    The IL begins by declaring and instance using: DeclareLocal (type);

    The method does other stuff too looking at fields and so on.

    Now ocassionally the app just dies, no exceptions nothing just stops executing even under debug.

    I narrowed this down and discovered that it only fails like this if the type we are using for this DynamicMethod operation, is a class that inherits MarshalByRefObject.

    If this is absent we have no probs, but as soon as it is present on a class we get the brutal crash in the dynamic method.

    So my question: is it wrong to instantiate the class using DeclareLocal ? should classes like this be created some other way?

    Next question: is there a way to trap an exception and see exactly why/where the MSIL is faulting?

     

    Thanks

    Cap'n

     

     

    Friday, April 9, 2010 4:49 PM

Answers

All replies

  • 1. DeclareLocal will not create/instantiate class, it just declares a variable of that type. It is perfectly fine to do it.
    2. I am not sure what kind of trap you have in your mind. I'd just: attach native debugger, look at the last exceptions thrown (incl. first-chance exceptions), use Microsoft symbol server and check out the call stacks.

    Good way to resolve issues like this is to save your dynamic IL into a module and run peverify to see if the IL is correct/verifiable.

    -Karel

    Friday, April 9, 2010 5:50 PM
    Moderator
  • 1. DeclareLocal will not create/instantiate class, it just declares a variable of that type. It is perfectly fine to do it.
    2. I am not sure what kind of trap you have in your mind. I'd just: attach native debugger, look at the last exceptions thrown (incl. first-chance exceptions), use Microsoft symbol server and check out the call stacks.

    Good way to resolve issues like this is to save your dynamic IL into a module and run peverify to see if the IL is correct/verifiable.

    -Karel


    Hmm

    Thanks for these comments, they are helpful. Is it not possible to "see" exceptions that are thrown inside a DynamicMethod? if so that's pretty poor in my view. I will try the native debugger suggestion though when I net get to look at the code.

    Thanks

    Cap'n

     

    Sunday, April 11, 2010 10:32 AM
  • Well, of course you can attach also managed debugger and look at the exception - I just assumed you already did that. There is nothing special about exceptions from dynamic code (except that source code is missing, but that is not issue of exceptions).

    -Karel

    Sunday, April 11, 2010 6:51 PM
    Moderator
  • Well, of course you can attach also managed debugger and look at the exception - I just assumed you already did that. There is nothing special about exceptions from dynamic code (except that source code is missing, but that is not issue of exceptions).

    -Karel


    Well I run the app under debug and it just dies, period. I see no exceptions (the debugger is set to break on ANY exception) it just terminates. I have tried putting try/catch around the dynamic method's delegate invocation and again nothing, no exceptions are seen or caught. Something is happening during the execution of the MSIL that causes the process to immediately and silently end.

    So I can't see any exceptions, I was hoping that a native debugger WOULD see an exception, I will try when I am next at my desk.

    Cap'n

     

    Monday, April 12, 2010 9:48 AM
  • Silent crash means there's some bad AV or other really bad exception. Native debugger (e.g. windbg) should be able to stop at that point - it did for me so far at least.

    -Karel

    Monday, April 12, 2010 5:52 PM
    Moderator
  • Silent crash means there's some bad AV or other really bad exception. Native debugger (e.g. windbg) should be able to stop at that point - it did for me so far at least.

    -Karel


    Yes it is a bad exception.

    It is at times like this that I wonder why there is no ability to debug IL code in VS 2008, one could perhaps disable JIT and just debug IL like one can debug x86 assembler, this is a big drawback when using Dynamic Methods.

    Cap'n

     

    Monday, April 12, 2010 10:25 PM
  • I believe you can debug IL via mdbg.

    The difficulties of debugging Dynamic Methods and RefEmitted code is a known problem. In the old days when these features were created it probably wasn't clear if users will use it as heavily as today. Adding good debugging experience at this point is unfortunately quite big investment as the original design didn't bother with it. CLR has that feature as one of its priorities. However note that it doesn't say anything about VS support, etc.

    Another point of view is that CLR team tries to move out from dynamic methods to unloadable assemblies.

    -Karel

    Tuesday, April 13, 2010 1:32 AM
    Moderator
  • I believe you can debug IL via mdbg.

    The difficulties of debugging Dynamic Methods and RefEmitted code is a known problem. In the old days when these features were created it probably wasn't clear if users will use it as heavily as today. Adding good debugging experience at this point is unfortunately quite big investment as the original design didn't bother with it. CLR has that feature as one of its priorities. However note that it doesn't say anything about VS support, etc.

    Another point of view is that CLR team tries to move out from dynamic methods to unloadable assemblies.

    -Karel


    OK I have more.

    During execution of the delegate on 32-bit XP we see ExecutionEngineException.

    There is somethig in the abstract class MarshalByRefObject that is leading to this.

    I created a tiny class with the same attributes [Serializable, ComVisible(true)], made it abstract, and gave it a single private field of type Object.

    Neeither that class or classes derived from it, cause the same error.

    The puzzling thing is that MarshalByRefObject also has just one filed like this (many methods properties though).

    Frustratingly, this exception does not have any further info for me, like opcode, or offset within IL stream or anything.

    So something specific to MarshalByRefObject causes this BUT we ONLY look at fields in our IL we dont look at methods/properties so this is most puzzling.

    Cap'n

    Wednesday, April 14, 2010 6:38 PM
  • Hi Captain,

        I am writing to check the status of the thread. How is your problem going on?


    Please mark the right answer at right time.
    Thanks,
    Sam
    Friday, April 16, 2010 10:01 AM
  • Either try to run your app in partial trust (that will verify the IL first and report unverifiable error), or as I mentioned before: "save your dynamic IL into a module and run peverify to see if the IL is correct/verifiable". I don't know about any better way.

    -Karel

    Friday, April 16, 2010 3:49 PM
    Moderator
  • Here is debugging Managed Codegen 

     

    http://blogs.msdn.com/yirutang/archive/2005/05/26/422373.aspx - Shows a example to debug

    http://blogs.msdn.com/yirutang/archive/2006/06/07/621125.aspx -   

    The second one is tool check the LCG instructions

     

    Though these were written way back. I guess this would be handy.

     

     


    Thanks Naveen http://naveensrinivasan.com
    Friday, April 16, 2010 8:01 PM
  • Either try to run your app in partial trust (that will verify the IL first and report unverifiable error), or as I mentioned before: "save your dynamic IL into a module and run peverify to see if the IL is correct/verifiable". I don't know about any better way.

    -Karel

    OK This is fixed now, it was due (but I'm not yet clear why) to not using a Mkrefany instruction to convert an object's address into a pointer. It seems to be fine now and working as expected.

     

    Thanks

    Hugh

     

    Saturday, April 17, 2010 12:53 PM