MSVCR90D.dll not found in debug mode with Visual C++ 2008

I

11

17

I have a problem with Visual C++ 2008. I have installed opencv and I've created a new program and I build it with no errors. However, it complains about not finding MSVCR90D.dll when debugging. In release mode there is no problem at all.

I do have MSVCR90D.dll in one of Winsxs folders. Does anyone know a get-around to this problem? Is this a known bug?

Gerard

Isthmus answered 20/10, 2008 at 15:5 Comment(2)

I have the same problem. As of 18-07-2009 none of given answers really answers the question. That's why I asked it again here stackoverflow.com/questions/1150464 – Tsarevna 19/7, 2009 at 18:10

possible duplicate of msvcr90d.dll not found in debug mode – Affected 26/7, 2015 at 8:1

V

9

There are several potential solutions described in this forum post. See if any of those help.

One hint from there:

Go to %System Drive%\Windows\WinSxS and look for the directory x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456

If this doesn't exist, go to the VS setup and make sure you have all libraries installed under VC++.

And another one:

I had the same problem, but fixed it by turning off incremental linking (Project properties... Linker... General... Enable Incremental Linking: No).

Confirming the last one:

Projects built on a software-mounted drive complain about a missing MSVCR90D.dll. The problem goes away if you turn off incremental linking (and rebuild all, of course).

Vinic answered 20/10, 2008 at 15:16 Comment(5)

Thank you very much for your help. It worked!! However, can I have any problem for setting off the incremental linking? What difference does it make? Thank you again – Kampmann 20/10, 2008 at 23:18

From MSDN: An incrementally linked program is functionally equivalent to a program that is nonincrementally linked. This is the important point. Read more at msdn.microsoft.com/en-us/library/4khtbfyf(VS.80).aspx. – Vinic 21/10, 2008 at 8:29

Turned off incremental linking (OGRE3D) and it worked. Thanks +1 – Uncircumcision 13/8, 2009 at 15:12

Thanks a lot for the "software mounted drive" part, that was my problem. – Ankylosaur 17/9, 2011 at 19:38

Setting 'Enable Incremental Linking' to "NO" worked for me. – Shay 4/11, 2015 at 16:47

R

5

Having the same problem I found a post that lead me to the debug DLLs in the VS9.0 install. For the default install they were in: C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC90.DebugCRT.

There are three DLLs and a manifest file. You can add these to your System32 directory, add the directory to your PATH environment variable or copy the files to same directory as your executable when debugging.

Incremental linking speeds up your builds (the linker only re-links libs that have changed instead of re-linking the entire project). It otherwise has no effect on the build output. For a large project I would not recommend turning off incremental linking.

Radmilla answered 29/3, 2009 at 2:13 Comment(1)

this works for me. I just copy the DLLs and it runs ok. However, copying the libs might not be a good choice nor adding an additional directory to PATH variable (need to restart PC). Is there any better way than these?? – Spacial 31/7, 2012 at 8:8

G

3

Had the same problem although another VC9.0 project did well. So I compared both project settings. The crucial difference was under 'Project Properties' -> 'Configuration Properties' -> 'Manifest Tool' -> 'Input and Output' -> 'Embed Manifest'. This option must be set to YES.

Gregoriogregorius answered 13/1, 2010 at 16:18 Comment(2)

this might not be the case! it asks me to use Manifest file, not embedded manifest. I changed to 'NO' and it run just fine – Spacial 31/7, 2012 at 8:9

This precise change resolved the problem for me. It may differ under different circumstances. – Quad 24/9, 2012 at 19:34

C

2

Troublehooting DLL problems is a lot easier with Dependency Walker . It allows you to profile your application, catching both DLLs loaded at startup and DLLs loaded later. It will spit out a lot of messages related to the loading of DLLs, or the failure to load them. It also understands SxS loading of DLLs.

You can pass an EXE as a argument to Depends.EXE, and it will profile that app. This can be combined with most IDEs. For instance, in Visual Studio you can set the "Command for Debugging". By default, that's your own EXE. Change it to depends.EXE, and set the command arguments to (at least) /pb your.debug.exe.

Crowson answered 21/10, 2008 at 9:5 Comment(0)

P

1

Recompile your project in VC++ 2008 using function File->New->Project From Existing Code. It helped myself, probably it will help you. Regards.

Pump answered 11/7, 2010 at 8:9 Comment(0)

F

1

I have solved same problem like below:

Select project, right click and open property page.
Select Configuration Properties.
Select C/C++ from tree list.
Select Code Generation.
Look at the property list at left side and see the Runtime Library property.
Select Multi-threaded Debug instead off Multi-threaded DLL.

When you do that, your project embeds depended dlls and so it escaped dependency problems.

Note: I worked on a dll project and had that problem. After doing above steps it worked for my situation.

Fraise answered 5/8, 2014 at 6:47 Comment(0)

F

0

This is one of the reasons that I statically link; bigger EXEs but I have never had a dependency issue like this before. Probably worth a question in itself though...

Feline answered 20/10, 2008 at 15:22 Comment(1)

"Probably worth a question in itself though" While I disagree on the viewpoint you expressed, I agree fully with your conclusion... ^_^ – Sebbie 20/10, 2008 at 15:54

H

0

I can't give a definitive solution, but here are some helpful links:

And of course, there's a lot more on MSDN if you follow the links.

Hl answered 19/7, 2009 at 18:29 Comment(0)

B

0

I had the problem:

Could not load file or assembly 'AudioInterface, Version=1.0.3548.29920, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)

AudioInterface was the name of my C++ project.

Switching to "Release" config, everything worked.

I tracked it to lack of the manifest file alongside my DLL, which I further tracked to having an Assembly Identity set. (Properties > Manifest Tool > General > Assembly Identity)

I removed this setting, and the manifest dropped in the right place, and everything worked.

Bhili answered 22/9, 2009 at 0:3 Comment(0)

C

0

I tried all the suggested solutions without any luck. I finally found that the manifest was missing from the "C:\WINDOWS\WinSxS\Manifests" folder.

Find the folder in C:\WINDOWS\WinSxS where your dll is located. Check to see if there is a manifest in C:\WINDOWS\WinSxS\Manifests that matches the folder name of your dll. If the manifest is missing, copy the correct manifest from another machine and paste it into the manifest folder. The manifest file names are:

"x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456.cat"

"x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456.manifest"

Chev answered 1/7, 2010 at 13:0 Comment(0)

S

0

I faced the similar problem but none of the described solutions worked for me.

Finally I did the following to fix my issue:

Step-1: Follow the suggestion given by @user176861

Step-2: In the VC++ Project Properties -> Configuration Properties -> Linker -> Manifest File: In the "Additional manifest dependencies" add the following:

type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'

After making the above change, I was able to debug.

Selah answered 2/3, 2021 at 13:1 Comment(0)

Recommended topics

Hot tags