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

bk1e
  • 23,871
  • 6
  • 54
  • 65
  • 1
    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 http://stackoverflow.com/questions/1150464 – Piotr Dobrogost Jul 19 '09 at 18:10
  • possible duplicate of [msvcr90d.dll not found in debug mode](http://stackoverflow.com/questions/1150464/msvcr90d-dll-not-found-in-debug-mode) – Shankar Narayana Damodaran Jul 26 '15 at 08:01

11 Answers11

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).

Jorge Ferreira
  • 96,051
  • 25
  • 122
  • 132
  • 1
    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 –  Oct 20 '08 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 http://msdn.microsoft.com/en-us/library/4khtbfyf(VS.80).aspx. – Jorge Ferreira Oct 21 '08 at 08:29
  • Turned off incremental linking (OGRE3D) and it worked. Thanks +1 – Brock Woolf Aug 13 '09 at 15:12
  • Thanks a lot for the "software mounted drive" part, that was my problem. – Cray Sep 17 '11 at 19:38
  • Setting 'Enable Incremental Linking' to "NO" worked for me. – Khulja Sim Sim Nov 04 '15 at 16:47
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.

x_x
  • 51
  • 1
  • 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?? – TSL_ Jul 31 '12 at 08:08
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.

Markus
  • 31
  • 1
  • 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 – TSL_ Jul 31 '12 at 08:09
  • This precise change resolved the problem for me. It may differ under different circumstances. – Mark McKenna Sep 24 '12 at 19:34
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.

MSalters
  • 173,980
  • 10
  • 155
  • 350
1

I have solved same problem like below:

  1. Select project, right click and open property page.
  2. Select Configuration Properties.
  3. Select C/C++ from tree list.
  4. Select Code Generation.
  5. Look at the property list at left side and see the Runtime Library property.
  6. 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.

Mustafa Kemal
  • 1,292
  • 19
  • 24
1

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

user388764
  • 11
  • 1
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.

Adam Rosenfield
  • 390,455
  • 97
  • 512
  • 589
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.

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...

Rob
  • 76,700
  • 56
  • 158
  • 197
  • "Probably worth a question in itself though" While I disagree on the viewpoint you expressed, I agree fully with your conclusion... ^_^ – paercebal Oct 20 '08 at 15:54
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"

Parvin Gasimzade
  • 25,180
  • 8
  • 56
  • 83
opie
  • 1
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.

Humayun Khan
  • 63
  • 1
  • 5