Sign in to follow this  
Running_Wolf

DLL problems

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Why don't you run under a debugger to see what is going on?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this