CODEWITHSUNDEEP
visual-studio-2008dllmsvcr90d.dll
Raymond
Raymond

Reputation: 957

How to control the SxS for msvcr90d.dll/msvcp90d.dll

After long time study/research I found

My application should use msvcr90d.dll/msvcp90d.dll -- 9.0.21022.8 But when I debug it with vs2008, it always use msvcr90d.dll -- 9.0.30729.6161

I think it should be the root cause for my app crash for STL standard vector exception (from 3rd-party DLLs). I ever run the app successfully on my machine with vs2008. It must be other app affected my app.

I even re-install vs2008 (again and again), and tune Manifest options for my app, nothing changed. I was crashed...along with my app. (The app crashed just before I am preparing to demo it to my boss...)

I have vs2010, vs2012 on my machine too. But the app ever worked when they are already exist. The only thing I can remember before the app crash is I remote access my machine with TeamViewer... The next day, the evil days began.

How to control the SxS for my app?

Upvotes: 0

Views: 380

Answers (1)

Hans Passant
Hans Passant

Reputation: 941217

The DLL version you ask for in your manifest, .21022.8, is being redirected through publisher policy files that are also deployed in your side-by-side cache. Which made you end up with the SP1 version plus several security patches. This is the primary mechanism by which Microsoft can patch security holes in the runtime DLLs.

The one thing you can be fairly sure of is that it is not the DLL version that is causing your problem, the version that this 3rd party DLL is asking for will be subject to the same version redirection rules. Easy to check btw, look in the Debug + Windows + Modules window and look for msvcr90d.dll. You'll see if more than one got loaded and you can see the version number. And watch out for msvcr90.dll, the Release version, having them both loaded into a process is Really Bad. Likely to happen when you link to the Release build of the DLL.

One standard crash-inducing mismatch is the _HAS_ITERATOR_DEBUGGING #define. Iterator debugging changes the size of C++ collection class objects. This goes wrong when a DLL exposes such an object through an exported function and was compiled with a different setting for this #define. The object it exposes has the wrong layout. You must ensure that you are using the same setting as was used by the 3rd party when they compiled the DLL. It is turned on by default for Debug builds so some likelihood that setting the #define to 0 for your project will be the quick fix. Contact the vendor if you don't know or want them to change their setting. Perhaps also a good time to point out that exposing C++ objects across a DLL boundary is a bad idea.

Upvotes: 1

Related Questions