DLL problems
Author
I'm encountering some weird results while trying to load a DLL.
First, even though the DLL is in the current directory and in the Windows system32 directory, LoadLibrary fails.
Second, in my code after calling LoadLibrary, I check to see if the resulting handle is NULL, which indicates failure. It is NULL, but the program keeps running anyways and skips the return statement.
Any ideas as to why this could be happening? I'm using Visual C++ .NET 2003.
Post some of your code, but it sounds like you have built a release version of the program but still have it defining the symbols. I know that this can produce unexpected debug output and has gotten me a couple of times when trying to debug.
Also, check the modules dlg to make sure that it isn't actually interfacing with the DLL in question.
Also, check the modules dlg to make sure that it isn't actually interfacing with the DLL in question.
Author
The code in question is as follows.
coreHandle = LoadLibrary("Core.dll");
if (coreHandle == NULL) {
return ERROR_OPENING_LIBRARY;
}
It completely skips the if statement even though coreHandle is NULL, indicating an error loading the library. About the symbols, how do I tell if it is still creating the symbols in Release build mode?
coreHandle = LoadLibrary("Core.dll");
if (coreHandle == NULL) {
return ERROR_OPENING_LIBRARY;
}
It completely skips the if statement even though coreHandle is NULL, indicating an error loading the library. About the symbols, how do I tell if it is still creating the symbols in Release build mode?
Author
Running the debugger is how I know it is skipping the if statement. All values are as they should be, and yet it doesn't do what it is supposed to.
I am sure you are building a debug version of the application, but check to make sure you are not building a release version. Because I do not have VS 2003 .NET up and running at the moment, you can check to see if your sysmbols are being loaded from within the "Modules" dialog that is provided to you when running the application. Look for the name of the application within the list, and scroll to the right. On that window it will tell you if the module loaded has debugging symbols loaded. To see if you are building the symbols in release mode, go into the project settings and check all the options for "Build Debug Symbols" or something along those lines. Like I said, I don't have it open at the moment. I am sure you already know this, but debug your application from the debug version, not the release. Just stating this again, as the AP already did.
What is coreHandle? Is coreHandle a HMODULE?
What is coreHandle? Is coreHandle a HMODULE?
Author
coreHandle is an HINSTANCE.
All projects are in Debug mode. Core.dll, and the application both.
All projects are in Debug mode. Core.dll, and the application both.
Here are a few things to check/try:
1) Any chance that Core.dll relies on another DLL that's not in the search path? Visual Studio comes with a tool called DEPENDS.EXE, which lists the dependencies for a DLL or EXE, and it will highlight dependencies that aren't found in the search path.
2) Don't put the DLL in two places in your search path. One will get out of date, and you could spend a lot of time hunting down phantom bugs when you run it from the wrong directory.
3) If you have any optimizations turned on at all, it can cause the debugger to fail to match up with the source code in the debugger. (It is possible to enable compiler optimizations for the Debug configuration, but it's generally a bad idea.)
4) Do a manual clean, and then rebuild. I've had cases where an obj file had a newer timestamp than a more recent cpp (sometimes due to version control software timestamp updates), so the build dependencies didn't catch and build recent changes.
1) Any chance that Core.dll relies on another DLL that's not in the search path? Visual Studio comes with a tool called DEPENDS.EXE, which lists the dependencies for a DLL or EXE, and it will highlight dependencies that aren't found in the search path.
2) Don't put the DLL in two places in your search path. One will get out of date, and you could spend a lot of time hunting down phantom bugs when you run it from the wrong directory.
3) If you have any optimizations turned on at all, it can cause the debugger to fail to match up with the source code in the debugger. (It is possible to enable compiler optimizations for the Debug configuration, but it's generally a bad idea.)
4) Do a manual clean, and then rebuild. I've had cases where an obj file had a newer timestamp than a more recent cpp (sometimes due to version control software timestamp updates), so the build dependencies didn't catch and build recent changes.
Author
Thanks for all the suggestions and help!!
It appears that doing a manual cleaning of the files and recompiling fixed the problem. But now I have another one. The never ending problems, it is.
It appears that doing a manual cleaning of the files and recompiling fixed the problem. But now I have another one. The never ending problems, it is.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
