none
'System.AccessViolationException' Unmanaged Dll RRS feed

  • Question

  • The situation isn't as clear cut as the previous posts (by other people) make it to be. My case differs because of the following:

    I have a C# application calling a Native C++ DLL via PInvoke.
    The symptoms of the problem are as follows:
    If I run the code, nothing breaks (Press F5).
    If I run the code and hitting a breakpoint in the code, subsequently running the code again (Press F5), nothing breaks.

    Basically I can always run the code and traverse via F5.

    If I run the code and hit a breakpoint in the unmanaged area, when I subseqently step through (press F10, or F11) I get:
    First-chance exception at 0x0926f77b in <Program Name>: 0xC0000005: Access violation.
    First-chance exception at 0x739a5015 (mscorwks.dll) in <Program Name>: 0xC0000005: Access violation reading location 0x0926f77b.
    First-chance exception at 0x739a5015 (mscorwks.dll) in <Program Name>: 0xC0000005: Access violation reading location 0x0926f77b.
    The thread 'Win32 Thread' (0x1604) has exited with code 0 (0x0).
    The thread 'Win32 Thread' (0xf00) has exited with code 0 (0x0).
    The thread 'Win32 Thread' (0x12b4) has exited with code 0 (0x0).
    A first chance exception of type 'System.AccessViolationException' occurred in <Program Name>

    Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

    Misc Junk Follows.



    Finally, lets use this example to explain the next bit of information

    1: void ManagedFunction()
    2: {
    3:        UnManagedFunction(bC.Handle, address, ref ytArray[0], bytArray.Length, ref EC);
    4: }


    10: void UnManagedFunction(UInt32 Handle, Int32 address, ref Byte bytArray, Int Length, ref Int EC)
    11: {
    12:       //blah.....
    13: }


    Note: Syntactically the entire line is correct and compiles regardless of whether I have made a mistake above.

    I (can) hit F11 on line 3 and step to line 11.
    I (Can NOT) hit F10 or F11 on line 11 as it will throw the exception.
    I (can) place a break point on line 13 and hit F5 and get to the breakpoint without error.


    The access error only appears when stepping through code. Though, stepping through the code is a necessary part of debugging I would like to fix this error if possible.
    • Edited by BlndLeadingDef Wednesday, March 10, 2010 9:02 PM Modified line numbers to maintain consistancy.
    Wednesday, March 10, 2010 6:55 PM

Answers

  • Unfortunately your situtaition is not much different from 'the other threads' about this topic. Some code (most probably unmanaged code, or a PInvoke) corrupted some data somewhere, which are important for the debugger.

    I would recommend to debug through the code in assembler (diassembly). That might help you a little bit, however it requires quite a lot of knowledge about call conventions, assembly language, etc. Moreover the stuff emitted by C++/CLI for ManagedFunction won't be easy to read.
    If you just leave it as it is, there is quite a high chance that the same issue will manifest itself someday later in a different way and it can crash the process even if you are not debugging it. If you have a consistent repro, you are quite lucky and it is a good first step.

    BTW: There is also a chance that it is caused by HW error, or it is a bug in compiler, CLR or in debugger. Without debugging through the assembly you won't know :(.

    -Karel
    Thursday, March 11, 2010 1:19 AM
    Moderator

All replies

  • Unfortunately your situtaition is not much different from 'the other threads' about this topic. Some code (most probably unmanaged code, or a PInvoke) corrupted some data somewhere, which are important for the debugger.

    I would recommend to debug through the code in assembler (diassembly). That might help you a little bit, however it requires quite a lot of knowledge about call conventions, assembly language, etc. Moreover the stuff emitted by C++/CLI for ManagedFunction won't be easy to read.
    If you just leave it as it is, there is quite a high chance that the same issue will manifest itself someday later in a different way and it can crash the process even if you are not debugging it. If you have a consistent repro, you are quite lucky and it is a good first step.

    BTW: There is also a chance that it is caused by HW error, or it is a bug in compiler, CLR or in debugger. Without debugging through the assembly you won't know :(.

    -Karel
    Thursday, March 11, 2010 1:19 AM
    Moderator
  • Thanks for your input.
    I guess when I was referring to the other threads, most had the issue where the AccessViolation was occurring and nothing was working. I examined most cases to find myself always ruling out this scenario as it doesn't throw any errors (so far *knocks on wood*)  while it's running.

    Unfortunately my assembly is very rudimentary, and worse off, it's been unused for at least a minimum of 12 years. At this point in time it'd be better off that I say I don't have any skills.

    Once again, thanks for your time. I must admit I was hoping the fact it worked while running but not by stepping would reveal a setting I had mangled with, but alas, this was not the case.
    Thursday, March 11, 2010 3:22 PM