views:

295

answers:

1

This is related to regular assert(...) There are two scenarios that I'm interested to improve in my code. 1) a debug build app is started regularly, if there is an assertion I'm getting "Debug assertion failed" dialog box with "Abort", "Retry", "Ignore". Abort and Ignore answers are working fine. The problem with Retry. If I hit retry I'm getting that useless "Application error, breakpoint has been reached" "OK" - to terminate, "Cancel" - to debug the program. WTF would I see that useless dialog with default focus on "OK", which is to terminate, after I already made decision to debug the program?! Sometimes I just quickly hit space bar and the process is gone, I lost an opportunity to see what was wrong! So, the question here I have: is it possible, to avoid this dialog and directly go to "Just in time debugger" dialog that shows choices for debuggers. I understand that the nasty "Application error" dialog box is triggered by __debugbreak() or _asm int 3 on intel, so after "Retry" was pressed I need t somehow initiate debugger attach without using _asm int 3. Is this possible? I couldn't find any WinAPI that does this

2)a debug build app is started in VS debugger (using F5). If there is an assert triggered I don't want to see any dialogs at all, I want it to stop right on the line where assert is. I managed to install crt debug runtime hooks and if IsDebuggerPresent then I __debugbreak() and it stops on the line of the assert. It works perfectly when I'm debugging windows mobile builds, but I'm still getting useless dialog box for Win32 builds: "APP.exe has triggered a breakpoint", "Break", "Continue", and greyd out "Ignore". What a useless dialog box!! Any way to completely disable it, so I never see it??

thanks

+1  A: 

Take a look at the registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug.

I think that if you set Auto to 1, that the debugger is automatically started.

And of course changing the assert implementation can also help you (take a look at the SuperAssert of John Robbins from his famous Debugging Windows Applications book).

Patrick
pps
I know about SuperAsser, but I don't need anything from it. I use similar technique to get stack backtrace for memory leak detection, but in assert I don't find it to be useful, especially if I can attach with debugger and see what's wrong.The only thing that remains to be fixed is the "APP.exe has triggered breakpoint" dialog box.__debugbeak(); on PC builds trigger this dialogbox, but if you debug Windows Mobile code then I don't have this box and I'd like to find out how to skip it in pc build as well.
pps