4

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.

Access violation upon exit

CPU window upon closing the exception dialog box

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.

Cary Jensen
  • 3,751
  • 3
  • 32
  • 55
  • 6
    Have you considered using MadExcept? – John Easley Mar 06 '12 at 19:40
  • madExcept would be an excellent call. If you aren't already using it (or something similar), then you probably need to run with debug DCUs and set some breakpoints in unit finalization sections. Then narrow down which unit is the problem and take it from there. – David Heffernan Mar 06 '12 at 19:48
  • We already set breakpoints in the finalization sections. This proved to be overwhelming, due to the number of units/components that are involved. Typically gave up after 10-15 minutes of stepping. We haven't looked at MadExcept yet, and it might be that AQTime Pro might also help. – Cary Jensen Mar 06 '12 at 19:52
  • @Cary Use bisection to narrow it down. Don't single step through the entire process! – David Heffernan Mar 06 '12 at 19:55
  • @David How would you use bisection during finalization? You don't know in which order the finalization sections will be executed. – gabr Mar 06 '12 at 20:04
  • 7
    @gabr Easy. Go to System.FinalizeUnits. Look at the while loop that walks the unit finalization calls, of the form `while Count>0`. *Offtopic: OMG, Count is 150 for a plain vanilla VCL app, do we really need so much just to show an empty form?* Set a break point that fires every, say, 75 times to work out which half we are in. Continue in that vein. Even with 1000 units, you'll work out which is the bad guy in 5 minutes. You probably don't use pure bisection because it's cheap to go forwards but expensive to go backwards. Oh how I yearn for a reversible debugger. – David Heffernan Mar 06 '12 at 20:16
  • 1
    I've found Exception.GetExceptionStackInfoProc is the best place to capture stacktraces in recent Delphi versions. You'd also have to implement Exception.GetStackInfoStringProc/CleanUpStackInfoProc. AQTime works great for me in situations like this as well indeed. – Giel Mar 06 '12 at 20:20
  • @DavidHeffernan some professor(can't remember his name) made a nice proof of concept(in java) that will hold snapshots of everything within your app step by step, you could go basically at any point in your app's history, however, he concluded that it wasn't more efficient than step by step, which I doubt... it would be nice to go back and forth... –  Mar 06 '12 at 21:16
  • 1
    @Cary is the application *purposely* being terminated before the main form is displayed, or is that part of the problem? – MikeD Mar 06 '12 at 21:30
  • 1
    @David Excellent! I would never thought of that. And I want a reversible debugger too. – gabr Mar 06 '12 at 22:21
  • @Jambog The termination is intentional. We know that we can change the order in which things are created to prevent so much initailization before termination is started, but we really want to figure out what is misbehaving. – Cary Jensen Mar 06 '12 at 22:22
  • What happens to application if you will continue the execution? – Alex Mar 08 '12 at 04:54

3 Answers3

5

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.

Deltics
  • 22,162
  • 2
  • 42
  • 70
2

  1. Go to View/Debug Windows/Modules, find cxLibraryD15.bpl and extract its base adderess. Now, substract $00E51B9E - base = offset.

  2. Run your application and immediately pause it. Go to View/Debug Windows/Modules, find cxLibraryD15.bpl and extract its base adderess (it could be the same). Now, add an offset from step 1 to it: base + offset = absolute address.

  3. Open breakpoints window or CPU view and set breakpoint at address from step 2. Now you'll stop right before exception occurs, thus you can see call stack and analyze the situation in the debugger.

Alex
  • 5,477
  • 2
  • 36
  • 56
  • This is exactly the answer I needed to find an exception when a critical section wasn't being correctly initialised. – Tom Leys Jan 23 '15 at 04:45
0

Try to set breakpoint to KiUserExceptionDispatcher, RaiseException and Exception.GetExceptionStackInfoProc.

Alex
  • 5,477
  • 2
  • 36
  • 56