Welcome to ShenZhenJia Knowledge Sharing Community for programmer and developer-Open, Learning and Share
menu search
person
Welcome To Ask or Share your Answers For Others

Categories

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.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
thumb_up_alt 0 like thumb_down_alt 0 dislike
206 views
Welcome To Ask or Share your Answers For Others

1 Answer

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


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
thumb_up_alt 0 like thumb_down_alt 0 dislike
Welcome to ShenZhenJia Knowledge Sharing Community for programmer and developer-Open, Learning and Share
...