Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations MikeeOK on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Errors when loading 2DLLs

Status
Not open for further replies.

nico765

Technical User
Jan 7, 2006
1
FR
Hello,


I have some problems using c++ DLLs in delphi. My problems only appear when i doubleclick the compiled .exe and not when i use run (F9) in delphi.
I get the following error: "Access violation at address: 77F6CC66 in module ntdll.dll" when the dll is getting loaded.
I have tried different ways with different success (i am trying to load 2 dlls):
+ implicit linking: 2 dlls are loaded at the begining, the error occurs once the first function is called. But when I load only 1 dll (and therefore call only 1 function) the program works fine.

+explicit linking: 1st dll is loaded, function is called, dll is freed, 2nd dll is loaded, 2nd function is called, dll is freed, this works fine the first time, if i redo this step (without exiting program) i get the error.

+explicit linking: both dll are loaded using a procedure, i get an immediate error.

Thanks.

Nicolas
 
I am not sure if I will be of any assistance to your problem.I have had similar problems and felt like i'd share my thoughts to you.

I would suggest that you check the following:

- Are you defining the DLL function header with the right calling convention?
Typically it will be "stdcall".


- Does the DLL function you call internally allocate some memory and return a pointer?
In this case you should not free the pointer using delphi calls such as StrDispose, Dispose etc. Instead you should find out whether there is a routine within the DLL that will actually free the memory allocated.

... each distinct application, whether an .exe or .dll, manages its own heap. All subsequent problems arise simply from having one exe/dll mistakenly manage a piece of memory that does not live in its own heap...

Zarko Gajic


- Are you using ShareMem in your delphi? (i doubt you are)
ShareMem has been infamous of bugs and i think even in Delphi 2005 the problems are still there. You probably are NOT using ShareMem because its typically used when loading DLLs created with Delphi and it basically means that the DLL and the calling application would share the memory.

If you are using ShareMem (and you must) then dont use it. Instead last time i checked Borland's bug report on this Borland's workaround was to use FastMM4 memory manager.


- Finally because you say the program runs fine from within delphi its worth to check that you dont have multiple copies of your DLLs and when running the program from Delphi it loads and uses a different one (the one that works) whereas when called from simply double clicking the program it uses a different one (the one that does not work). This is possible at least with Delphi 2005, because it is actually possible to add overrides to the Windows PATH variable which are only active while the Delphi IDE is running.


Hope this helps you.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top