How to debug a crash that only occurs on application shutdown? (Delphi)

Question

So, after some recent changes we discovered that one of our oldest applications is sometimes crashing on shutdown. This manifests itself either in the form of \"Runtime error 21

Answer 1

Well the Runtime error 216 are memory issue (Access violation), it seems like you refer to some Object which doesnt exist at that point of time.

Emarcadero writes:

Applications that use the SysUtils class map most runtime errors to Exceptions, which allow your application to resolve the error without terminating

Did you try to set a breackpoint at the finalization section of Sysutils?

I would try it with an Allocation / Memory Profiler, its not sure you will find the error code line but this may show you some parts of your code where Memory issues occure.

Answer 2

"Runtime error 216" is from Windows itself, not the Delphi exception handler. I've found that it is caused by code that runs in initialization and finalization sections of units, which execute before the Delphi exception handler kicks in. Particularly. COM objects that need to unload through finalization code running after the Delphi App has terminated will cause this and similar errors. So check that stuff.

MNG

Answer 3

You've likely got a pointer problem. Some event or method is trying to run on an object that doesn't exist anymore.

Answer 4

Like others said: 216 means AV after SysUtils was shutdown. Usually, the only thing that shutdowns after SysUtils (and have chance to raise AV) - is System unit. Specifically: memory manager.

So, run-time error 216 at shutdown usually means memory corruption bug in your application.

That can be very easy to solve - just enable full debug mode in memory manager or use a debugging memory manager. Sometimes, however, it can be very hard to find. But you can start with debug mode of MM first.

See this article.

Answer 5

A runtime error 216 means that you have an Av (access violation) and SysUtils has already stopped translating those errors to exceptions.

First try: Build with debug DCU's and look in the unit system where the error is raised, set a breakpoint there. hopefully you can catch it in the debugger and work from there.

You probably have a memory bug (dangling pointer, null reference etc etc use of s string constant in an already finalized unit) and the best trick is to check the finalizations after sysutils is finalized. You can do this by building WITH debug dcu's, setting the break point to the finalization in sysutils and start stepping through the code until the error occurs.

Answer 6

Are you using runtime packages? I've seen similar issues before. If you're sharing globals or interfaces across package boundaries, you have to make sure that all references to classes that belong to a certain package get cleaned up before that package is unloaded; otherwise they'll try to make virtual calls into memory that's no longer valid.