DLL dependency not found when debugging with Visual Studio 11 RC

Asked 20/9, 2012 at 17:51 Answered 21/9, 2012 at 5:55

Solved c++dll visual-studio-2012 fmod

My project is a standalone C++ application that uses FMOD for playing sound. I've previously developed the same project with Visual Studio 2010 without any problems, but 2012 gives me the classic error: "The program can't start because fmodex.dll is missing from your computer. Try reinstalling the program to fix this problem." The project seems to load other DLLs(such as Direct3d related files and d3d shader compiler) just fine.

The problem occurs only if trying to debug or run the program from the IDE, not if I copy the executable to the appropriate directory with DLL and run it manually. If I remove all references to FMOD from the program, the debugging and running works fine. I've made sure that I have correct working directory in Project settings (besides it loads all the other files just fine in the same directory). I originally converted the project from Visual Studio 2010, but tried to create a new project from scratch with no luck. I've also tinkered all the possible compiler and linker settings through, and googling doesn't seem to help either.

I'm guessing that the problem has something to do with the new Metro style apps and it's way to handle external dependecies, but I have also turned "Metro Style App Support" off. I'm starting to think I've really tried everything I can and have no idea what to try next. Directions for getting more diagnostic information would be much appreciated as well! Thanks!

Edit: Visual Studio version I'm using is Visual Studio Ultimate 2012 RC, Version 11.0.50706.0 QRELRC July, 2012

Shell answered 20/9, 2012 at 17:51 Comment(1)

As usual with DLL problems, have you tried Dependency Walker? In particular, profiling mode? – Crisp 21/9, 2012 at 10:1

Go to the project's properties:

Configuration Properties | Debugging | Environment

And add the following item:

PATH=c:\path\where\the\dll-is;$(Path)

Petrifaction answered 21/9, 2012 at 5:55 Comment(7)

Sounds like this could be it! Have to try when I get back home from work! – Shell 21/9, 2012 at 8:14

Excellent! That nailed the issue. Thank you! – Shell 21/9, 2012 at 14:37

That'll let you run the program in the debugger, but it doesn't fix the problem that the program isn't looking for its DLLs properly. i.e. If someone else runs the program with the current directory set somewhere else, it will fail for them as well. (That's common if you run the program via a command prompt, for example.) – Futurity 22/9, 2012 at 13:26

@Leo: I was under the impression that the DLL would be deployed/installed in the application directory based on the comment about it working outside the IDE. However, you are right that that needs to be addressed if it hasn't already been, and that this solution is just for debugging in the IDE. – Petrifaction 22/9, 2012 at 15:15

Yes, the DLL will be deployed with the program. The issue was that I wasn't able to debug the program from the IDE. – Shell 26/9, 2012 at 9:17

Michael's advice did not work for me. I then put the DLL in the Debug directory and then it worked. – Mixed 7/4, 2015 at 17:25

Actually I forgot to put the PATH= – Mixed 7/4, 2015 at 19:4

My sympathies, I live in DLL hell a lot lately it seems. Two suggestions:

You can drive the IDE from the command line with devenv which has a /useenv switch.

"... Use PATH, INCLUDE, LIBPATH, and LIB environment variables instead of IDE paths for VC++ builds.
dumpbin /dependents [*.exe] [*.dll] will show you DLL dependencies.

dumpbin /dependents openssl.exe

Microsoft (R) COFF/PE Dumper Version 10.00.40219.01 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file openssl.exe

File Type: EXECUTABLE IMAGE

Image has the following dependencies:
SSLEAY32.dll
LIBEAY32.dll
WSOCK32.dll
MSVCR80.dll
KERNEL32.dll

Summary

     4000 .data
    14000 .rdata
     1000 .rsrc
    33000 .text 

Conventionalize answered 21/9, 2012 at 5:34 Comment(1)

The /useenv switch seems to make the VS fail to open the project at all. It outputs following error for each project:

F:\Program Files\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.Common.props(63,3): The imported project "G:\build\CommonConfiguration\Neutral\sdk.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

(F is the disk where visual studio is and G where the project is, there's no G:\build directory though..). – Shell 21/9, 2012 at 6:10

It may be that VS is running the app with a different current directory to when you run the app by hand.

VS typically sets the current directory to the project folder, which is usually not the same as the folder where the built binaries are. When you run it by hand you're probably running it from the latter, not the former.

If that is the problem then the code that loads fmodex.dll must be depending on the current dir being in the DLL search path, which can a big security risk (lookup "DLL planting" or DLL "pre-loading") and which is actively blocked by some Windows configurations.

Futurity answered 20/9, 2012 at 20:25 Comment(1)

The current directory should be fine (if by that you mean the working directory in project settings). But you might be right there, that the debugger seems to be actively preventing the program to load the DLL from the current directory. I went on to try something even that drastic than to copy the fmodex.dll to my local System32 folder, and the program seemed to start just fine. – Shell 21/9, 2012 at 6:22

Recommended topics

Hot tags