Object Spy locks on application crash?
Currently working with an application which is c# .NET at it's core. And it spawns Delphi modules. I'm trying to write a crash handler for it. (It does crash during tests sometimes .... in variou...
Forum Discussion
Don't you just hate it when c#.NET apps spawn Delphi modules?
Since you already gather a lot of info about the crash, try terminating the application at a point after you get your info, but before it locks up TestComplete/TestExecute.
Tell those programmers to fix it! Fix it! Fix it!
Don't think the problem lies with my application.
The whole of TestComplete freezes up (other applications are OK) once this dialog box appears.
I found this:
My error dialog is coming from Werfault.exe. So it would appear that TestComplete still has problems with this. I'm going to see if I can find a way round it by killing everything process and service level after taking the information from the initial dialog. (The one prior to the WerFault one .... which is fine)
TC 11.20. Win 7 Pro 64 bit.
Killing everything at process level does the trick.
And is fine. As the application is about to stop/die at that point anyway. All the information of any worth is in the first Dialog and is captured and logged. The one causing the problems is just the "Has encountered a problem and needs to close" window. No useful info in it so no loss if I never see it ....
HKosovaAlumni
Hi Colin,
WerFault is one of those Windows components that cannot be automated through UI (similar to UAC), that's what causes the hanging. The way to deal with Werfault is to let TestComplete intercept the crash - which it does automatically during test runs. TestComplete will capture the crash dump, add it to the log, and suppress the WerFault window. So there is no need to interact with WerFault from tests.
For example, if an application crashes like this:
and the test looks like this:function Test() { TestedApps.CrashDemo.Run(); Sys.Process("CrashDemo").WinFormsObject("Form1").WinFormsObject("button1").ClickButton(); // Crash! // Note we don't handle the Werfault window in any way Delay(5000); // This line won't actually be executed, because the test will stop after the crash Sys.Process("CrashDemo").WinFormsObject("Form1").Close(); }then test will be stopped after the crash, and the log will have a link to the crash dump:
Could you please try and see if automatic crash interception works for your app?
Thanks for the info Helen. Does the AUT have to be run in debug mode for this to happen? As it currently just causes TC to freeze. (It's not just the object spy .... it's the entire application)
I don't want to stop the entire run at this point.
I should explain ....
I run using my own framework. Which also uses it's own logging system. I don't use the built in logs at all.
My tests are all keyword & data driven via user populated spreadsheets. Each spreadsheet constitutes a "test pack".
When the application crashes, I need to extract any relevant information from the crash Dialog (which I do .... it's not a WerFault one). Log it (using my own logs). Kill the application. Abandon the current test pack. Then move onto the next one. All test packs for this application expect to start with a blank slate (for consistency) so killing everything at process level before I abandon is fine.
I was going to look at running in debug mode next, but if killing it at process level does the job (it does) then I'm fine with that. I already have a routine to terminate all it's processes (there are quite a few) as this has to be done before a DB restore (which all test packs do at the start as well) anyway.
According to the devs, the crash I'm causing is an unusual ones. Most application errors are not handled by WerFault, they are dealt with using internal mechanisms. But the one I'm hitting is due to a 3rd party DLL we use, which does drop into WerFault. So in most cases, I won't have to worry about it. The internally generated Dialogs are handled no problem.