Delphi DLL Debugging Help

29 May, 2007 (12:00) | Delphi, Developer

Borland Developer Studio (BDS), CodeGear Developer Studio (CDS), Embarcadero RAD studo:
Help tutorial guide on how to best debug bugs in DLLs using Delphi 4, 5, 6, 7, 2005, 2006, 2007, 2010 and C++ Builder

BPG files – avoid them when you want to debug DLLss
Even if you mark/select the DLL project you want to debug in the list of projects, you will still have troubles if following conditions are present:

Your DLL project uses relative search paths. (Set in project options.)
- And example with relative project search paths and Delphi IDE:
  - 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 executable (if just the DLL file, ignore this), you will also need to configure your executable with remote debug symbols as mentioned in above section. In he 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 program process.
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.

Attach to project – attach into a multi thread application
It can often be useful to attach into a running project to see what the various threads are working at. However, setting a break point at all possible places is tedious. Here is the solution:

Select “Run – Attach to process” and choose your application.
Select “Run – Program pauses”
Select “View – Debug windows – Call stack” and view the different thread call stacks.

COM DLL programming – paths are important
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.

Remember extension – “.dll” in interface declarations
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 alignment issues – when passing data
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'

Threads – the less the easier to debug
If possible, create 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)

Last solution – search and ask in discussion groups
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 no-one ever mentioned in the various discussion groups (probably because my problem was quite rare to encounter). Good places to find answers include:

Epilogue – when I experienced my “DLL hell”
The product for which I wanted a multiple DLLs / plugins and for an application was Automation Batch Tools which comes with a DLL plugin SDK for developers. While the term DLL hell usually refers to problems associated with a “visual” and “basic” development tool (not Delphi!), I dare to say that I have gone through my amount of DLL hell