I have a strange issue that I am trying to work out for someone. I don't have any access to the code. There is a program that loads a DLL and has somewhat of a plugin framework. They provide virtually no documentation beyond how to import functions from the DLL and what calling convention to use for exports.
This person's plugin imports functions from a DLL (let's assume they used the proper calling conventions and imported properly). It periodically runs into access violations (usually access violation write/read from 0x0000000). Sometimes, it crashes the program and Event Viewer shows exception code 0xc0000005 (another access violation) with faulting module SHLWAPI.dll.
Using depends, I have determined that the program is statically linked to msvcr. I found that the plugin DLL dynamically links to msvcr120.dll.
Yes, I am aware that this is just asking for trouble and the access violations are no surprise, but unfortunately, I have to deal with someone else's problem.
Anyway, my question is this: Let's say is imported from this DLL and inside is a call to a function that is provided by msvcr120. When the program calls the imported , is it possible that it is calling from the msvcr it is statically linked to rather than from msvcr120?
I realize that it probably depends on the main program's plugin framework, but general feedback would be appreciated.
Thanks in advance!
There are known issues when using multiple copies of the CRT in one program, even when they all use the same version of the CRT (see Potential Errors Passing CRT Objects Across DLL Boundaries). If the CRTs are different versions, there are lots of other problems due to different size or layout of internal structures.
Since the program you use statically links with the CRT, it can not reliably be plugged in to. The anti-debugger code is just plain silly; there are several ways around it. If you paid for it send it back and demand a refund.