Forum Discussion

Colin_McCrae's avatar
Colin_McCrae
Community Hero
10 years ago

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...
Colin_McCrae's avatar
Colin_McCrae
Community Hero
10 years ago

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's avatar
Colin_McCrae
Community Hero
10 years ago

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

  • HKosova's avatar
    HKosova
    Icon for Alumni rankAlumni
    10 years ago

    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?

    • Colin_McCrae's avatar
      Colin_McCrae
      Community Hero
      10 years ago

      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.

      • HKosova's avatar
        HKosova
        Icon for Alumni rankAlumni
        10 years ago
        Colin_McCrae wrote:

        Does the AUT have to be run in debug mode for this to happen?

        Simple mode works too.

         

        Colin_McCrae wrote:

        I don't want to stop the entire run at this point.

        Crashes intercepted from WerFault stop the run only if "Stop on error" is enabled for the whole project (in project properties > Playback).

        They do not trigger Stop on Error for test items. This is because TestComplete catches crashes from all apps, not just the AUT, and we don't want third-party app crashes to interfere with the tests.