Unfortunately this is going to be a pretty open-ended question, but I am at my wit's ends and I thought I would reach out for some advice.
This is a Visual C++ MFC app using Visual Studio 2008 SP1.
A coworker and I both had Office 2007 installed and we have both had strange DLL loading problems with our app since. Specifically, LoadLibrary is failing to load one our DLLs ( the first one it loads ) and returning error code 126 ( module not found ). What's really strange is that if I just run the executable from the windows explorer it works fine.
I took the usual steps to diagnose the problems:
Verify that the file existed and that the current working directory was pointed at it.
Run dependency walker and verify that it's dependencies are loading correctly. They are all loading ok except the ones this question says are ok to fail.
Experiment with loading some different DLLs at the same location in the code. Some of the simple 'stub' dlls succeed, but most of them fail.
Experiment with loading the DLLs that are failing from separate test apps - in an empty console app and a barebone MFC app, all the DLLs are loading fine!
Try to load the DLLs with LoadLibraryEx and the LOAD_LIBRARY_AS_DATAFILE flag, which does succeed but doesn't get us very far except to point out it's probably a dependency problem.
I really don't know what else to do at this point. Like I said, Office 2007 is a common thread in our problem but I don't know what kind of problems it could create. I really don't know even what steps to take next. Any ideas?
edit: I'm pretty sure the current working directory is not in the DLL path for some reason. It seems the DLLs that are failing are ones that need any other DLLs. If I turn on Loader Snaps debug output the current working directory does not appear to be in the DLL loading path. Any idea what could cause this?
edit2: The current build dumped the executable into a directory other than the working directory. For some reason, when I tried to load a DLL which then tried to load ANOTHER DLL, the current working directory is no longer searched. By putting the executable into the directory with all of the DLLs I am trying to load, the problems go away. Based on all of this, and the output by loader snaps, I am 98% sure this is some bizarre Visual Studio bug and I will simply have to work around it.
Office 2007 turns on SafeDllSearchMode in the registry.
http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx
With SafeDlLSearchMode, the current directory is no longer searched. To disable it, they claim you can go into regedit and set HKLM/System/CurrentControlSet/Control/SessionManager/SafeDllSearchMode to 0, but this did not work for me. Calling SetDllDirectory to the current directory DID work for me, although this only works if you are targeting XP SP1+.
The reason this caused problems in my specific app is that when we run the executable from the debugger, we keep the executable in a different directory than the current directory with all the other build files. When we run outside of Visual Studio, we first copy the executable into the directory with all of the other DLLs. The directory that the original executable is called from is ALWAYS in the search path, so if you keep your executable and your dlls together, you would never run into this problem.
Still, it's quite confusing for Microsoft to change the dll search path under us like this.
Does the DLL which fails has MSVCRT80 in dependencies? If yes, the most likely reason is that Office 2007 has overridden MSVCR80.dll
Related
I have a question regarding VC++ 5.0.
For a dialog-based project I am writing, I have linked it to a particular dynamic link library called File32.dll by adding the corresponding .lib file to my project debug folder as you do.
I also linked to this library in the Project Settings. This library contains functions specific to a particular application which I need to access. All of the necessary header files have been included and the project builds without errors or warnings.
The problem is that once I try to debug and run the dialog, an error appears:
The program can't start because OUTPUT.dll is missing from your
computer.Try reinstalling the program to fix this problem.
OUTPUT.dll is a library I am not linking to for this project. And when I add this particular .dll to my debug folder, the same error appears with a different .dll (SYSINT32.dll).
No matter how much I add these dlls to my debug folder, the error message reappears with a new dll. Bare in mind, the project debugged and ran successfully before I linked to File32.lib. So I feel that the problem lies with File32.lib. Any ideas on what might be happening with the linker?
Use Dependency Walker to open your File32.dll. It will show all DLLs this one (statically) depends on. It will also highlight the missing ones.
As for VC++ 5.0 ... I feel the need to comment ...
Visual C++ 5.0, which included MFC 4.21 and was released 1997-04-28 (...)
that's an amazing 18 years :-)
we made one application on Visual Studio 2008 , it about to release. but now we are getting the crash while launching the application . could you please any give a suggestion how do i debug on this particular issue
You can run the Release build in the debugger, too. Turn on debug-info settings in both the compiler and linker tabs (I think that was not the default in vs2008 and there were two distinct places to set) but don't change any optimization options or other setting.
Then launch the program from the debugger. If the resulting EXE shows the crash when run normally but not when started via the debugger, there are more things to make the situations work the same (and that shows clues as to what is wrong, too). So let us know if that still doesn't reproduce.
There could be a lot of reasons for your application's Release is crashing.
Did you link proper Release libraries with your application in Visual Studio project configuration ?
Check your code for some missing Release specific code.
My best guess is you are not linking to proper libraries for the Release version of your application.
Also, one reason could be that your application may be trying to load some file that may not exist. This happens with me sometimes when my Release build of application does not find file that it needs (Eg: OpenGL application trying to load a shader file that is missing); and you don't check for errors.
I have a Visual C++ 6 project that is creating a COM DLL. This is an old project that I have not used in years but I came back to it recently to update some functionality of the DLL. The issue I am having is that when I try to manually register the DLL (using regsvr32) that is created by the project, I get no response whatsoever. It does not say it succeeds and it does not say it fails. I have verified that the DLL is not being added to the registry. I have never seen a situation with regsvr32 when it would not show any confirmation message.
Also, the DLL is set to self-register in the project and when it attempts to do this, it also does not show a message.
I have not touched this project in a long time, but the last time I did touch it, it worked without issue. Now I come back to it, and all of the sudden I am having this problem. It is as if the DLL being created by the Visual C++ project is not compatible with the current version of Windows. I have updated the development software to SP6 but it has not changed the situation.
I ran Depends on regsvr32 when it was pointing to the created DLL, and it shows this message:
LoadLibraryExW("C:\Source32\BIS\Projects\ALFA\DigiPixSvc\DigiPixObj\Debug\DigiPixObj", 0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH) returned NULL. Error: The operating system cannot run %1 (182).
Can anyone please tell me why this is happening and what I can do to correct it?
Disclaimer: since I don't have VS 6.0 installed anymore, I'll have to use some Google searches to give you the exact steps for the VC 6.0 dialogs - so some of this information may be inaccurate. I believe it's correct - it's really what you'd do in the current IDE, just for VC 6.0.
Before you go through the trouble of debugging your DLL, make sure you run it through Dependency Walker to verify that all your dependencies are on your machine. Don't run Dependency Walker on regsvr32 - what matters is whether your DLL has its dependencies. If they're missing, regsvr32 won't be able to load the DLL.
To see if your DLL is getting loaded by regsvr32 when you try to register it, you need to debug through the DLLRegisterServer() function and see what happens there - this is one of the 4 entry points a COM DLL must have and regsvr32 calls this function when the DLL is about to be registered. In order to do this, you'll have to set regsvr32 as the startup program of your project and pass the full path to your debug-built DLL as a command-line parameter to regsvr32.
Bring up Project Properties for your project.
Go to the Debug tab.
Make sure the General category is selected.
Enter the full path to regsvr32 in the Executable for debug session textbox.
Enter the full path to the debug version of your DLL in the Program arguments textbox. Make sure you have a PDB file for your DLL so you can see symbol information during debugging.
Put a breakpoint on the first line in DLLRegisterServer(). The code in this function may be long or short, depending on how it was created: generated by a wizard, written by a developer, etc.
Start debugging.
Your breakpoint should be hit and you should be able to step through the registration code and see at which point it fails.
when i try to run a application developed in vc++ on windows7,i get popup window saying that"the program can not be started because MSVCR80D.dll is missing from your computer,try reinstalling the program to fix this issue."
I googled it,it says that this DDL may not be present in your system or it has been got corrupted,Now i searched this file, i get this file at 20 different folder in win7.
I am not getting which file has been corrupted or if it is missing then where it is mising?
can anybody tell in which folder ,this DDL is missing or might be corrupted?
Thanks in advance. .
You're trying to run a Debug version of your program on a machine which does not have VS installed. The MS*D.dll files are not redistributable - they are installed were VS is installed. If you want to run executables on other machines, compile them as Release. You might still need to deploy some files (depending on how you're linking to the CRT), but that won't be a problem.
Never ever distribute your DEBUG builds to customers. Always distribute Release build.
Yes, of course, in develoment environment having multiple machines, you may share Debug builds to other developers - provided others developers have debugging-tools (like VS) installed on their system along with Debug-binaries of shared DLLs (like MSVCRxx).
Are you using the same computer that compiled the program? If not, you need visual studio redistributable files to run it.
Search the internet for your version of visual studio or visual c++ redist, you'll find it.
We have an installer application.
In that we have one dll related to our application.
We created setup with all respective files.
We used "Install Shield 6.3" and created a setup file.
After created build. The build is working in xp, not working in 2000.
It is showing error message as Couldn't load .dll only in win2000.
What could be the issue any idea?
Regards
Hara
It looks like one of the system/third party dll you are loading is either not available or of wrong version. Use a tool like dependency walker to check whether all the required dlls are available or not.
You have probbely missing prequsits that exits on XP but not on Win2000.
You need to run the Dependency Walker tool on Win2000 and load the problematic DLL, the tool will tell what is missing.
Try running installation with Filemon in the background, filtering with the missing DLL's name. Then, see where the DLL is searched for, and fix the problem. Hard to say without any further information, but first difference I have in mind is that the system folder in XP is C:\windows\system32, while in win2000 it is C:\winnt\system32. If you've hardcoded the system path for any reason, it might be the problem.