Question

I have an application that uses a third party native C dll. Everything works well on a Windows 7 machine with .Net 4 but fails on Windows XP (SP3) with .Net 4.

I get the following exception on Windows XP machine.

Unhandled Exception: System.AccessViolationException: Attempted to read or write
protected memory. This is often an indication that other memory is corrupt.

When I debug,

First-chance exception at 0x10069e1d in CacheInteropTest.exe: 0xC0000005: Access violation reading location 0x00000000.

this is my simplified test application code:

public unsafe class Program
{
    [STAThread]
    static void Main(string[] args)
    {
        var status = CacheEnd();
        Console.ReadKey(true);
    }

    [SuppressUnmanagedCodeSecurity]
    [DllImport("cachet.dll", EntryPoint = "#24", CallingConvention = CallingConvention.Cdecl, SetLastError = true)]
    internal extern static int CacheEnd();
}

I compiled the above program on Windows XP (SP3) 32 bit and copied to a Windows 7 machine and ran, it did not give any exception. The third party dll is available in the same folder as the executable.

I found many replies for issues related to AccessViolationException, particularly this
AccessViolationException in P/Invoke call is a close match.
Another site has kind of an overview about PInvoke and memory related issues here
http://dotnetdebug.net/2006/04/17/pinvoke-and-memory-related-issues/ but does not help me in this case.

The third party dll is a database kernel and provides multi-threaded database access (maintains one connection per thread). In the documentation of the API it was mentioned that the dll must be statically linked and C++ application that consumes this dll on Windows XP works well too.

I think the problem is in the implementation of the native dll, but why it works well on Windows 7?

Any one has any idea what could be going wrong on Windows XP?

The native function proto type provided by the vendor is

extern  int  CFPROTOD(CacheEnd,(void));

So I guess the issue is not related to calling conventions.

Answer 1

The issue is because of a limitation in Windows. The static linking requirement for the API came from this limitation that was already known to the vendor.
http://support.microsoft.com/kb/118816 explains the issue in Windows. Looks like this has been fixed in Win 7