Debugging DLLs

D7Pro... wrote a DLL myself and attempting to use the DLL in another program which I'm also writing, so I have full source for both. The problem is something falls over in the DLL and I cannot use the debugger to find out exactly where and why. I've followed the Delphi help which goes as follows:

"The following topics cover issues when debugging DLLs.

Specifying the host executable

When debugging a DLL, you don’t need to add the host executable file to a project to debug it. You can specify a path name to the executable by selecting Run|Parameters and entering the path to the executable in the Host application edit box. Press the Load button to load the executable in the debugger.

Using Module load breakpoints when debugging DLLs

Use Module load breakpoints to halt an application when it loads a specified DLL. To set a Module load breakpoint either:

Select either Run|Add Breakpoint|Module Load Breakpoint
      Choose View|Debug Windows|Modules to display the Modules window and right-click anywhere in the upper-left pane and select Add Module

Then in the Add Module dialog box, enter the module name of the DLL or click Browse to find the DLL. Click OK. When the application loads the specified DLL, the application will halt.

Setting a debug source path

The debug source path is specified under Project|Options|Directories\Conditionals. Debug source paths for modules in the current project, or project group, are automatically set. If you are debugging modules (executables, DLL) in different projects or projects groups, you need to add the debug source path for each module that is not part of the current project group.

Locating symbol files

All dcp files must be located in the Debug Symbols Search Path (set on General page of the Tools|Debugger Options)."

I can set a breakpoint in Delphi on a line with a blue dot. As soon as I choose Run or Load Module, that blue dot disappears and the line is never stopped at (although I know damn well it is using it). The program itself runs fine (apart from the error inside the DLL).

I've set the debug search paths to everywhere possible (source of the exe, source of the DLL). All the debugging options are on for both the DLL and the EXE.

Any ideas?

Geoff M.
Who is Participating?
LunchyConnect With a Mentor Commented:
PAQed, with points refunded (250)

Friendly Neighbourhood Community Support Admin
DLL debugging always seems to be a little hit-and-miss in Delphi...

Make sure you compiled the DLL with full debug enabled.

Make sure you compile your client application with full debug enabled.

Tyhpically, I DON'T debug the DLL with a host appplication - I debug the client application, and it seems to be able to walk into a DLL.

Breakpoint in the client on a line that calls a DLL function. Step into the call (F7). It might ask you to find the source file - Do it. Then usually it works....

I think there's a little black magic involved, somewhere.

If you lose breakpoint dots, delete all the .dcu and .tds files, and do a full rebuild of both projects. That sometimes helps...
gmayoAuthor Commented:
Sorry, this question is awaiting deletion. I found the solution: even though Delphi built and compiled one DLL, it actually ran with another DLL in another directory. Why, I don't know. Deleting the other DLL worked.

Thanks anyway.

Geoff M.
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

You can delete them yourself if there haven't been any comments added!

Wim ten BrinkSelf-employed developerCommented:
Suggestion: how about PAQ'ing this question and refund the points to gmayo? This is a very typical error when people decide to debug a DLL and I have seen a very frustrated collegue dealing with a similar error in the past.
Btw... That other directory, is that part of your 'PATH' environment variable? Is it e.g. in your C:\WinNT or C:\WinNT\System32 folder? :-) My collegue had this problem. He expected the DLL in his project folder to be used but instead he ran the one in the C:\WinNT\System32 folder.

Oh, a reminder from thw Windows platform SDK:

When no path is specified, the function searches for -> loaded modules <- whose base name matches the base name of the module to be loaded. If the name matches, the load succeeds. Otherwise, the function searches for the file in the following sequence:

1) The directory from which the application loaded.
2) The current directory.
3) The system directory. Use the GetSystemDirectory function to get the path of this directory.
    Windows NT/2000/XP:  The name of this directory is System32.
    Windows NT/2000/XP: The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
4) The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5) The directories that are listed in the PATH environment variable.

Windows XP:  If HKLM\System\CurrentControlSet\Control\SessionManager\SafeDllSearchMode is 1, the current directory is searched after the system and Windows directories, but before the directories in the PATH environment variable. The default value is 0 (current directory is searched before the system and Windows directories).

This was just a little advise, free of charge. :-)
Wim ten BrinkSelf-employed developerCommented:
Of course, deletion of this question is also still possible... :-)
gmayoAuthor Commented:
The app was in one directory, C:\TMS, and the DLL was in another directory, C:\TRESISDLL. The DLL had been copied to the C:\TMS directory to enable that to run. But when compiling the DLL, the version it compiled was put into the C:\TRESISDLL directory but run from the C:\TMS directory. Probably like (1) and (2) you mention above.

To be honest, I think Borland have fallen down in this respect. There is no mention in their help files of such a thing possibly happening.

If everyone would prefer this question to be awarded points and PAQd, then that's fine by me (I've got unlimited points anyway!).

Geoff M.
gmayoAuthor Commented:
Okay, that's fine by me. Thanks.

Geoff M.
All Courses

From novice to tech pro — start learning today.