none
Error calling status dll from different thread RRS feed

  • Question

  • Hello

    I am calling a dll from a c# application. The dll has 3 methods:

    - OpenDb ( open database )

    - UseDb( use db opened before)

    - CloseDb( close database)

    If I call these methods in the main application everithing is OK, but if I open db in main application and I call "UseDb" in a new thread opened by main application, the DLL gives me an error accessing to protected memory, it seems like if application and his thread don't share memory used to preserve the variable status of DLL. How can I mantain the dll status?

    Thank you

    • Moved by Bob Shen Wednesday, July 4, 2012 5:35 AM (From:Visual C# General)
    Tuesday, July 3, 2012 12:24 PM

Answers

  • Yes the dll was created by me at the begining in Visual C++ 6.0 and was working fine, now I converted it in Vc++ 10.0 and that conversion is now creating the problem.

    What do I have to do to make dll thread-safe? Do you have any idea ?

    It's a wide-open field of potential problems.  But assuming your repro steps are simply this (below) then there's hope:

    1. Thread 1 calls OpenDb
    2. Thread 2 calls UseDb
    3. Crashes every time.

    (If not, then please clarify your repro steps!)

    If you wrote all the code then your first step is to determine the nature of the crash.  I think you said you got an access violation.  Your debugger will show you what the exception is and what code caused it.  Turn on native debugging in your debugger (Project > Properties > Debug > Enable unmanaged code debugging.).  Just work backwards from the evidence that the debugger gives you until you find what went wrong.  Find out what memory was being accessed, who it belongs to, why it was being accessed, what it should have been, who called it, etc.  Your debugger has lots of facilities to help you with multithreaded debugging, so this should be doable.

    There are numerous potential factors:  race conditions, thread-local storage, even code that calls "get thread ID" could all be contributing to the problem.

    But like I said, your first job is to determine the nature of the crash.

    A few related questions:

    • What language was used to create the DLL?  C++?
    • Are you PInoking the DLL?  Or using COM?
    Wednesday, July 4, 2012 1:30 PM

All replies

  • Not every API is "thread-safe".  It could just be that the author of that particular dll never intended that those function calls be made from different threads.

    Or, are you the author of that dll?

    Tuesday, July 3, 2012 1:09 PM
  • Yes the dll was created by me at the begining in Visual C++ 6.0 and was working fine, now I converted it in Vc++ 10.0 and that conversion is now creating the problem.

    What do I have to do to make dll thread-safe? Do you have any idea ?

    Tuesday, July 3, 2012 1:14 PM
  • Hi Roby,

    According to your description, I'd like to move this thread to CLR Forum for better support, where more experts live.
     
    Thanks for your understanding.


    Bob Shen [MSFT]
    MSDN Community Support | Feedback to us

    Wednesday, July 4, 2012 5:34 AM
  • Yes the dll was created by me at the begining in Visual C++ 6.0 and was working fine, now I converted it in Vc++ 10.0 and that conversion is now creating the problem.

    What do I have to do to make dll thread-safe? Do you have any idea ?

    It's a wide-open field of potential problems.  But assuming your repro steps are simply this (below) then there's hope:

    1. Thread 1 calls OpenDb
    2. Thread 2 calls UseDb
    3. Crashes every time.

    (If not, then please clarify your repro steps!)

    If you wrote all the code then your first step is to determine the nature of the crash.  I think you said you got an access violation.  Your debugger will show you what the exception is and what code caused it.  Turn on native debugging in your debugger (Project > Properties > Debug > Enable unmanaged code debugging.).  Just work backwards from the evidence that the debugger gives you until you find what went wrong.  Find out what memory was being accessed, who it belongs to, why it was being accessed, what it should have been, who called it, etc.  Your debugger has lots of facilities to help you with multithreaded debugging, so this should be doable.

    There are numerous potential factors:  race conditions, thread-local storage, even code that calls "get thread ID" could all be contributing to the problem.

    But like I said, your first job is to determine the nature of the crash.

    A few related questions:

    • What language was used to create the DLL?  C++?
    • Are you PInoking the DLL?  Or using COM?
    Wednesday, July 4, 2012 1:30 PM
  • The condition is follow:

    1. Thread 1 calls OpenDb

    2. Thread 2 calls UseDb : Dll gives access violation

    After a while a I found the problem and a sort of "workaround" but it don't like me very much.

    When I call OpenDb from Thread1, it creates a CDaoDatabase pointer (pDbUInUse) , and if I call "UseDb" using "pDbUInUse" in Thread1 everything is ok. If I try to use the method "UseDb" from Thread2 (that was created from Thread1), I use "pDbUInUse" pointer that belong to the Heap of Thread1 and this create the Access Violation.

    The solution I found is to force the calling of "UseDb" from Thread1 creating an event on it and create a method to generate the event from Thread2

    If you think there are better solution please let me know.

    Thursday, July 5, 2012 2:17 PM