Handling exception from unmanaged dll in C#

Question

I have the following function written in C#

public static string GetNominativeDeclension(string surnameNamePatronimic)
{
    if(surnameNamePatronimic == null) 
       throw new ArgumentNullException("surnameNamePatronimic");


IntPtr[] ptrs = null;
try
{
    ptrs = StringsToIntPtrArray(surnameNamePatronimic);

    int resultLen = MaxResultBufSize;
    int err = decGetNominativePadeg(ptrs[0], ptrs[1], ref resultLen);
    ThrowException(err);
    return IntPtrToString(ptrs, resultLen);
}
catch
{
    return surnameNamePatronimic;
}
finally
{
    FreeIntPtr(ptrs);
}


}

Function decGetNominativePadeg is in unmanaged dll

[DllImport("Padeg.dll", EntryPoint = "GetNominativePadeg")]
private static extern Int32 decGetNominativePadeg(IntPtr surnameNamePatronimic,
    IntPtr result, ref Int32 resultLength);

and throws an exception: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
The catch that is in C# code doesn't actually catch it. Why? How to handle this exception?
Thank you for your help!

Answer 1

If the IntPtr result parameter is to receive the value from within the function, it must be marked ref.

I don't see ptrs[1] being assigned any value before passing.

Try changing the definition to:

[DllImport("Padeg.dll", EntryPoint = "GetNominativePadeg")]
private static extern Int32 decGetNominativePadeg(IntPtr surnameNamePatronimic,
    **ref** IntPtr result, ref Int32 resultLength);

The reason probably is that it's trying to write to "result" which is marked as input-only.

Answer 2

you have probably turned off debugging of unmanaged code.

"Enable unmanaged code debugging option" must be check in project properties under the Debug section. After this, the exception is shown in the debugging process.

Answer 3

"The CLR no longer delivers exceptions for corrupted process state to exception handlers in managed code."

.NET Framework 4 Migration Issues.

Just add this to the config file: http://msdn.microsoft.com/en-us/library/dd638517.aspx

Answer 4

Problem solved. I found out that when using 4-th framework I have this problem, when using 3.5 - I don't.