none
AccessViolation crash when debug mode application runtime loaded before supporting library's release mode runtime RRS feed

  • Question

  • Hi,

    I've got a problem where a customer is building a COM application that integrates with an Excel workbook.  This application is built and distributed for their company's internal use and is only distributed as a DEBUG build.  For certain operations in the spreadsheet, they need to access my company's API through DLLs that we provide.  Our DLLs are all built in release mode, and utilize a release mode runtime.

    We have seen a conflict arise that certain operations will cause an access violation in our code during allocations due to what appears to be a conflict between the two runtime versions that are loaded.  We have noted in test cases that a) if our DLLs are loaded in their application before certain other support DLLs this does not happen, and b) if the customer's application is built in release mode, this does not happen.

    My question is, what is the recommendation for dealing with such a case?  Is there a way that we can resolve this conflict without requring the customer to either a) load our DLLs always before other DLLs, or b) compile in release mode, as both options have been rejected by the customer.

    Thanks.

    -baldheadedguy
    Tuesday, December 16, 2008 10:02 PM

Answers

  • Is this at all related to the CLR, the topic of this forum?  Smells like a C/C++ problem.  Yes, mixing the release and the debug version of the CRT libraries is not a good idea.  You'll need to talk to your customer to find out how they managed to deploy the debug version of the CRT DLLs to their machine.  It is strictly verboten by MSFT, the license does not permit it.
    Hans Passant.
    • Marked as answer by Zhi-Xin Ye Tuesday, December 23, 2008 8:29 AM
    Wednesday, December 17, 2008 1:38 PM
    Moderator