The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,969 other subscribers

Delphi: great post by Malcolm Groves about Debugging Initialization and Finalization sections

Posted by jpluimers on 2010/07/21

Long time Delphi user Malcom Groves just posted an interesting video on Debugging Initialization and Finalization sections.

What I especially like is that he performs this trick using the DUnit unit testing framework for Delphi.
+1 for using unit testing!

The trick he uses is an old one, but I didn’t realize that few people know it, so it is good to put it in writing.

Note that the trick does not work in all cases (see further on an alternative), but for most cases it does work well:

  1. Open your .dpr (From the Delphi menu, choose “Project” followed by “View source”
  2. Put a breakpoint on the begin and end of your program code (see listing below)
  3. Run your project
    (note: for some Delphi versions: you have to F7 into your project)
  4. At the begin of your program Press F7 (“Run” – “Trace into”) in stead of F8 (“Run” – “Step over”)
  5. At the end of each initialization section, press F7 again (not F8!) to step into the next initialization section
  6. At the end of your program press F7 (not F8!) to step into the finalization section
  7. At the end of each finalization section, press F7 again (not F8!) to step into the next finalization

Easy, when you know, difficult to find out yourself (I found out by accident eras ago <g>).

Sometimes (I have not found out why yet) some Delphi versions refuse to work this way.
So you need an alternative, which is this one:

  1. Make sure your project is compiled with “debug .DCUs” enabled
  2. Open de System unit (any where in your project type “system”, then with the cursor inside “system”, press Ctrl+Enter)
  3. Set breakpoints on the lines like this:
    (there are 2 instances of them, one in the “procedure InitUnits; “, the other in the “procedure FinalizeUnits;”
  4. When you hit the breakpoint, press F7 to enter the initialization section or finalization section of that unit.
program MyDUnitTests;



{$R *.RES}

begin // <--- put a breakpoint here, or use F7 to end up here; then press F7 to debug your initialization sections
  if IsConsole then
end. // <--- put a breakpoint here, press F7 to debug your initialization sections

Be sure to watch the video below by Malcolm Groves, it is very insightful.


via: Malcolm Groves | Debugging Initialization and Finalization sections.

9 Responses to “Delphi: great post by Malcolm Groves about Debugging Initialization and Finalization sections”

  1. Bertrand said

    Thanks for the post – I can’t get videos online, so this transcription is very welcome indeed!

  2. I have to say I agree with the first comment: “duh”.

    When I say the title of Malcolm’s post I was interested. When I saw what it was actually showing I was underwhelmed. This really isn’t that sophisticated.

    There are no “tricks” involved, just correct usage of the tools and a really very simple understanding of the runtime initialisation (and finalisation) sequence of a Delphi program, something that people shouldn’t be messing with if they don’t understand it.

    For me, F8 to “step over” a project that isn’t currently running does not surprise me when it starts in a “breakpoint” mode. Knowing that “initialization” sequences are performed before program execution starts, it is entirely intuitive then that F7 should “step into” the program and take me to the first initialization procedure and that F7 is required to ensure you step into each subsequent procedure in the chain, just as F7 at the end of any procedure is the most reliable way to step to the next line of executing code.

    I find the fact that these debugging “insights” are such a surprise and considered so secret and amazing just a little bit depressing, though I can’t quite put my finger on why it makes me feel that way.

    • jpluimers said

      Hence my “I didn’t realize that few people know it, so it is good to put it in writing” in the posting:
      (Apparently) there is a huge discrepancy between “us experienced” Delphi users, that understand initialization/finalization order, behaviour of F7, F8 and F9, and the “less experienced” people.

      Over the last few years I have become more and more aware of that gap, and it is one of the reasons I have started blogging, and even more reason for me to include things that I sometimes have learned more than a decade ago:
      “Fresher” people, can benefit from that.
      And looking at the view count of those posts: they do appreciate it!

      As a side note: you see this in other worlds as well.
      For instance on most conferences that cover various types of technology, the average level of sessions stays quite constant.
      The number of constant faces on those conferences over the years is remarkably low: more advanced attendees find other means of gathering info on their level; fresh people enter each year.

      This doesn’t hold for all kinds of conferences; there are a few conferences that have a very constant group of attendees. They feel more like ‘user groups’ than conferences, but in fact they are the latter.


      • Yes, I understand that. I think I find it saddening because it reflects on the level of ability and sheer curiosity of people coming to the tool.

        New developers these days are increasingly weaned on managed runtime environments and told that they don’t need to know how the framework/runtime works because it’s all taken care of for them.

        They lack the basic grounding in understanding how those frameworks and runtimes themselves work, and thus are completely adrift when the need to step outside their comfort zone.

        Everyone has gaps in understanding, the difference is a seeming inability these days for people to close those gaps for themselves.

        No-one ever taught or even showed me how to debug initialization/finalization sections. When I first encountered initialization and finalization I read-up on what they did, how they worked and combined that with knowledge of the simple debugging facilities that are easily understood.

        Adding 2 and 2 it came as no surprise to find the answer was 4.

        What is perhaps depressing is how many people lack the grasp of the fundamentals, and are thus ill-equipped to close their own knowledge gaps.

        That is definitely something that has changed over the years, I think as the result of the belief that the skills needed to be effective in “software development” have somehow changed and become much higher level, with no need to even understand the lower levels.

        • jpluimers said

          I’m like you: keen to learn the fundamentals of new technologies.

          At the same time, the field has broadened so much, that I only know a few people who can cover both the fundamentals and the breath.

          Changing times!


  3. Heinz Z. said

    # Open your .dpr (From the Delphi menu, choose “Project” followed by “View source”
    # Put a breakpoint on the begin and end of your program code (see listing below)
    # Run your project

    When I start my program with F8 the debugger stop at the begin of the dpr-file without a breakpoint.

  4. santos said


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: