I guess this is kind of separate to the other thread ....
The only thing that comes to mind is exactly how you get to the point in the test run where the crash happens.
aka - how are you interacting with the controls to get this far?
To keep it short - always avoid using native methods outwith those which will happen through normal user interaction.
eg:
click - is fine. As this is the method that gets invoked when a user uses the mouse to click on something.
setText (on a textbox) - is not fine. This directly populates a value to the field and is not what the user would do. I always use Keys over setText as it's what the user does. They key in the value, one letter at a time. You could argue that setText mimics copy + paste into a field. Which maybe it does. Sort of. Copy and paste still involves clicks and/or key presses when a user does it. But when you use setText, it directly populates the value to the field. No clicks or keys required. So it's not equivalent to what a user is able to do. You will also miss any trigger events which may be present. Such as validation on keypress (often used if a field does not allow numeric characters etc etc).
So, what I'm wondering, is if you've used a method of a control somewhere in the test flow leading to the crash point that has left the software in an invalid state, thus prompting the crash.
So, have you used any methods other than clicks (of various types - left, right, double etc) or keys to get where you've got to?