Question

I am working onsite with a client, and I am trying to help them with a complicated problem. I am hoping that there is a tool or feature in Delphi that we can use to peer into the inner workings to help us locate the problem.

Here is a high level overview of the problem we are dealing with. This is a commercial application that is currently deployed in Delphi 5. Over the past year the application has been migrated to Delphi XE. The migration is almost complete, but there are some serious errors that are being encountered.

The application itself is very large, with hundreds of units and many third-party and custom components. In one specific situation that we are encountering, the main form is created and then the application is terminated before that main form is displayed. The result is a crash that occurs during this termination, as units are being finalized.

The debugger is breaking in the RaiseException function of kernel32, which is called by NotifyNonDelphiException. We tried to set a non-breaking breakpoint that logs the call stack from within NotifyNonDelphiException, but that does not give us anything useful. The call stack contains only methods that handled the exception, and that is RtlRaiseStatus and KUserExceptionDispatcher.

How do we identify the code that throws the original exception that is being handled by NotifyNonDelphiException?

---

edit: Here are two images captured following one instance of the exception. The first one is the raised exception, and the second depicts the CPU window after the exception dialog box is closed.

New Edit:

It has been more than a week since I posted this question, and I am impressed with the various answers. Some of the comments to the initial question were most valuable, but some of the answers themselves are very informative.

My visit to that client is over, and I will ask them to consider the answers that have been posted here. While we were not able to track down the actual source of the error, the cause of the error was more than obvious. Many years of tweeking the user interface without a serious refactoring left the application with an unstable log in process. When the log in was canceled by the user, the main form was in a partial state of initialization. When this process was not permitted to run its course, which was what happened when the user aborted log in, very serious finalization issues were present.

The company has purchased AQTime Pro to help identify future problems, but a refactoring of the login process is called for, and will solve the problem in the long run.

At one point I considered removing this question, but I have opted to keep it posted, since I believe that others will find the many excellent suggestions that were posted informative.

For the time being, I am accepting @Deltics answer, since I hate leaving a question without an answer. However, I ask viewers of this question to also consider all of the other answers and comments, and they are equally valuable.

Answer 1

Exceptions should never be allowed to “escape” from finalization (or initialization) sections for precisely this reason.

With very few exceptions [sic], any code in a finalization section should be enclosed in a try..except. What you do when you get an exception is up to you, but at the very least a call to OutputDebugString() will give you information when debugging and give you a point on which to set a breakpoint that will only cause a break when an actual exception has occurred.

finalization
  try
    // Perform finalization processing here

  except
    on e: Exception do
      OutputDebugString('%s: $s in unit %s', [e.ClassName, e.Message, 'MyUnitName']);
  end;
end.

NOTE: The OutputDebugString() call in this code is to my own “string friendly”, wrapper around the function in the Windows unit, extended to accept args.

Since you presumably don’t have such exception handling in your finalization sections, this will involve putting them in place before you can proceed. However, this exercise will improve the quality of your code overall, and make diagnosing any similar problems in the future that much easier (who’s to say that once you have identified and fixed your current exception, that some other finalization exception will not raise it’s ugly head?).

Also, the process of applying this exception handling will give you an opportunity to review each finalization section and determine whether it cannot be handled differently, with a view to eliminating as many finalization sections as possible.

This should not be considered an “unnecessary overhead” or a “waste of time” but an essential piece of housekeeping to bring your code quality up to an acceptable standard.

An Alternative Approach

An alternative approach is to manage your own list of finalization procedures, as we had to do before finalization sections were introduced. i.e. in the initialization section of a unit that current has finalization, remove the current finalization code into a parameterless procedure and register that procedure with a “finalization manager”.

Then, in your application, invoke the “finalization manager” at an appropriate time during application shutdown, to perform your finalization before any actual unit finalization takes place. This ensures that your finalization procedures are performed with the runtime exception handler still in place.

This also presents the opportunity for providing a more sophisticated “finalization manager”, with mechanisms to ensure that finalization procedures are performed in a specific, determined order (if required). This capability depends on how you implement your own finalization manager, naturally.