different behavior when mixing DLLs from different MSVC

0
votes

I know that mixing DLLs from different MSVC is bad and should be avoided. Here I would like to know the reason of their different behavior.

Background:

Having 3rd party library shipped with (XXX.dll, XXX.lib and XXX.h) I use it in my application with implicit linking. They are all x64.

  • my application is built with MSVC 2015.
  • The 3rd party XXX.dll is apparently built with MSVC 2008 and
    • Unfortunately there is pointer involved in function calls from XXX.dll
    • e.g. int __stdcall func1(const char * arg); to have string as argument
    • e.g. int __stdcall func2(char * arg); to get string filled by DLL

Different Setup:

On Windows 7 (x64)

It works just fine.

On Windows 10 (x64)

I get access violation exception from XXX.dll due to reading invalid memory location. (i.e. calling int __stdcall func1(const char * arg);)

Exception thrown at 0x000001EF05A2BBB9 (XXX.dll) in Application.exe: 0xC0000005: Access violation reading location 0x00000000074A3A68.

(it sounds reasonable when there are two CRTs/Heaps and pointer transfer will not work.)

Question:

Why it works on Windows 7?

I use the same MSVC2015 tool-chain and would expect the same behavior. Or is there something OS related?

Thanks.

1
c++visual-studiodllwindows-10
If dll is exposing C interface and does not perform resource ownership transfer then it should work perfectly fine even if build with different version of compiler or completely different compiler. Simply reading arg should not cause any problems. Have you inspected the call stack to figure out what is the failure point? - user7860670
Neither of those should be a problem unless func2 eventually frees the non-const string pointer you gave it and said-same pointer did not originate from some other call to the library. Then you're in trouble. Unrelated, find the author and slap him upside the head for taking a "write-to-my-buffer" pointer without an argument specifying sizing constraints. That's just a recipe for disaster. There's a reason gets was pulled from the standard library. - WhozCraig
May be, it's even simpler (and has nothing to do with DLLs and mixed MSVC runtimes): There is a call of func1() with success on Windows 7 which failed on Windows 10 (for any reason). Somebody forgot to check the success of func1(), and thus, consecutive processing of return value crashs in the latter case. (Sorry, if I mixed func1() and func2() but I guess you got my point.) - Scheff's Cat
thx. all make sense. I am trying to dig deeper... and will update soon - rnd_nr_gen

1 Answers

0
votes

Indeed, the original question is not really valid. When I look at stack trace. The exception is actually thrown by a (msvcr90.dll) thread from the XXX.DLL.

Here is the question with more detail

Debug 3rd party DLL causing access violation after upgrading to Windows 10