Fellow experts!
I have faced the following dilemma: some of our tools (executables) are started as scheduled tasks, some are started as services and others as usual desktop apps with interactive Windows user. We are using the code sharing strategy for source management (this is not debatable for this question).
So the solution I want to find is the following:
Detect UI operation at run-time which leads to hanging service/background task (such as say call to Application.ShowException, ShowMessage, MessageDialog, TForm.Show etc.). And when such an action detected I want to raise the exception instead. Then the operation will fail, we will have stack trace etc. but the process will not hang up! The most problematic hang up is when some event processing is done in transaction and then in some of the code used to process event suddenly (because of error in code, design, whatever) there is UI code executed then the process hangs and the DB parts can be locked!
What I think I need to do is: Use DDetours library to intercept WinAPI calls to a certain routines and raise exception instead (so that the process does not hang, but just fail in some method). Also I know that the creation of forms and windows does not hang the app, but only the tries to show them to the user.
Is there some known method of handling this problem? Or maybe there is some list of WinAPI routine set which hangs in service mode?
Thank you in advance.
I want to be able to catch any attempts of executing exit()/ExitProcess()/TerminateProcess() or any other such calls.
I thought about registering a handler with atexit(). This works fine for normal program termination (return from main()) or exit() calls (regardless of the thread that calls exit()), but ExitProcess() and TerminateProcess() bypass the handler I registered.
ExitProcess() documentation states:
Note that returning from the main function of an application results
in a call to ExitProcess.
But the observed behaviour is at least different in this regard.
Is there a method of registering a handler for process exit/termination what will always be called (except for external calls to TerminateProcess(), unhandled exceptions thrown by one of my threads or __failfast() calls, I'm guessing these are really impossible to catch).
There is the dirty option of hooking ExitProcess(), but I'd rather not do that.
EDIT: just so this is clear: I'm interested in my own process, not monitoring / controlling another process.
There is a Kernel Mode Event a device driver can subscribe to in order to get notifications of terminations of processes. This is preferred over trying to inject a DLL into processes for API hooks due to the myriad number of internal and external ways that process may end.
In Visual Studio 2010, I have a number of unit tests. When I run multiple tests at one time using test lists, I sometimes reveive the following error for one or more of the tests:
The agent process was stopped while
the test was running.
It is never the same test failing, and if I try to run the test again, it succeeds.
I found this bug report on Connect, which seems to be the same problem, but it does not offer a solution.
Has anyone else seen this behaviour ? How I can avoid it ?
Edit
I am still experiencing this bug, and so is many of my colleagues on the same software/hardware setup. I have evaluated the answers so far, but they don't resolve the problem. I am starting a bounty for a solution to this problem.
This message is caused by an exception on a thread different from the executing test thread. All answers so far boil down to this simple explanation. It is a known bug in Visual Studio not to display any sensible information in that case.
Visual Studio’s test runner totally chokes if a thread other than the executing test thread throws an exception: It gets swallowed and there’s no output, no chance to intercept and debug and no nothing except a burned-down smoldering mess that was supposed to be your unit test.
I've just experienced the similar problem: some tests fail and they are different in different test runs. I don't know exactly the reason why it happens, but it began to occur when I added a finalizer to one of my classes. When I disable the finalizer - the problem disappears. When I turn the finalizer on - the problem comes back.
Right now I don't know how to overcome this.
I was having this problem, and it turned out to be a problem in my code which the Test Framework wasn't catching properly. A little accidental refactoring had left me with this code:
public void GetThingy()
{
this.GetThingy();
}
This is of course an infinite recursion, and caused a StackOverflowException (I guess). What this caused was the dreaded: "The agent process was stopped while the test was running."
A quick code inspection showed me the problem, and my tests are now running fine. Hope this helps - might be worth inspecting the code looking for issues, or maybe extracting a bit into a console app and checking it works properly there.
I was able to find the source of my problem by looking in the test result file (/TestResults/*.trx) It provided the full details of the exception that occurred in the background thread, and once I resolved that exception the "agent processed stopped..." error went away.
In my case I was unintentionally launching the GUI in my unit test, which eventually caused a System.ComponentModel.InvalidAsynchronousStateException to be thrown.
So my .trx file contained:
<RunInfo computerName="DT-1202" outcome="Error" timestamp="2013-07-29T13:52:11.2647907-04:00">
<Text>One of the background threads threw exception:
System.ComponentModel.InvalidAsynchronousStateException: An error occurred invoking the method. The destination thread no longer exists.
at System.Windows.Forms.Control.WaitForWaitHandle(WaitHandle waitHandle)
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at System.Windows.Forms.Control.Invoke(Delegate method)
...
</Text>
</RunInfo>
This didn't provide any information on what test caused the error, but it did show me where the exception was, which was very useful.
This message is typically generated when the test process crashes and can happen when there is an unhandled exception on a background thread, a stack overflow occurs, or an explicit call to Process.GetCurrentProcess().Kill() or Environment.Exit. Another possible cause is an access violation in unmanaged code.
Something no one has mentioned is that there may be additional information in the event log. Usually you will not get much information on why the test crashed in the results, however in the event of an unhandled exception on a background thread, then the test framework writes details to the Application event log with source VSTTExecution. If there is no information written to the event log then it is likely one of the other causes listed above.
I encountered the same Problem and solved it while Removing
Environment.Exit(0);
So i am pretty sure, that this error occurs while your test or method under test, is causing the executing process to terminate.
In my case the solution was resolved by checking the Output Window.
'QTAgent32.exe' (Managed
(v4.0.30319)): Loaded
'C:\TestResults\bdewey_XXXXXX072
2011-01-11
17_00_40\Out\MyCode.dll',
Symbols loaded. E, 9024, 9,
2011/01/11, 17:00:46.827,
XXXXX072\QTAgent32.exe, Unhandled
Exception Caught, reporting through
Watson: [Exception message]
In my case I had a FileSystemWatcher that was throwing an error on a seperate thread.
Thanks for posting the question. I just ran into this problem and figured out a cause that you may be running into.
An asynchronous exception may have
occurred
During my test setup, I create an object that queues a worker thread in the thread pool. If I run through debugging fast enough my code passes.
If the worker thread kicks off and has an error BEFORE the test setup completes, then I get a result of Aborted with no reasoning.
If the worker thread kicks off and has an error AFTER the test has begun, then I get a result of : Error - The agent process was stopped while the test was running.
Important to note: this is a component that I use throughout several of my tests. If the test framework encounters too many of these errors it aborts the rest of the tests.
Hope this helps
I added try/catch blocks to the descructor ~ClassName(){} that were defined in any class involved in my tests. This fixed the problem for me.
~MyClass()
{
try
{
// Some Code
}
catch (Exception e)
{
// Log the exception so it's not totally hidden
// Console.WriteLine(e.ToString());
}
}
For finding out where the exception was thrown click on the hyperlink "Test Run Error" next to the exclamation icon in the Test Results window. A window with the stack trace is opened.
This helps a lot to track down the error!
I had the same problem and it was caused by a finalizer for an unmanaged resource (a file writer that was not getting disposed properly for some reason).
After wrapping the finalizer code in a try-catch that swallows the exception, the problem disappeared. I don't recommend swallowing exceptions like that, so it would obviously be wise to find out why the exception is occurring in the first place.
I have had this happening on the odd occasion, and the culprit almost always turns out to be threading.
Strangely enough all the tests would work fine on the development machines, then randomly fail on the build servers.
On closer inspection it turned out that although the tests were being listed as passed on the dev boxes, there were exceptions being thrown. The exceptions were being thrown on a seperate thread which didn't get picked up as an error.
The exception details were being logged against the test trace, so we were able to identify which code/tests needed to be modified.
Hope this helps someone.
In my case I had some unit-tests for a WCF-service. This WCF service was starting up 2 timers.
Those timers caused side effects.
--> I disable these timers by default and everything is fine!
BTW: I use WCFMock to fake the WCF service, so I have "real" unit tests around my WCF service
This error was caused by a Finalizer for me as well.
The Finalizer was actaully calling some DB code which wasn't mocked out. Took me a while to find it as it wasn't a class I wrote and the reference to it was burred quite a few classes deep.
I have run into a similar problem where a test is failing in TestInitialize and is also running code from a ddl from another of my projects. I get the error message as described above and if I try to debug the test, the test is just aborted without any exception details.
I suspect that the problem may be that the dlls from my other project are from a Visual Studio 2012 project and I am running my tests in a VS2010 project, and/or possibly that the UnitTestFramwork dll versions from the 2 projects are mismatched.
The problem can also be triggered by an Exception or Stackoverflow in Constructor of a TestClass.
As this error can have many different causes, I'd like to add another one for completeness of this thread.
If all your tests are aborting as described by the OP, the cause might be a wrong project configuration. In my case the target framework was set to .NET Framework 3.5. Setting it to a higher version through the project properties page (tab Application) resolved the issue.
I was able to determine what was causing my issue by looking in the Windows Logs > Application log entries within the Windows Event Viewer. Look for entries at the time the test bombed-out. I had an Error entry similar to below:
QTAgent32_40.exe, PID 10432, Thread 2) AgentProcess:CurrentDomain_UnhandledException: IsTerminating : System.NullReferenceException: Object reference not set to an instance of an object.
at XXX.YYY.ZZZ.cs:line 660
at XXX.YYY.AAA.Finalize() in C:\JenkinsSlave\workspace\XXX.YYY.AAA.cs:line 180
It was indeed a null reference exception within a method called from a class finalizer.
For anyone happening upon this old question and wondering what's being thrown from their thread(s), here's a tip. Using Task.Run (as opposed to, say, Thread.Start) will report child thread exceptions much more reliably. In short, instead of this:
Thread t = new Thread(FunctionThatThrows);
t.Start();
t.Join();
Do this:
Task t = Task.Run(() => FunctionThatThrows());
t.Wait();
And your error logs should be much more useful.
When running a Delphi application outside the debugger most exceptions that occur seem to be silently ignored (like an access violation). Sometimes however there appears the Windows error reporting dialog (send or not send, you probably know what I mean). What exactly does this mean? What errors trigger this behaviour?
Additional info: I have a global exception handler for my application that should log all unhandled exceptions. So, no exceptions should leave the application unhandled.
Thanks.
Most exceptions are not silently ignored when running outside the debugger. They are normally caught by the event loop in VCL applications, or fall through to the main begin/end in console applications, etc. The default aciton of the VCL event loop is to display a dialog containing the message associated with the exception.
It's if the exception escapes the application, either by reaching the main begin/end without being caught, or not being caught by the event loop, that the Windows error reporting steps in - functionally, it is an exception handler just like any other except at the very base of the stack.
It covers exceptions that are not handled by the application - if an exception propagates outside of the main entry point of the app, then WER will step in. This covers things like AVs, divide by zero, invalid handle access and other out of band or "chip" exceptions. Sometimes your code can attempt to handle those things, but if memory is corrupted too badly or what have you, then your code will die.
You will generally get problems if you have exceptions in threads that are not handled in the Execute method. The program will mostly be killed, but the behaviour is unpredictable and seems to depend on many things (like the number and state of other threads). Often the main window vanishes immediately, and any further exceptions will thus not be handled by the program, and this is probably what causes WER to catch them.
I made it a habit to have an outer exception handler in Execute that logs any unhandled exceptions and allows the thread to terminate cleanly.
Exceptions occurring in initialization and finalization sections would escape your global exception handler and trigger WER.
Our code library needs to be notified when the application is exiting. So we have subscribed to the System.Window.Forms.Application.ApplicationExit event. This works nicely for Winforms apps, but does it also work for other types of applications such as console apps, services, and web apps (such as ASP.NET)? The namespace would suggest that it doesn't, and it presumably gets raised when Application.Exit() is called (explicitly or implictly), which may not be correct to call for these other cases.
Is there some other event which would be better in these other cases or which would be more universal (great if it works for Winforms, too)? For example, is there an event for when Environment.Exit() is called (console app)?
I found a mention of an Exited event in System.Diagnostic.Process, but this appears to be for monitoring the exit of another process, and it does not appear to be received by a process about itself (for example, Process.GetCurrentProcess().Exited += Process_Exited; Process.GetCurrentProcess().EnableRaisingEvents = true;). I would think it might only be raised after the process has actually exited, so that wouldn't work.
This is particularly for .NET 2.0 and C#.
We finally found more about this (but by then my machine had been rebuilt and lost the cookies to my unregistered profile here; hopefully, it will let met post this answer).
Further investigation eventually found a few more events which we have found helpful:
System.Windows.Forms.Application.ThreadExit - Fires when a message loop exits
System.Windows.Forms.Application.ApplicationExit - Fires when all message loops exit
System.AppDomain.CurrentDomain.DomainUnload - Fires when a domain other than the default exits
System.AppDomain.CurrentDomain.ProcessExit - Fires when the default app domain exits
System.AppDomain.CurrentDomain.UnhandledException - Fires when an uncaught exception occurs, ending the app.
Only one of the DomainUnload or ProcessExit events are possible for a given app domain, depending on whether it is the default (top-level) domain for the process or was created as a subdomain (eg. on a web server). If an application doesn't know which it might be (as in our case), it needs to subscribe to both if it wants to catch the actual unload for itself. Also, it appears that UnhandledException (which as of .NET2.0 is always fatal) may prevent the other two events, so that may be a third case to handle. These three events should work for any .NET application.
There is a caveat that the execution time for ProcessExit is bounded (about 4 seconds?), so it may not be possible to do extensive "final" work in that event handler. It needs to be something which can be done quickly.
The Application events only apply to WinForms applications (we suspect they may not apply in pure WPF applications, however). The naming can be misleading because they are named for their most basic normal usage which has certain assumptions. ThreadExit does not relate to the actual System.Threading.Thread but rather to the message loop (Application.Run())) of a UI thread, and ApplicationExit similarly relates to the collection of application Forms on one or more UI threads. Normally, once the call to Application.Run() returns, called from the entry method of a thread, the entry method quickly concludes and the thread itself then ends. And once all UI threads have exited, a WinForms app is usually all done and exits.
Another event of note is the System.Windows.Forms.Application.ThreadException event. A Windows message loop can be configured to catch exceptions which occur in handling a message and send this event rather than let them be uncaught (and thus fatal) exceptions. Catching these exceptions allows the message loop (and that UI thread) to continue running (after aborting the current message handler). There can be only one subscriber to this event at any time for a given thread (subscriptions overwrite any previous subscriber), and it must be configured before any Form is created and subscribed before entering the message loop. See the MSDN help for this event and System.Windows.Forms.Applicaton.SetUnhandledExceptionMode() for more info.