Archived

This topic is now archived and is closed to further replies.

kuphryn

DLL & free() Heap Access Violation

Recommended Posts

Hi. I am learning about dll. I created a simple dll with one class and one member function that returns a string object. The function looks something like this. ----- string MyClass::MyFunc() { string text = TEXT("Testing 1 2 3"); return text; } ----- In the main program, I statatically link the dll to the program. Everything compiles fine. However, the program crashes right after MyFunc(). ----- // Statically link DLL. #include "MyDLL.h" void MyWinClass::F1() { // Instantiate MyClass as local variable MyClass oneVar; // Attempt to get text from oneVar''s member function // MyFunc() should return a string object. It does. string newText = oneVar.MyFunc(); ----- Everything works up to and including the last line of code. I could even open the text MyFunc() returns. There is a big problem, however; the program crashes. This is the error Visual C++ shows when the program crashes after calling a function via the DLL. ----- HEAP[MyProgram.exe]: Invalid Address specified to RtlValidateHeap( 00360000, 00353FA0 ) Unhandled exception at 0x77f7f570 in MyProgram.exe.exe: User breakpoint. ----- In debug mode, the debugger shows a message box that mentioned something about "_BLOCK_TYPE_IS_INVALID(pHead->nBlockUsed)." Is there something wrong with the dll? The algorithm above works find if I call MyFunc() from inside another class. It seems that the program is trying to free something after return from the dll. Thanks, Kuphryn

Share this post


Link to post
Share on other sites
Magmai Kai Holmlor: Good point. I compiled the DLL in a separate project. Here is how I did it.

- project1 is DLL only
- project2 is EXE statically importing DLL

I thought it is okay to compile a dll separately and then using .dll, .lib, and .h files in any other project that will statically import the dll. Furthermore, you can use the .dll file in any project that dynamically imports the dll.

If the message I receive is what I believe it is, you need to compile all DLL and EXE in one project if and only if you want to statically import DLLs.

Thanks,
Kuphryn

Share this post


Link to post
Share on other sites
niyaw:

Thanks. I missed your message. Do I need to set the compiler for multithreaded DLL runtime in all projects that statically import DLL? Do I need to do the same for all DLL projects? How about projects that dynamically import DLLs?

Kuphryn

Share this post


Link to post
Share on other sites
niyaw:

Thanks. I missed your message. Do I need to set the compiler for multithreaded DLL runtime in all projects that statically import DLL? Do I need to do the same for all DLL projects? How about projects that dynamically import DLLs?

Kuphryn

Share this post


Link to post
Share on other sites
Okay. I believe I see the problem. The problem has to do with setting the compiler (Visual C++ .NET) to compile both the DLL project and EXE project (both debug and release versions) to "Multi-threaded DLL /MD."

The niyaw mentions is correct. Everything works, except for one problem. I am using MFC doc/view as program core. I have set the compiler to "Use MFC in a Static Library." I believe when you set to that option, the compiler automatically changes "Multi-threaded DLL /MD" to "Multi-threaded /MT."

So the bottomline is that the original problem has to do with multithreaded DLL setting and can be fixed. However, if I fix that problem, I cannot use MFC via Static Library. That is okay too, but then I would have to gather all MFC dll into one zip file before releases the program. Some people do not have MFC DLLs.

Kuphryn

Share this post


Link to post
Share on other sites
if you want to share data that is obtained from a c runtime between different modules, such as new''d data, stdio FILE pointers, strdup()ed strings, and so on, you must use the dll version of the runtime. i would stay away from statically linking to mfc in your case because you (with a great likelihood) may experience the same problems. mfc generally thinks that there is only one copy of it for the entire process. so i''d suggest dynamic linking for everything. finally, i believe you only need to distribute mfc42.dll with your project, but check dependency viewer to be on the safe side.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Hey I made few standard dll and I''m worried someone might use it without my permission.
It is possible that someone could findout the parameters for my functions?
There is a way to stop people using the dll without my consent?

Thanks!

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
It is possible that someone could findout the parameters for my functions?


yup.
quote:

There is a way to stop people using the dll without my consent?


nope.

you can make it hard to reverse engineer your code, however, by packing and protecting your dll with one of the tools that exist precisely for that purpose. i''ve heard of asprotect (not sure if it''s the right name), try google for more.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I''m not worried about reverse engineering. I''m more worried about someone using the dll as it is.
One techinque came to my mind is to pass a number in the parameter and compare that parameter with a hardcoded number or word. It would work fine in my situation, except that I don''t want to put an extra comparision at the beginning of each function and I can''t find a way to do this when the module loads.

Dumpbin.exe shows all the export function in a dll, but is there a program that shows the formal parameters of a function?

Share this post


Link to post
Share on other sites
Anon brought up an important security factor about DLL. Maybe Microsoft and Borland will come up with ways to protect DLLs.

One possible way is to require a password when including the DLL and its libs as well as when openning the DLL.

Kuphryn

Share this post


Link to post
Share on other sites
just dug out this thread from my bookmarks. yes, i know it''d old.

one way to protect your data is to use interfaces instead of functions. export only one function that creates an interface (not necessarily containing addref/release/queryinterface, just an abstract class with some members) that in turn creates objects that do useful work. the exported functions will then become members of those ''useful'' interfaces.

you can go further by hiding the function behind a data export. export a variable that is located at the beginning of a block of memory, and put the pointer to the creator function at a predefined offset. you''ll getprocaddress() the beginning of the data block and use the offset to get to the creator function, call it to create interface implementations, and so on.

or you can set up a shared memory area (through a file mapping, for instance) with a name known to both your app and your dll, and store the creator function pointer somewhere in that area. this way your dll does not have any exports at all .

i''m pretty sure you can come up with even more obscure way to prevent people from using your code. have fun

Share this post


Link to post
Share on other sites