I'm writing a few tests for a managed/unmanaged Winform application. Some of the bugs occur in the unmanaged part, and result in the process terminating due to an unhandled System.Runtime.InteropServices.SEHException exception .
When this exception occurs, Windows pops up a message box explaining the error.
Unfortunately, neither MS Test nor White recognize this. The test itself finishes successfully without any sign of error, even though I can see the message box pop up right before the test goes on and closes the application.
How can I detect this kind of exception?
The message box is the result of the default unhandled exception handling of a Winforms application.
I ended up looking for it after the test has finished. If the message box is there, I fail the test.
Related
I'm writing a game in C++ with a little known game framework known as Proton SDK by Seth A. Robinson. I am getting a runtime error like the one shown below..
Runtime Error!
I don't get trapped in the debugger, and the game still runs just fine while the dialog is open, but when I click OK on the dialog, the game closes.
I'm unable to provide any code as I've not been able to track down the cause of this problem simply due to the fact that the error doesn't trip up the debugger, instead just closes the program when I click OK and keeps it running while the dialog is open.
Other runtime errors show the usual abort, retry, cancel prompt, but this one just says "OK"?
I'm frustrated. I've been dealing with this issue for several months.
Am trying to use the project found here, I have made some modifications and the code works okey, but sometimes it throws the below error.
How can I suppress or handle that error message in code, as it stops logic flow from continuing untill the button is pressed manually
after debgugging abit, I can find the error is thrown in a delete line, it tries to delete a pointer and it prints std::bad_alloc then hangs
I would like to terminate application when error occurs, something similar to throwing an exception that cannot be caught.
When C++ exception is thrown and not catched, Visual Studio 2017 automatically opens the file where exception is thrown and points to the exact line of exception in a text editor, which is exactly what I want, except that I would also like to prevent exception from being caught.
I tried using abort(0) and std::terminate(), but then a message box is shown, instead of pointing to the line in text editor where application is terminated.
Simillary, exit(0) only displays message to debugger output which says that application has exited.
Is there a way to terminate application, but still make Visual Studio point to the line in text editor where application is terminated?
We have a legacy build infrastructure for nightly builds (implemented in Perl) to compile, link and unit tests our applications/plugins. On Windows, if the unit testing process crashes, this pops up a Modal Dialog which "locks" our build farm.
Is there a way (win32 API call, system config, env var, something...) to disable this behavior to have the child process terminate immediately on crashes, with no Modal Dialog and a non-zero exit status instead?
Thanks, --DD
PS: We compile with SEC (Structured Exception Handling) on Windows, to be able to "catch" crashes using catch (...), therefore avoiding this issue most of the time, but sometime that's not enough, since of course some crashes are not recoverable (if they corrupted the stack for example).
Depending on who's throwing the dialog, you may have to combine multiple approaches.
SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
...will shut up one set of dialogs.
You need to add an 'unhandled exception handler' that catches all exceptions: put a call to SetUnhandledExceptionFilter(handler) in your initialisation code and it'll call the handler routine. Really simple.
I use sample code from an old article, include a file called minidumper, call the exposed function, and you're done.
Here's some more example code, this pops a different dialog, but you can change that to simply write a message to a log file or similar.
If you're writing a pure .NET app, then you'll be more interested in this article.
Do not use the "catch(...)" statement because then you can miss the point of having unit tests.
What you need is a non-modal dialog, since the modal dialogs are for blocking the user from any further actions and the program execution (in your case the unit test runs) hangs up until the user makes his/her choice. Now the crash dialogs can't be avoided, but you need to see how your unit test framework handles these situations. I would say you missed something around the unit testing framework because if I have a crash in my applications I got just a log message about that from the Boost.Test stubs.
If you run your unit tests as a child process it shouldn't block your build bot, BUT: if a unit test case fails, you shouldn't continue the building process in my opinion.
You can use WSH to "script" your windows.
With it you can "simulate" that somebody clicked on the "Accept" button of the modal window, or send the ESC key to close that.
Regards.
I have an MFC application that spawns a number of different worker threads and is compiled with VS2003.
When calling CTreeCtrl::GetItemState() I'm occasionally getting a debug assertion dialog popup. I'm assuming that this is because I've passed in a handle to an invalid item but this isn't my immediate concern.
My concern is: From my logs, it looks as though the MFC thread continues to service a number of windows messages whilst the assert dialog is being displayed. I thought the assert dialog was modal so I was wondering if this was even possible?
The message box that shows the assertion failure has a message pump for its own purposes. But it'll dispatch all messages that come in, not just those for the message box (otherwise things could get blocked).
With a normal modal dialog, this isn't a problem because the parent window is typically disabled for the duration of the dialog.
The code that launches the assertion dialog must've failed to figure out the parent window, and thus it wasn't disabled. This can happen if your main window isn't the active window at the time of the assertion. Other things can go wrong as well.
You can change how Visual Studio's C run-time library reports assertion failures with _CrtSetReportMode. You can make it stop in the debugger and/or log to the output window instead of trying to show the dialog.
Dialogs (even a messagebox) need to pump the message queue, even if they're modal. Otherwise how would they know you clicked on the "OK" button?
If you need to stop everything when an assert triggers it's usually not too difficult to write your own implementation of assert() (or ASSERT() or whatever) that will break into the debugger instead of displaying a messagebox that asks if you want to break into the debugger (maybe only if it determines that the debugger is attached).