Problems with debugging after migration.

[SneakyPeaky99 0]

Hello,

I have a problem with debugging program in Delphi. From some time I am bringing back to life a very old project that was initially written in Delphi (around 20 years ago), I updated whole code to be buildable under newest Delphi 11.3. I am using Rad Studio for Delphi 11.3, in project-group there are a couple of separate projects. Some of them are stand-alone modules of this application, and the rest of them are using some other project in this project-group. After some trouble I managed to run debug on most of the projects, but ... and there is a question of this post. Some module can't be debugged, although breakpoints are set in the entry point of the application, debug .dcus are enabled, program throws errors like: Runtime error 204 at 0027BE19 and other error like: Project name.exe raised exception class EIdException with message 'Extension already exists'. Can someone explain to me what should be steps necessary to resolve this types of errors or where should i start looking for solution. It is strange because program does not seem to start (because no breakpoints are hit) but errors are thrown anyway. On top of that sometimes when I try to debug program, IDE annoyingly doesn't hit my breakpoint but instead shows 'CPU' file with assembly code. Can someone tell me how can i get rid of that, I have tried many solution from the internet but non of them solved this problem for me. My last question is the following, nearly all the applications in this project are launched with arguments. Surprisingly after providing arguments with RAD Studio option Run->Parameters some of them are causing strange behaviour. For example after typing '/regserver' as a parameter of the application (which is correct argument for this app) debug doesn't start. IDE seems to be compiling the project but then it doesn't run it. Other parameters are working completely fine. Can someone tell me where should I start digging for information on these topics, or maybe someone has a solution for them.

[Fr0sT.Brutal 900]

EIdException is likely thrown by Indy. Probably units register some extensions twice in unit init code and exceptions there are always painful. You can observe all kinds of weird behavior incl. unknown exceptions, app crashes and silent closing.

Try to find what method throws it in Indy and track the duplicated call (or use debug DCU's and place breakpoint at exception raising to see call stack)

Edited June 21, 2023 by Fr0sT.Brutal

[Remy Lebeau 1396]

9 hours ago, SneakyPeaky99 said:

program throws errors like ... Project name.exe raised exception class EIdException with message 'Extension already exists'.

That error is raised by Indy's TIdMimeTable class when a file extension is being added that has already been added.  But looking at Indy's default logic, although I do see several duplicates being added, the dupes are explicitly ignored when invoked by Indy itself.  It is only when user code adds an extension that such error can be raised.  And even so, TIdMimeTable is typically used only on-demand at runtime. never at design-time or at program startup.

Edited June 21, 2023 by Remy Lebeau

[SneakyPeaky99 0]

Thank you for advice, i have managed to determine where was the problem with 'Extension already exists' exception. I have one more question, do you know any way to solve errors like: "Runtime error 204 at 0027BE19"? Or do you know any place i should start looking for solution? Code on the right side is an address code given in hex but it doesn't give me any clue what is going on.

[PeterBelow 238]

2 hours ago, SneakyPeaky99 said:

Thank you for advice, i have managed to determine where was the problem with 'Extension already exists' exception. I have one more question, do you know any way to solve errors like: "Runtime error 204 at 0027BE19"? Or do you know any place i should start looking for solution? Code on the right side is an address code given in hex but it doesn't give me any clue what is going on.

See the list of error codes here. 204 is an invalid pointer operation, which may be caused by corrupted memory (stack overwrite, writing beyond the bounds of a heap-based memory block, etc.).

Open the project in the IDE, place a breakpoint on the first code line after the "begin" of the DPR file, run under the debugger until you hit this breakpoint. If the error pops up before you reach the breakpoint it is triggered by code executed from a unit initialization section. In this case build with debug dcus and place a breakpoint on the first line of the initialization section of system.sysutils.

After you reach such a breakpoint you can use the "go to address" function of the debugger. This hides in the context menu of the disassembly view (View -> Debug windows -> CPU Windows). Make sure you have "debug information" selected in the active project configuration. When you type in the address do not forget to start with a "$" sign to flag the typed text as a hex value.