Background. I ran a release version of my program on another computer and immediately got a message, "Could not find Your_DLL.dll or one of it's dependencies". I believe I've tracked this down to the fact that "Your_DLL.dll" makes use of MSVCR120D.DLL . I checked this using Dependency Walker (Depends.exe). On my original computer, all is well because I have the full Visual Studio (2013) and MSVCR120D.DLL is present. However, it is not present on another machine, nor should it be as it's a Debug version of MSVCR120.DLL. I'm pulling my hair out trying to figure out where in my project for "Your_DLL" I am making use of MSVCR120D.DLL or have any debug settings under the release build. A search for MSVCR120D.DLL in the whole directory turns up nothing. Of course, perhaps something in the settings for the release build is somehow making use of a debug dll that in turn calls this debug dll. Can someone give me a clue where to look for the problem?
Thanks,
Dave
The flavor of a run-time library is specified in the compiler switch /M...
For dynamically linked CRT, it should be /MD for release config, and /MDd for debug. I would check that first, by looking into:
Project Properties -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library
[added]
The Depends tool has a "Profile" command (Profile -> Start Profiling), where you can see a run-time information for dynamically loaded DLLs. Hope that will point you to the offender.
Thank you for all the answers. We found the problem, and I must admit that I'm the one who caused it! "Your_DLL.dll" was building just fine in Debug and Release. The problem was how I was using it from another dll. The other dll was a C# project and under references, I added "Your_DLL.dll". Unfortunately, I left the "Copy local" to True. By company policy, we build everything to a central place C:\bin\debug or C:\bin\release. Also, by company policy, when we add a reference, we pick the debug version (you have to pick one!) but make sure to have "Copy Local" as FALSE. So when our build script builds, it correctly builds "Your_DLL.dll" and puts a release version in C:\bin\release. However, when CSharp.dll is subsequently built, it was putting a debug version of "Your_DLL.dll" in C:\bin\release. We finally noticed the problem when we saw that the version of Your_DLL.dll was the same size in c:\bin\debug and c:\bin\release.
I've always had a sinking feeling about the way we handle references. Perhaps there is a better way? But that's probably a whole other stack overflow question.
I hope this helps someone in the future.
Thank you,
Dave
Related
I've done some searching and seen questions similar in nature to mine, but none that quite hit the nail on the head of the issue I'm having.
I'm making C++ game in Visual Studio (with the Allegro 5 library) and encountering difficulty running it on other computers. I'm well aware of the 'MSVCR##.dll is missing from this computer' issue, but what I'm wondering is why I'm unable to run my Release build because I'm missing the MSVCR##'D'.dll on a certain computer, when I was under the impression that the 'D' suffixed .dll was exclusively required for running the debugger. I've checked in my configuration manager for release build settings and I have 'Generate Debug Info' set to No, which I thought was the only thing I needed to do. My question I guess is whether or not there are any other settings I need to configure to make sure my Release build isn't looking for the MSVCR##D.dll. Thanks in advance anyone who has any info!
You're a bit confused about the use of the *D libraries. They're indeed used for debug builds, but debug builds differ in multiple ways from release builds. For starters, debug builds by default come with a *.PDB file that contains all the function names (This is your "Generate Debug Info" option). A debugger looks into the .PDB file to find a readable name for a crash site.
Another debug option is to not inline code - this keeps your named functions intact. Inlining may put that single finction inside three other functions, which complicates debugging a bit.
Finally the Debug CRT includes functions that perform extra error checking against bad arguments. Many functions exhibit Undefined Behavior when passed a null pointer, for instance. The Debug libraries will catch quite a few of those, whereas the Release versions assume you pass valid pointers only.
Now DLL's can reference each other; there's a whoel dependency graph. That's why the Dependency Walker tool exists: it figures out which DLL's rqeuire which other DLL's, and this will tell you why you need the *D version.
Thank you very much for all your inputs, I was able to learn a fair bit from this. It turns out the issue was (of course) entirely my fault, as when setting up the Allegro 5 dependencies in the project settings (under General->Linker) I was accidentally including a dependency for the debug version of the Allegro monolith-md.dll as well as the non-debug version in my Release build, and that .dll was in turn referencing the *D version of the MSVCR .dll. The issue has been resolved by removing that dependency from the Release build of my game.
Install dependency walker on that machine. Load the exe. Check if any of the dependent dlls are missing.
My current preferred C++ environment is the free and largely excellent Microsoft Visual Studio 2005 Express edition. From time to time I have sent release .exe files to other people with pleasing results. However recently I made the disturbing discovery that the pleasing results were based on more luck that I would like. Attempting to run one of these programs on an old (2001 vintage, not scrupulously updated) XP box gave me nothing but a nasty "System cannot run x.exe" (or similar) message.
Some googling revealed that with this toolset, even specifying static linking results in a simple hello-world.exe actually relying on extra .dll files (msvcm80.dll etc.). An incredibly elaborate version scheming system (manifest files anyone?) then will not let the .exe run without exactly the right .dll versions. I don't want or need this stuff, I just want an old fashioned self contained .exe that does nothing but lowest common denominator Win32 operations and runs on any old win32 OS.
Does anyone know if its possible to do what I want to do with my existing toolset ?
Thank you.
For the C-runtime go to the project settings, choose C/C++ then 'Code Generation'. Change the 'runtime library' setting to 'multithreaded' instead of 'multithreaded dll'.
If you are using any other libraries you may need to tell the linker to ignore the dynamically linked CRT explicitly.
My experience in Visual Studio 2010 is that there are two changes needed so as to not need DLL's. From the project property page (right click on the project name in the Solution Explorer window):
Under Configuration Properties --> General, change the "Use of MFC" field to "Use MFC in a Static Library".
Under Configuration Properties --> C/C++ --> Code Generation, change the "Runtime Library" field to "Multi-Threaded (/MT)"
Not sure why both were needed. I used this to remove a dependency on glut32.dll.
Added later: When making these changes to the configurations, you should make them to "All Configurations" --- you can select this at the top of the Properties window. If you make the change to just the Debug configuration, it won't apply to the Release configuration, and vice-versa.
I've had this same dependency problem and I also know that you can include the VS 8.0 DLLs (release only! not debug!---and your program has to be release, too) in a folder of the appropriate name, in the parent folder with your .exe:
How to: Deploy using XCopy (MSDN)
Also note that things are guaranteed to go awry if you need to have C++ and C code in the same statically linked .exe because you will get linker conflicts that can only be resolved by ignoring the correct libXXX.lib and then linking dynamically (DLLs).
Lastly, with a different toolset (VC++ 6.0) things "just work", since Windows 2000 and above have the correct DLLs installed.
In regards Jared's response, having Windows 2000 or better will not necessarily fix the issue at hand. Rob's response does work, however it is possible that this fix introduces security issues, as Windows updates will not be able to patch applications built as such.
In another post, Nick Guerrera suggests packaging the Visual C++ Runtime Redistributable with your applications, which installs quickly, and is independent of Visual Studio.
I am having some trouble debugging a visual studio 2008 C++ project. When I start running it in debug, the breakpoints are disabled with the message
The Breakpoint will not be hit. No Symbols have been loaded for this
document.
I have tried cleaning and rebuilding, but this doesn't make a difference.
I also tried looking in Debug->Windows->Modules. If I right click on the module I am trying to debug and press Symbol load information it brings up a list of places it has tried to load the symbols from. The first in the list is correct and the file exists, but next to it is this error
C:\path\to\my\symbol\Debug\MyProject.pdb: Unknown symbol handler for
error
Does anyone know what causes this or how to fix it?
First of all, it is possible that some of your modules won't show in the module window, because some of them may be loaded dynamically (only as needed).
You might want to check in your project properties under Linker > Debugging > Generate Program Database File and Generate Debug Info. Be sure these two are set properly.
Also, check if C/C++ > General > Debug Information Format is set to Program Database for Edit And Continue (/ZI) or something similar.
I know you mentioned that your symbol file exists, but checking what I just mentioned will ensure you have the right version of your symbol in the right place.
Finally, check if all your project and files in your solution are set to compile as Debug and not Release or something else, because no symbols will be generated (hence none will be loaded) for this project / file.
Hope this helps a bit.
In my case, the problem was solved by checking "Use Managed Compatibility Mode" in Tools / Options / Debugging / General.
In case anyone has this problem when using 'Attach to process', the answer to this question solved it for me:
Visual Studio is not loading modules when attaching to process
Specifically, switching to 'Native code' in the 'Attach to' options instead of 'Auto'.
I have managed to solve this by copying my source sideways and checking out a completely clean copy. I assume it was some setting stored in the projects .suo file.
Go to the "Properties" for the website that would use that dll for debugging and then select "Native Code" in the "Debuggers" section below:
There could be a problem with the mspdbsrv.exe process. Try killing it and start debugger again.
For me the fix was in restarting the Visual Studio :) As simple as that. Nothing else helped - tried to Clean (even deleted all files in the Debug folder), checked settings, even killed the mspdbsrv.exe process, but only VS restart did the trick.
In the Modules window you can right click and add your Debug output folder to folders where your system looks for symbol files. Also, the thing that worked for me was deleting all the output files manually, Clean won't do it every time and that's why even though the .pdb file is generated, it doesn't correspond to your output files, thus not loading symbols from it.
Delete all files in the bin and obj folders. Then build the solution again. If your problem was like mine, it seemed like VS was loading an older version of a specific unknown file that rebuilding the solution/project would not replace. Make sure to make a copy of your solution/project before trying this. Good Luck!
Make a copy of your "Debug" folder within your project's folder, then delete every file in the original "Debug" folder. As additional measure if you had your visual studio already running with your project loaded, close it after deleting Debug's contain and reopen it before re-build the whole project, theoretically this action will create new copy of symbol files and the rest needed to debug your code.
I found out this problem occurred to me when I moved my files to other computer and try to compile and debug my code from there, although all folder and drive names were the same, some how the IDE was unable to use the previously created symbol files.
Hope this work around works for some one else !.
VS2015 C++
I ran into the same problem after cancelling the loading of symbols whilst attempting to debug my application in VS2015. After this, VS2015 refused to load the symbols for the project I was interested in (multiple sub projects in a solution with C# calling C++ DLLs). Solutions above did not work for me, but this did.
For Visual Studio 2015 (C++):
Right click on your project that your break point is in and select
properties Expand C/C++
Select General under C/C++
Change the Debug Information Format to any other option
Click Apply
Change the Debug Information Format back to its default "Program
Database for Edit And Continue (/ZI) (or whatever you prefer)
Click Apply
Now rebuild your project
Hope this helps.
Alan M
1) Right click on the project you want to debug.
2) Select [Properties]
3) Select the [Build] tab
4) Make sure [Define DEBUG constant] and [Define TRACE constant] are checked
5) Click the [Advanced] button at the bottom of the Build tabpage
Make sure that [Debug Info:] is set to [full]
6) Click [OK]
7) Rebuild the project
In my case, "use library dependency inputs" in "linker->general"should be set to yes, then the problem is solved.
None of the above helped me...
At the end I changed from Debug\X64 to Debug\win32, this helped, probably it's some configuration which isn't the same in both. Maybe this will help as a
workaround for someone...
Hope that could help anyone.
I'm debugging a WIA driver, and came across this similar problem.
I noticed this log :
DLL named C:\Windows\System32\WIA\wiadriverex.dll cannot be loaded (LoadLibraryEx returned 0x0000007E). Make sure the driver is installed correctly
Then I realized that it is due to DLL dependency. Then I copied required DLLs to System32, the problem is gone. Pay attention, copy to System32, or it won't work for me.
It helped in my case:
Debug -> Attach to process
Scroll down to w3wp.exe
Check "Show processes from all users
After refresh scroll again to w3wp.exe
Select new one with type x64, Managed (Native compilation)
Try disabling /GL option if it has been enabled in C/C++ / General / Optimization / Whole program optimization.
Initially, I had no issue with debugging my program but after tweaking here and there the issue that OP says began to arise.
The module and its symbols were loaded and nothing in this guide seemed to correspond to my problem. Turning /Zi to /Zl also didn't help.
I'm not sure why, but, it's sort of a compiler behavior I haven't been experienced before. FYI, /GL option is not a default in the C++ projects in VS2017.
In my case, the error was due to the fact that part of the code was connected as an external library. In order for debug process to work also when going into the code of the external library, it was necessary to add not only its headers, but also the implementation files - folder Source Files of Solution Explorer.
In my case it was debugger type.
I used remote windows debugger, changing it to local solved an issue.
Debugger options:
I am trying to use a library (.dll) in my project. Everything seems to
be set up fine. It all works in release mode.
When I go debug on it, I get this darn error on startup:
ldr: ... application couldn't be initialized error (or similar, I translated it)
I learned that this has to do with manifest files.
I fumbled around a bit, in the project settings, but nothing really worked / I couldn't get my head around it.
The error persists.
Does anyone know a quick solution to this?
I don't care if it is dirty.
I think I liked dll-Hell better than manifest-Hell!!
The solution:
The wrong version of the .dlls got loaded. I didn't know that they were still
lying around on the system. Depedency Walker is a great tool and set me on the right track. So I will accept this answer.
Thanks a lot!
I always use Dependency Walker for debugging this sort of thing. It will tell you which dependencies your dll is missing.
Are you trying to run Debug-mode executables on a PC without Visual Studio installed? If so, you'll need to copy the Debug CRT DLLs onto it. See here: http://msdn.microsoft.com/en-us/library/aa985618(VS.80).aspx
Probably has something to do with dependent DLLs that are not available in debug mode (but are there in release mode). Make sure the debug DLLs you need are available (e.g. in the path).
My current preferred C++ environment is the free and largely excellent Microsoft Visual Studio 2005 Express edition. From time to time I have sent release .exe files to other people with pleasing results. However recently I made the disturbing discovery that the pleasing results were based on more luck that I would like. Attempting to run one of these programs on an old (2001 vintage, not scrupulously updated) XP box gave me nothing but a nasty "System cannot run x.exe" (or similar) message.
Some googling revealed that with this toolset, even specifying static linking results in a simple hello-world.exe actually relying on extra .dll files (msvcm80.dll etc.). An incredibly elaborate version scheming system (manifest files anyone?) then will not let the .exe run without exactly the right .dll versions. I don't want or need this stuff, I just want an old fashioned self contained .exe that does nothing but lowest common denominator Win32 operations and runs on any old win32 OS.
Does anyone know if its possible to do what I want to do with my existing toolset ?
Thank you.
For the C-runtime go to the project settings, choose C/C++ then 'Code Generation'. Change the 'runtime library' setting to 'multithreaded' instead of 'multithreaded dll'.
If you are using any other libraries you may need to tell the linker to ignore the dynamically linked CRT explicitly.
My experience in Visual Studio 2010 is that there are two changes needed so as to not need DLL's. From the project property page (right click on the project name in the Solution Explorer window):
Under Configuration Properties --> General, change the "Use of MFC" field to "Use MFC in a Static Library".
Under Configuration Properties --> C/C++ --> Code Generation, change the "Runtime Library" field to "Multi-Threaded (/MT)"
Not sure why both were needed. I used this to remove a dependency on glut32.dll.
Added later: When making these changes to the configurations, you should make them to "All Configurations" --- you can select this at the top of the Properties window. If you make the change to just the Debug configuration, it won't apply to the Release configuration, and vice-versa.
I've had this same dependency problem and I also know that you can include the VS 8.0 DLLs (release only! not debug!---and your program has to be release, too) in a folder of the appropriate name, in the parent folder with your .exe:
How to: Deploy using XCopy (MSDN)
Also note that things are guaranteed to go awry if you need to have C++ and C code in the same statically linked .exe because you will get linker conflicts that can only be resolved by ignoring the correct libXXX.lib and then linking dynamically (DLLs).
Lastly, with a different toolset (VC++ 6.0) things "just work", since Windows 2000 and above have the correct DLLs installed.
In regards Jared's response, having Windows 2000 or better will not necessarily fix the issue at hand. Rob's response does work, however it is possible that this fix introduces security issues, as Windows updates will not be able to patch applications built as such.
In another post, Nick Guerrera suggests packaging the Visual C++ Runtime Redistributable with your applications, which installs quickly, and is independent of Visual Studio.