How does this happen?
-
I'm writing an application that loads a DLL midway through execution (it's a wizard). When I debug my program and step through the lines of code which load the DLL, I get a null pointer back and my error handler catches it just fine. But that's not my issue--the issue is, when I run the exact SAME executable file but I don't do it in debug mode, the program experiences a runtime error, presumably from trying to get functions from an invalid HINSTANCE pointer with GetProcAddress, which I do right afterwards. How is it possible for the same code to experience different behavior? Has anyone else run into this? I also see runtime differences between the debug and release versions of my code. Any ideas? Thanks alot, augy
-
I'm writing an application that loads a DLL midway through execution (it's a wizard). When I debug my program and step through the lines of code which load the DLL, I get a null pointer back and my error handler catches it just fine. But that's not my issue--the issue is, when I run the exact SAME executable file but I don't do it in debug mode, the program experiences a runtime error, presumably from trying to get functions from an invalid HINSTANCE pointer with GetProcAddress, which I do right afterwards. How is it possible for the same code to experience different behavior? Has anyone else run into this? I also see runtime differences between the debug and release versions of my code. Any ideas? Thanks alot, augy
Microsoft would call this "behaviour by design". The debug versions are much more error-tolerant than the release versions. The runtime error is caused by the invalid HINSTANCE variable (if
LoadLibraryreturns NULL). The debug version doesn't cause a runtime error, because, during the debug build phase, there is a compiler predefinition called _DEBUG. This predef causes the compiler to generate much heavier and more error-tolerant code, made especially for debug purposes. On the release versions, a _NDEBUG is specified. The idea is that you create code, then do a debug build, then run/step through the code to see if it is working smoothly. Then you do a release build. It is supposed to work this way. Trying to alter this behaviour is the same thing as trying to reinvent the wheel. The debug mode of Visual Studio, when ran with a debug build, is capable of cathing and handling numerous types of error that would quickly crash a release version. It is designed to help you predict errors and fix them beforehand when building your applications. The reason why your error catcher doesn't handle "the NULL pointer" error in a release build is probably because you either have forgotten to use a try - catch block or then you are trying to check the error handler after theGetProcAddressis called. When HINSTANCE parameter is NULL,GetProcAddresswill cause a runtime error. Check the HINSTANCE parameter instantly after you callLoadLibrary. For more detailed error analysis, you should paste the library loading code here. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible. -
Microsoft would call this "behaviour by design". The debug versions are much more error-tolerant than the release versions. The runtime error is caused by the invalid HINSTANCE variable (if
LoadLibraryreturns NULL). The debug version doesn't cause a runtime error, because, during the debug build phase, there is a compiler predefinition called _DEBUG. This predef causes the compiler to generate much heavier and more error-tolerant code, made especially for debug purposes. On the release versions, a _NDEBUG is specified. The idea is that you create code, then do a debug build, then run/step through the code to see if it is working smoothly. Then you do a release build. It is supposed to work this way. Trying to alter this behaviour is the same thing as trying to reinvent the wheel. The debug mode of Visual Studio, when ran with a debug build, is capable of cathing and handling numerous types of error that would quickly crash a release version. It is designed to help you predict errors and fix them beforehand when building your applications. The reason why your error catcher doesn't handle "the NULL pointer" error in a release build is probably because you either have forgotten to use a try - catch block or then you are trying to check the error handler after theGetProcAddressis called. When HINSTANCE parameter is NULL,GetProcAddresswill cause a runtime error. Check the HINSTANCE parameter instantly after you callLoadLibrary. For more detailed error analysis, you should paste the library loading code here. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.Interesting. I figured as much, but I didn't know that the debug version would change runtime behavior THAT much. Anyways, I do check the HINSTANCE immediately afterwards for a NULL value, before any GetProcAddress() calls, hence my utter confoundment. After running it a few times, the problem has gone away (but without ANY change in the DLL loading code), and my simple check on the HINSTANCE ptr seems to catch it. Why or how this changed, I still haven't got a clue; I was using the debug version.
-
I'm writing an application that loads a DLL midway through execution (it's a wizard). When I debug my program and step through the lines of code which load the DLL, I get a null pointer back and my error handler catches it just fine. But that's not my issue--the issue is, when I run the exact SAME executable file but I don't do it in debug mode, the program experiences a runtime error, presumably from trying to get functions from an invalid HINSTANCE pointer with GetProcAddress, which I do right afterwards. How is it possible for the same code to experience different behavior? Has anyone else run into this? I also see runtime differences between the debug and release versions of my code. Any ideas? Thanks alot, augy
the_augy wrote: How is it possible for the same code to experience different behavior? Has anyone else run into this? All the time ;) I'm not sure, but I think one reason could be that a debug mode is much slower then the release. There is however nothing you can do about it. Just try to do it in a different manner. (PS: you can even get different errors when your breakpoint is set or not) "If I don't see you in this world, I'll see you in the next one... and don't be late." ~ Jimi Hendrix