Runtime Errors

Hi,



What runtime errors you are interested in?

To create a dumps of the tested application when it crashes because of runtime error, you may consider DbgServices object (http://support.smartbear.com/viewarticle/28808/, http://smartbear.com/forums/f74/t83801/test-complete-prevents-dump-file-to-be-generate/#83829) or Report Generator utility (http://smartbear.com/forums/f81/t83562/application-crash-dumps-full-dump/#83839).

To handle VBScript's runtime errors, you should use disable error handling with the

On Error GoTo 0

statement (not recommended and must be used only and when it is *really* needed) and check if the error occurred by using the Error object (see VBScript's documentation for more details and code samples).

For other managed first chance exceptions, Alexei is right that it is probably normal, however access violation exceptions are by definition only emitted from unmanaged or unsafe code, and the exception is only thrown after many attempts at reading unallocated memory, usually from a bad pointer, and indicates that the application's memory heap might be corrupted. This almost always indicates a bug in the application code. The managed equivalent would be a null reference exception, which will routinely occur in managed code for any code block trapping null references. Access violations cannot be trapped or handled starting with .NET 4.0 (other than by assemblies marked with a special attribute), and should be considered fatal.

Look at this post for my reference. You might remember it... ;)



What leads me to believe the debugger is actually causing the exception is what I have witnessed trying to resolve my problem described in the thread above. Same situation, application works fine alone, but the moment I attached ReportGenerator to my app's process, access violations in a loop. Application keeps working, but ReportGenerator logs hundreds of access violation exceptions. Mind you, this is all conjecture as only an inspection of your tool's source code would answer it, but I suspect your debugger actually (incorrectly) handles the exception thrown, without re-throwing it. For example, let's assume the debugger attaches to the tested application and then sits in a loop waiting for exceptions.

Try

    Do

        ' Polling loop here, might be some other construct but that doesn't really matter.

        ' Possibly trying to read from application's allocated memory in here, causing the exception loop in the first place.

    Loop

Catch ex As AccessViolationException

    ' Here the debugger catches the exception and reports it. After that it should re-throw the exception to let the application handle it.

    Throw ex   ' <== I suspect this is missing in the debugger

    ' Without the Throw, the exception is handled, and never gets to the application.

End Try

That error handling block (without the Throw) would likely cause the same symptoms both me and Muruqan saw.

Actually, assumption that the tested application did not crash and the quoted excerpt was the reason of why I wrote that the reported first chance exception may be ignored if it is expected by the tested application's design.

If the tested application does not crash, either as you say it does handle the exception (which it cannot if it is not a .NET application using framework 2.0 or 3.5, or 4.0 with the special attribute set on the assembly) or it never gets the exception.

Here is a graphical representation of my reasoning above:







What I suspect is happening is the exception is thrown originally at the debugger context, logged, and NOT thrown back to the OS. This makes sense for any non-CSE managed exception originating from the application context, because otherwise Watson would kick in and kill both the debugger and application, without letting the debugger clean up the application's mess and terminating gracefully. The CSE however MUST either be handled properly (by terminating the app and its entire context, that is now presumed to be corrupt) or thrown back to the OS so that Dr Watson can clean up.



The fact that the application works fine without the debugger, and that the application is not terminated when the debugger gets the CSE (that has either unwinded from a lower context unhandled or originated from within the debugger context itself) means that the debugger failed to properly terminate the app context, and the fact that the OS doesn't intervene means that the debugger has also failed to throw back the CSE to the OS.



This could happen only if the debugger caught the exception. If it didn't catch it, it would unwind to the OS.

The above also explains Microsoft's decision to disallow normal apps from catching CSE's from .NET 4.0 onwards.  How many times have you seen "Catch ex As Exception" in code? Applications linked against .Net 2.0 or 3.5 using this bad catch statement and failing to throw the exception back would improperly handle a CSE and leave itself in an uncertain unstable state. They could have removed the ability to catch them completely, but that would have broken compatibility with existing code, so instead the make sure that CSE's are treated as a separate class of exceptions, to be handled only by the OS or an authorized debugger context. This way the application is terminated and disallowed to further corrupt persistent data while in a corrupted state.

Hi Murugan,



First thing: I am not sure why you are using DbgServices and execute your tested application in Debug mode. DbgServices are a kind of monitoring debugger and can provide you with tested application's debug output and information about other events (http://support.smartbear.com/viewarticle/32704/) but this is usually not needed for the regular functional testing.



Test log provided on your screenshot contains the 'Unexpected window' record. This message is posted by TestComplete engine and is not related to the DbgServices. Unexpected Window event often can be used to handle different error events in the tested application. See http://support.smartbear.com/viewarticle/29307/, http://support.smartbear.com/viewarticle/31921/ and http://support.smartbear.com/viewarticle/31750/ as a starting point.

Hi Alexei Karas

Thanks for ur reply.i used debug services in my application and i m getting the following error
"First chance exception 0xc0000005 ACCESS_VIOLATION occurred at 0x7c80bfc9, read of address 0x01232000 at 0x7c80bfc9 (in C:\WINDOWS\system32\kernel32.dll)9:01:51 Higher"

wat is this error means...see the attached screenshot

Hi Hugo,



Thank you for the comment. Quite useful.

The only thing that I am wondering at is: Muruqan mentioned these first chance exceptions only because he ran tested application via DbgServices, which basically means that the application was run under debugger. It is my understanding, that application does not crash and no errors are reported if it is running as it is, without using DbgServices. If my guess is correct, then it means that these first chance exceptions are handled by either application itself or by OS. Just because they are not followed by the second chance exceptions and GPF errors. Isn't it?

I would appreciate if you can share some thoughts / links that explain what is going on if my above understanding is not correct.

If I had to guess, I would put my money on the debugger actually generating the exception. I know this happened to me while trying to use ReportGenerator a while back. If unmanaged code tries to read protected memory (i.e. a managed application's heap)  the same exception will pop out. Because the debugger services is actually the one handling the exception, my guess is you will never see a second chance exception (debugger causes the exception by trying to read the tested application's protected memory, debugging services notice the debugger, debugger handles the exception...).



You could try disabling the UAC and CEP, disable Windows Defender or any anti-virus, and making sure TC runs as administrator, but I am not sure if this makes a difference in the end.



The tested application might be handling the exception, if it was built under .NET 3.5 or less, but it's certainly not doing it properly if it is. You can clearly see a corrupted pointer in the second access violation in the screenshot. This might be a consequence of an indiscriminate Try...Catch block, where the block catches all exceptions, and some faulty unmanaged code is being called from within.



You can read more about Corrupted State Exceptions (which access violation is one of) here: http://msdn.microsoft.com/en-us/magazine/dd419661.aspx