I have a simple assertion macro that prints out a message. This usually works when the application is not a console application (i.e. I get a nice dialog that pops up, and has the expression including the message at which point I can hit retry to debug) but when it is, the console intercepts all the messages. This becomes annoying when the console hides behind the IDE and I have to fish it out, then go back to the assertion dialog, and hit retry to debug.
Is there any way to stop it from intercepting the messages so that the dialog that pops up has all the info.
The macro is this:
#define MyAssert(_Exp, _Msg) assert(_Exp && _Msg)
EDIT: Screenshot
The CRT attempts to work out where you want assert output to go to based on the type of application. It detects this from the type of the executable (/SUBSYSTEM). However, you can override with _set_app_type so that the CRT acts as if your console app is a Windows app. More likely, you just want to impact assertions and so should call _CrtSetReportMode to change to _CRTDBG_MODE_WNDW
You didn't specify your VS version, but these are availble (with subtle naming differences in VS2003) for all recent versions.
Martyn
Related
In the Microsoft Windows API, you can use SetUnhandledExceptionFilter, to set a handler for unhandled exceptions. The big catch, mentioned on that page, is:
If an exception occurs in a process that is not being debugged, and
the exception makes it to the unhandled exception filter, that filter
will call the exception filter function specified by the
lpTopLevelExceptionFilter parameter.
(emphasis added)
Which basically means, if the process is getting debugged, the debugger gets the exception, and my filter is skipped!
I can test & debug my ExceptionFilter the old-fashioned way, with printfs and trial-n-error.
But am I missing something? Is there a good way to interactively debug an ExceptionFilter if it is disabled when in a debugger?
Checkout the Resolution section of KB173652 which talks about placing all the code in main/WinMain in a _try/_except block like the following.
void main (int argc, char **argv)
{
__try
{
// all of code normally inside of main or WinMain here...
}
__except (MyUnFilter (GetExceptionInformation()))
{
OutputDebugString ("executed filter function\n");
}
}
Another article, Debugging custom filters for unhandled exceptions, describes a couple more techniques in addition to the one above. I personally use the one where you display a message box inside your exception filter and then attach the debugger. I use IsDebuggerPresent to determine whether to display the message box or not.
I know this post has been around for a while, but, I just happened upon it searching for something else. I’m happy to say that what user ‘abelenky’ asks is possible if the filter exists in a separate dll. You can debug an unhandled exception filter using a debugger. I’ve done it, and, here’s how:
The exception filter must exist in a separate dll. You’ll see why later.
You’ll need to add some code to the filter that displays a message box. I use the following code:
#ifdef _DEBUG
AfxMessageBox (_T("At this time, you must attach the debugger to this process in order to debug the filter code."));
#endif
The #ifdef is important because you don’t want the code executing in a Release build. I placed the above code at the very top of my filter.
To debug the filter:
Build a Release version of your application in Visual Studio
(instance #1).
Build a Debug version of your filter in a second instance of VS (#2).
Copy the Debug version of the filter to the Release folder of your
application.
Start your Release application from the Debug menu “without
debugging”.
Cause a crash in your application.
When the debug message box (above) appears, change to the second instance (#2) of Visual Studio.
In the #2 instance, open the filter project in Debug (if it isn't open) and attach the
debugger to your Application instance.
Set a breakpoint in your filter code after the message box displays.
Close the message box and your breakpoint should be hit.
Continue to debug your code.
I have a third party encryption library, which may create a MessageBox if key creation fails. The failure can be caused by bad random number generation or other rarities, and in most cases, trying again will result in success. My code will attempt key creation up to three times before deciding it failed.
Now, the issue is that the program may be used with automation. If a MessageBox is created during automation, it will block the process forever, because there's nobody to click the 'OK' button.
Does anyone know of a way to catch when this message box is created and automatically close it?
Anything is fair game, as long as it's not something that will make security suites angry. This means no hooking or code tunneling.
In summary, I need to catch when a MessageBox is created and close it. The MessageBox's creation is outside of my control. Modifying the code at runtime is not acceptable.
Also, I've noticed there are some other similar questions, but they don't have the same requirements.
EDIT: Additional note, I can find the message box via searching through all windows until I find one with a matching title and then send it a WM_CLOSE message, but I don't think this is a great solution. I also have no guarantee that the message box has been/will be displayed, or how long after my call it will be displayed. It could display instantly, it could display 1200 ms later, or it could not display at all.
Just before you begin the encryption process, install a WH_CBT hook, and in its callback watch for an nCode of HCBT_CREATEWND. If you get a matching class name ('#32770 (Dialog)' ?) and a matching title either return a nonzero value from the callback, or if that doesn't work post a WM_CLOSE (or a BM_CLICK to a relevant button if selecting an option is necessary). Uninstall the hook after the process for not messing with every possible dialog your application pops up.
That sounds like bad design on the part of that library. Generally any sort of utility library (like encryption) has no business invoking any kind of GUI (unless you explicitly ask it to).
Is there possibly some configuration or setting in this library that could disable its use of message boxes?
If not, I'd suggest that you might want to investigate using a different library. After all, if the designers of this library have already made this kind of poor design decision once, then there may be other unfortunate surprises lurking in there.
You can hope that it will be found by GetForegroundWindow, but this may catch other applications. The more brute force way is to iterate over all windows with EnumWindows looking for something that has a caption or text equal to this shown by the library.
I have once "remote controlled" an application by sending mouse click events to some controls. I guess you would have to do this in a separate thread that is watching for Events if a window is opened. Pretty ugly but working...
Create a new thread. If your function fails and a Message Box is opened, obtain a handle to the message box by looping through the windows (GetTopWindow, GetNextWindow) and comparing the window's process id to the one returned from GetCurrentProcessId().
Or, you can avoid all the hard work and just hook the MessageBox API with detours. It's not very hard, and if you don't want to pay for detours, you can do it manually.
Call VirtualProtect and set the memory protection at MessageBox at PAGE_EXECUTE_READWRITE
Create a naked function, and use it as a trampoline.
Create a function identical in parameters to MessageBox (this will be your hook)
Create a jump from MessageBox to your hook function.
I would like to have the ability to process Win32 messages in a console app and/or inside a standalone DLL.
I have been able to do it in .NET with the following article and it works great in C# inside a console app and standalone DLL
http://msdn.microsoft.com/en-us/magazine/cc163417.aspx
Is there a way to do the equivalent with C/C++ Win32 APIs? I have tried doing RegisterClassEx(...) and CreateWindow(...) even passing in HWND_MESSAGE to hWndParent but the trouble is that after the "invisible" window is created messages are not being processed probably due to the lack of a message pump.
Where would the message pump go if you had a DLL entry point? I have tried creating another thread in a DLL and put while(GetMesage(..)) there but that did not work either.
Any ideas?
You need a message pump yes. The window also has thread affinity so it needs to be created on the same thread that you're running the message pump on. The basic approach is sound, if you include more code it may become clear what the problem is.
In addition to what Logan Capaldo said, you also have the problem that, as a DLL, you don't know at compile time what kind of process is going to be loading you at runtime.
If you are being loaded by a console application (/SUBSYSTEM:CONSOLE), then creating a hidden window of your own and setting up a message pump on that same thread will work fine (as long as you are the first window created).
If you are being loaded by a windows app (/SUBSYSTEM:WINDOWS) then you might run into problems getting messages. They will be sent to the top-level window in the hierarchy, which you didn't create. You'll need to get the hWnd of the main process and subclass it (if you aren't already).
If you are being loaded by a service, then you aren't going to get window messages at all. You instead need to use the RegisterServiceCtrlHandlerEx Function
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).