I'm fairly new to DLL building and have what I'm sure is a dumb question, but I can't seem to find a solution anywhere:
I've dynamically linked to the DLL, the test calling program has no complaints and both tester and DLL compile cleanly. However, as soon as I hit a Win32 call in the DLL the program GPFs. It doesn't seem to matter which Win32 function I call - the call itself is resolving to an access violation.
I've looked at the addresses called, and they point into empty heap. Somehow all my Win32 functions are being lost. Does anyone know how this could happen
Win32 under DLLs?
mbutcher
Nevermind - it seems this only happens with the one app!
Well, at least now I know why I couldn't find any information on the problem. Now I just have to figure out what's odd about my test app.
Alexx4
Definitely need more information than this to figure out what's wrong. Could you give more details on what your DLL does, how the functions are exported, how you call the function, whether you are using MFC etc.
M Ram
The DLL is about the simplest that you can build - a Win32 DLL project, started as an empty project and exporting via a .def file. There's no Dllmain function, so I'm attaching to it with "LoadLibraryEx" and specifying "DONT_RESOLVE_DLL_REFERENCES". I have noted that just using "LoadLibrary" works anyway (failing the Dllmain call isn't fatal) but I thought I'd go by the book. I tried adding a Dllmain function and having it called just to see if it makes a difference, but it doesn't.
Right now the DLL doesn't do much of anything, I'm trying to set up an importing scheme that allows the whole program to be modularly re-organized post-compile and for the moment I'm just using place-holder DLLs. In short, it consists of a single function that calls CreateFile, WriteFile, and CloseHandle in order to dump some identity data to disk (through which I can track the order of DLL set-up). "Windows.h" is included locally to support this. The GPF hits as soon as CreateFile enters.
I tried this with a few other Win32 API functions - one doesn't have to set them up so that they'll work, they GPF before they discover any garbage parameters. It should be pretty easy to duplicate - in fact, unless this is something peculiar to my build environment (VC++ .net 2003) it should be almost impossible not to duplicate :).
There must be something obvious I'm missing here, probably some sort of compiler command (I also tried assuring that the DLL and the calling process used the same standard libraries, no change).
john mc
Found it - it was the LoadLibraryEx option after all - I went back to just using LoadLibrary and it worked (not sure why it didn't work the first time I tried that).