Object Spy locks on application crash?

Question

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 various different ways)

I've hit a problem. When a sub-process crashes, the .NET part of the application throws a crash message. This first part is no problem. I map all the parts of the dialog box it generates. Capture all the error text and click the button to close it. (OK being the only button)

This is where the problem starts.

When this Dialog closes, it throws a second message box. Once this one is on screen, TestComplete becomes totally unresponsive and only comes back to life once this Dialog is closed (manually). Using CTRL+SHIFT+A I did manage to capture one button. But as soon as it captures that, it was completely unresponsive again.

As you can imagine, that makes doing anything with this Dialog box kind of tricky.

This is the name locator I did manage to capture:

Sys["Process"]("WerFault")["Dialog"]("<MY_APPLICATION>")["Window"]("DirectUIHWND", "", 1)["Window"]("CtrlNotifySink", "", 10)["Window"]("Button", "Close the program", 1)

(For the "Close the program" button)

Any ideas? If an application crash is going to cause the test kit to stop working, I may have a problem .....

(It is not a child object of the application I'm working on ...)

hkosova · Answer

Hi Colin,
&nbsp;
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&nbsp;suppress the WerFault window. So there is no need to interact with WerFault from tests.
&nbsp;
For example,&nbsp;if&nbsp;an&nbsp;application crashes like this:
and the&nbsp;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&nbsp;test will be stopped after the crash, and the log will have a&nbsp;link to the crash dump:

&nbsp;
Could you please try and see if automatic crash interception works for your app?

energizerbunny · Answer

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!

colin_mccrae · Answer

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:

https://community.smartbear.com/t5/Functional-Web-Testing/Preventing-crashes-when-running-testcomplete/m-p/73315#M13503

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.

colin_mccrae · Answer

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 ....

colin_mccrae · Answer

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)&nbsp;I don't want to stop the entire run at this point.&nbsp;I should explain ....&nbsp;I run using my own framework. Which also uses it's own logging system. I don't use the built in logs at all.&nbsp;My tests are all keyword &amp; data driven via user populated spreadsheets. Each spreadsheet constitutes a "test pack".&nbsp;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.&nbsp;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.&nbsp;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.

Forum Discussion

Object Spy locks on application crash?

6 Replies

Recent Discussions

Name mapping gone

TestComplete: Connect to Azure Cosmos DB

Connection string using managed identity authentication

Related Content

Data Structures for Application Object Definitions

Application under Test Crashes while Identifying the WinForms object

Process "crashed" and test fails when closing the application in test