none
Getting a System.ExecutionEngine exception RRS feed

  • Question

  • Hi --

    I have a program that is executing in a mixed native/managed environment.  While the program is written in C++/CLR and loads as a managed application, it quickly moves to a native execution frame and executes entirely as native code from this point on.  It moves into this native execution frame via some inline assembly code that jumps to the entry point of a virtual machine that the program has constructed in memory.  The memory it uses for this is allocated with a VirtualAlloc call that specifies Read, Write and Execute attributes for the memory allocated.  This is allocated directly through the operating system, so it has nothing to do with the .NET Managed Heap.  The code executed inside this native stack frame is entirely located inside this allocated memory as is all of the data and other resources that the code accesses. 

    This scheme has worked for years.  And I have never had any problems reading from and writing to the memory in question.  Additionally, I have never had any problems executing the assembly language code I have assembled into portions of this memory; in fact my entire execution environment is bootstrapped in this manner and has worked like a charm for the entire life of the project.  Until this week, that is.  

    All of a sudden, when I attempt to execute the following assembly language instruction on a piece of my memory I get a System.ExecutionEngine exception:

    rep movs dword ptr es:[edi],[esi]
     
    This seems to be the only instruction that is having problems.  I am able to read and write this memory without problem with other instructions -- even in the same section of code.  So, for example, the same memory I am trying to move with the rep movs instruction I manipulate on a continual basis -- both reading and writing, as it is a critical stack structure of my virtual machine.  This is the first time, however, that I am attempting to manipulate it with the rep movs instruction.  So I have to believe that there is something about this instruction that is special.  In case you're wondering I am absolutely certain that the addresses I'm putting into esi and edi are correct; I am actually looking at the memory in the memory inspector as I step over the instruction that throws the exception.

    For a split second before the state of my machine gets trashed (0s in all registers), I see a brief Visual Studio message that has the words managed and native in it; I've never been able to look at it long enough to see exactly what it is saying.  I'm not sure if this is the forum to address this issue with or if there is some better target.  But I thought I would start here.  What I would particularly like is the benefit of others' greater experience with debugging techniques/tools that might help me troubleshoot or isolate the cause of this problem.  For frankly it doesn't really make sense to me.  I mean this is a native execution stack frame working on memory that has been allocated through the operating system with read, write and execute permissions.  I really don't see why the managed execution engine should even be concerning itself with this execution at all.

    Any help would be greatly appreciated, even if it's just to direct me to a more suitable forum.

    Regards,

    Mike
    Friday, December 19, 2008 3:32 PM

Answers

  • Hi --

    Just thought I would report back my final resolution of this.  A little embarrassing, of course it turned out to be developer error.  I was attempting to move some memory and the source and destination regions of memory overlapped.  I was not understanding the behavior of the rep prefix, the movs command and the std command.  I've recoded the section and everything is fine.

    Sorry for the noise.

    Regards,

    Mike
    • Marked as answer by mclagett Sunday, December 21, 2008 4:50 AM
    Sunday, December 21, 2008 4:50 AM

All replies

  • mclagett said:

    In case you're wondering I am absolutely certain that the addresses I'm putting into esi and edi are correct

    Makes me wonder what's in the ES register.

    Hans Passant.
    Friday, December 19, 2008 6:25 PM
    Moderator
  • Es Register is the same as the DS Register, which is what both of them always are.  I'm sure that's not the problem.
    Friday, December 19, 2008 6:49 PM
  • Hi --

    Just thought I would report back my final resolution of this.  A little embarrassing, of course it turned out to be developer error.  I was attempting to move some memory and the source and destination regions of memory overlapped.  I was not understanding the behavior of the rep prefix, the movs command and the std command.  I've recoded the section and everything is fine.

    Sorry for the noise.

    Regards,

    Mike
    • Marked as answer by mclagett Sunday, December 21, 2008 4:50 AM
    Sunday, December 21, 2008 4:50 AM