{"id":167,"date":"2007-05-12T16:31:01","date_gmt":"2007-05-12T14:31:01","guid":{"rendered":" http:\/\/www.nsonic.de\/blog\/2007\/05\/d5-debugging-dll-on-winxp\/"},"modified":"2007-10-18T15:44:30","modified_gmt":"2007-10-18T13:44:30","slug":"d5-debugging-dll-on-winxp","status":"publish","type":"post","link":"https:\/\/www.nsonic.de\/blog\/2007\/05\/d5-debugging-dll-on-winxp\/","title":{"rendered":"D5: Debugging DLL on WinXP?"},"content":{"rendered":"

Q: cannot debug DLLs with Delphi5 and WindowsXP
\n<\/em><\/p>\n

A:
\nSeveral threads address this issue, and here is the solution. The
\nproblem is restated here and three workarounds are given. Please keep
\nin mind that these solutions are from my experience on one Windows XP
\nmachine. You may have different experiences in your environments.<\/p>\n

-Sam
\n
\nPROBLEM
\n<\/b>
\nWhen debugging a DLL in Delphi 5 on Windows XP, you are unable to set
\nbreakpoints in the code. Delphi will stop execution when exceptions
\nare thrown, but it is unable to find the line of source that matches
\nup with the exception.<\/p>\n

This is problem is not specific to an isapi DLL. It can happen with a
\nregular DLL too. It is caused when the DLL is built to a directory
\ndifferent than the one the DPR file is in, which happens to be the
\ncase more often with an isapi DLL because you want to build to your
\nwebserver’s scripts or isapi directory.<\/p>\n

When Delphi attempts to load the symbol table for the DLL, it fails so
\nit can’t set any breakpoints. You can see this if you open the View |
\nDebug Windows | Modules dialog. Find the entry for your DLL. It will
\nnot have a Path specified. If you right click on your DLL and choose
\n“Reload Symbol Table…” you will be prompted to specify a path to the
\nDLL. It will default in the name of you DLL and if you click OK
\nwithout specifying the path you will get an error indicating that
\nDelphi was unable to find your DLL. This is exactly the problem.<\/p>\n

This problem is not specific to the webservers OmniHttpd or IIS.<\/p>\n

It does not help to add the DLL’s directory to the system path or to
\nDelphi’s search path, or to the project’s search path. It also does
\nnot help to run Delphi or your DLL’s host application under XP’s
\ncompatibility modes for other version’s of Windows.<\/p>\n

SOLUTION A
\n<\/b>
\nBuild your DLL to the same directory as the DPR file. If you just set
\nthe “Output Directory” entry to be empty on the
\nDirectories\/Conditionals tab of the project options, then this will
\nautomatically happen.<\/p>\n

Either use this directory as your webserver’s scripts or isapi
\ndirectory, or move the DPR\/DOF\/CFG\/RES files to your webserver’s
\nscripts or isapi directory. If you do the later through the Delphi
\nmenu option File | Save Project As, the Delphi will fix up the
\ndirectories of your source files in the uses section of the DPR for
\nyou. It is not necessary to move the PAS files.<\/p>\n

That should be it. Build and debug happily ever after. The only
\ndownside to this is that you have to either change your webserver
\nsetup or move your project file to your scripts or isapi directory
\nwhich is a annoying if you are using a source control system and you
\nare the only one with this setup.<\/p>\n

SOLUTION B
\n<\/b>
\nBefore compiling, change the linking options of your project to
\ninclude Remote Debugging Symbols.<\/p>\n

Before debugging, open a file (an empty text file will do) from the
\ndirectory your DLL is in. That directory will become the current
\ndirectory for Delphi. When you start debugging, Delphi will correctly
\nfind your DLL and load its Symbol Table because it is in this
\ndirectory.<\/p>\n

I don’t like this solution because you have to always make sure that
\nthe directory your DLL is in always the current directory for Delphi
\nbefore debugging.<\/p>\n

SOLUTION C
\n<\/b>
\nBefore compiling, change the linking options of your project to
\ninclude Remote Debugging Symbols.<\/p>\n

After you have started to debug, open the View | Debug Windows |
\nModules dialog. Find the entry for your DLL. If this is an isapi
\nDLL, make sure you have made a request to the webserver so your DLL
\nwill already be loaded, otherwise you won’t find it in this list.
\nRight click on your DLL and choose “Reload Symbol Table…” and enter
\nin the full path and filename for your DLL and click OK. This will
\nthen properly load the Symbol Table.<\/p>\n

A downside to this solution (other than you have to do it every time)
\nis that you can’t debug any code the executes when your DLL is first
\nloaded.<\/p>\n

Solution D
\n<\/b>
\nI can’t get any of the solutions to work, the only thing that works is when
\nI manually define the dll path in View\\DebugWindows\\Modules.<\/p>\n

->Just wanted to tell you I got it working. I checked Remote Debug info in the
\nlinker tab, and now it works!<\/p>\n

Cheers,
\nThomsen<\/p>\n

In German \/ Auf Deutsch:
\n<\/strong>
\nHier noch eine Zusammenfassung die ich im Internet<\/a> gefunden habe:<\/p>\n

Da Delphi 6 (Anmerkung: es betrifft Delphi5 genau so)<\/em> an vielen Stellen nicht mehr Up-to-date ist, was Windows XP angeht, muss man zu Kompromissen greifen. Es stehen gleich 4 Workarounds zur Auswahl:
\n1. Host-Anwendung liegt im gleichen Verzeichnis wie die zu debuggende DLL
\n2. Men\u00fcpunkt Ansicht | Debug-Fenster | Module | Symbol-Tabelle neu laden | Durchsuchen -> Pfad der DLL angeben
\n3. Alle Sourcecode-Dateien in das DLL-Verzeichnis kopieren und das Projekt in diesem Verzeichnis \u00f6ffnen (so dass Delphi alle Dateien finden kann).
\n4. ImageBase-Adresse der DLL auf der Linker-Seite auf einen Wert setzen, der im Host-Prozess garantiert frei ist, so dass Win32 die RVAs der DLL nicht neu setzen muss.<\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":"

Q: cannot debug DLLs with Delphi5 and WindowsXP A: Several threads address this issue, and here is the solution. The problem is restated…<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":""},"categories":[11],"tags":[105,75,97,104],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p71Tml-2H","_links":{"self":[{"href":"https:\/\/www.nsonic.de\/blog\/wp-json\/wp\/v2\/posts\/167"}],"collection":[{"href":"https:\/\/www.nsonic.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.nsonic.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.nsonic.de\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.nsonic.de\/blog\/wp-json\/wp\/v2\/comments?post=167"}],"version-history":[{"count":0,"href":"https:\/\/www.nsonic.de\/blog\/wp-json\/wp\/v2\/posts\/167\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.nsonic.de\/blog\/wp-json\/wp\/v2\/media?parent=167"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.nsonic.de\/blog\/wp-json\/wp\/v2\/categories?post=167"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.nsonic.de\/blog\/wp-json\/wp\/v2\/tags?post=167"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}