1

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.

Community
  • 1
  • 1
Rajeesh
  • 391
  • 3
  • 7
  • You have access to "cachet.dll"'s code? – leppie Jul 18 '12 at 12:02
  • No, I do not have access to the source code. – Rajeesh Jul 18 '12 at 12:04
  • 1
    In that case, contact the vendor. – leppie Jul 18 '12 at 12:06
  • Is your Windows XP machine (the one that fails to run the code, not the one that compiled it) a 64-bit machine? – ken2k Jul 18 '12 at 12:06
  • My Windows XP machine is 32 bit. I compiled the code on the same machine. – Rajeesh Jul 18 '12 at 12:08
  • 1
    @Rajeesh Try to check the calling convention. Another thing is (even if it won't fix your issue) you might want to return an IntPtr instead of an int (if the value represents a memory address). – ken2k Jul 18 '12 at 12:11
  • @ken2k I have tried with other calling conventions too with out success. I just tried to see IntPtr for the return type but still same exception. – Rajeesh Jul 18 '12 at 12:18
  • @Rajeesh Yes, the IntPtr thing could have fixed your issue only if your XP machine was a 64-bit machine. int or IntPtr is the same for 32-bit ones. Maybe you should try to contact the vendor as leppie said, so you can get the exact method declaration syntax. – ken2k Jul 18 '12 at 12:27
  • Just a though, did you try to build a unmanaged c++ proxy dll to call the statically linked cachet.dll and then call the proxy from you c# project? – MLeblanc Jul 18 '12 at 12:12
  • I did not try this case yet. I originally had a C++/CLI wrapper calling this native dll but it was not working. I will give it a try too – Rajeesh Jul 18 '12 at 12:22
  • @MLeblanc I created a native C++ proxy to call the native C dll and then consume it from C#, no success. – Rajeesh Jul 18 '12 at 15:39

1 Answers1

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

Rajeesh
  • 391
  • 3
  • 7