Figuring out where you application crashed might take some time. Someone once wrote that "the most bug-free line of code is the one you don't have to write". This is true, but you might "write" a buggy Delphi application with no code at all. How's that? Delphi, as a Windows application, has its own bugs!
Yes that's true, even Delphi is not bug free.

Various bugs have various severity, some of the bugs have a workaround some of them have not. For example, the StateImage property for a TreeWiev will not display the 0th element in the TImageList. This bug is a just a basic IDE functionality failure - Delphi will still work. Another example of a bug in Delphi is more serious. Right click|New procedure in the Code Explorer while it is busy updating itself from a large file (e.g. Windows.Pas), generates AVs. After this, you'll need to restart Delphi.
The most serious bug is the one that crashes your program occasionally at run-time and when some special cases have occurred. For example, if a user passes a command line parameter to your program that is longer than 255 characters and then try to read this parameter using the ParamStr function an access violation will occur.

Note that the above bug examples might not exist in your (newer) Delphi version.

One excellent method of proactive error prevention is to always keep the current with all updates and patches for whatever edition and version of Delphi (BDE, ADO, ...) that you are using. Always have the latest patch for Delphi - the number of your programs bugs will drastically decrease.

The first question that pops up is: how do I know if a bug in my Delphi application is really "mine"?

   Borland's QualityCentral
"The QualityCentral project started (code named "BugCentral") as a community-based bug tracking system. It has evolved into a feedback application that has its own unique twist - it allows the entire Borland community to participate in a discussion with measurable value. There's not really a simple way to describe everything it does, but perhaps it can be summed up as a "request" box for Borland customers. When someone posts a "request," other community members can agree, disagree, rate, vote, or comment on that topic. These requests will be bug reports, feature suggestions, ideas for community articles, requests for content on the Borland web site, and so on"

Bug reports?
1. Any community member is able to submit a bug report for any product Borland is actively supporting.
2. When the "bug" is reported, it immediately becomes visible, and other commmunity members can provide feedback on it.
3. When the bug has been verified, communication among the reporter of the bug, Borland Developer Support, QA, and R&D can then be brokered by the application, so all people interested in the bug can track its progress.

This is what one "bug-report" looks like: