Delphi dll debugging
Author: Thomas Schulz
Created: 2002-12-21 [approx] (yyyy/mm/dd)
Updated: 2007-05-29
Related: Borland Developer Studio (BDS), CodeGear Developer Studio (CDS) and C++ Builder
Abstract: Help, tips, and tricks on how to best debug bugs in dlls using Delphi 4, 5, 6, 7, 2005, 2006, 2007
|
BPG files - avoid them when you want to debug dlls
Even if you mark/select the dll project you want to debug, in the list of possible projects,
you will still have troubles if following conditions are present:
- Your dll project uses relative search paths (set in project options).
-
Another example highlighting the problem with relative project search paths:
- Use the open dialog to open a file in the same directory as the project file.
- You can open project files located in e.g. ..\shared in the code editor using CTRL + ENTER.
- Try open a file located in a different directory. You can no longer open files in ..\shared.
-
Jean-Claude Servaye proposes following solution:
- Go to the Control panel > System > Advanced panel.
- Click on Environment variables.
- Add the absolute path of the dll to debug in the system paths.
- Reboot the machine.
- Your dll project is in another directory than the other projects (possibly just if different from last project in list).
Debug info - always compile / build with all enabled
- You need to enable all relevant settings in Project > Options > Compiler.
- Whenever you try to debug from one project into another, the into project needs to have set Project > Options > Linker > Include remote debug symbols.
How to debug - host application, attach to process etc.
- If you want to debug both your dll and exe (if just dll, ignore this), then you will also need to configure your exe with remote debug symbols as mentioned in above section.
- In dll project choose Run > Parameters > Host Application and fill in the path to the compiled .exe file.
When the exe application is running, choose (from the dll project) Run > Attach to Process and pick your running exe.
- Set a breakpoint in the dll project where the exe will enter your dll. Now initiate the required actions in the exe for it to occur.
- Refer to the help for more usage variations.
Build project - before running and debugging
This lessens the chance of Delphi stating (while e.g. stepping from a breakpoint):
the source has changed since last build.
Blue dots - appearing wrong places on builds
Although this can be caused by other things (in my experience at least)
a primary reason seems to be a CR/LF problem that exists in Delphi:
The IDE and compiler disagree on end-of-line.
For Windows/Linux/Max this means that text/files written in one OS can cause problems in another.
So, if you use Windows, and suffer from the above problem,
try use e.g. NotePad to open and save the problematic file with.
COM dll programming - paths are important
Many people encounter problems with COM debugging when the file
path is not in 8.3 format: No spaces or long file names in path.
One such problem is setting breakpoints in code.
Jean-Claude Servaye sent the following solution:
- Search the registry for the filepath of the COM. This is in 8.3 format.
- Change it to the long file name format and the breakpoints are available.
Remember extension - ".dll" in interface declarations
Even if some Windows versions can handle leaving out the extension,
it is safer to include it, e.g. like this: procedure Foo external 'example.dll'.
Remember alignment issues - when passing data
Alignment changed from e.g. D5 (4 byte) to D6 (8 byte). This means that if you have not
taken special care to use packed records, a D6 compiled .exe can not work properly with
a D5 compiled .dll if any data are passed through records.
Threads - the less the easier to debug
If possible, you can have a flag that prevents multiple threads from connecting to your dll;
This makes it easier to debug the logic of the code from within the Delphi IDE.
Other reasons - for access violations, errors, exceptions, and memory leaks
As with everything else it is still possible to make and have pointer errors etc.
Here is a list of miscellaneous links and tools to solve common problems:
-
Access violations, exceptions, memory leaks: You should probably check out memory leak detection tools such as
MemCheck (compiled-in source)
and
MemProof (software program).
-
IIS debugging: Check Debugging ISS5.
Last Solution - search and ask in newsgroups
This page was never meant to be a full guide about Delphi dll file debugging.
I originally created this page because the thing that helped me, knowing how BPG files are handled,
is something noone ever mentioned in the newsgroups (probably because my problem was quite rare to encounter).
Epilogue - when I experienced my "dll hell"
The product for which I wanted my
multiple dlls / plugins and one host application architecture was
Automation Batch Tools.
This program was my pet project for quite some time. You can view and download the
SDK as well.
While the term
dll hell usually refers to the
problems associated with deployment issues and certain developer tools
(not Delphi), I dare to say that I have gone through my amount of troubles!
Language
