Windows CRT and approval reports (abort, redo, ignore)

Question

In Windows CRT debugging mode, the “Undo, redo, ignore" window will be displayed if the application falls into assert(false) , and sometimes it is created many times and fills my screen.

I would really like it if the statement broke off in the debugger and did not ask me any questions.

I changed CRT reporting flags that did not affect.

I also tried changing the binding. It is called after 25-30 Cancel dialogs appear.

I am creating a DLL loaded by a separate program if this helps. It also looks like the host program loading my DLL is not consistent with the thread calling my code. It seems that one of the threads has been stopped, but the rest are still working.

How to configure CRT for this?

Answer 1

This works (at least compared to 2008): (Essentially return TRUE from the hook function)

 int __cdecl CrtDbgHook(int nReportType, char* szMsg, int* pnRet) { return TRUE;//Return true - Abort,Retry,Ignore dialog will *not* be displayed return FALSE;//Return false - Abort,Retry,Ignore dialog *will be displayed* } int _tmain(int argc, TCHAR* argv[], TCHAR* envp[]) { _CrtSetReportHook2(_CRT_RPTHOOK_INSTALL, CrtDbgHook); assert(false); getch(); return 1; } 

You can also write your own behavior similar to the statement (note that this will show the “Break, continue” dialog):

 #define MYASSERT(x) { if(!(x)) {DbgRaiseAssertionFailure();} } int _tmain(int argc, TCHAR* argv[], TCHAR* envp[]) { MYASSERT(false); getch(); return 1; } 

Hope this helps!

Answer 2

Liao's answer will give you most of the way, but I would suggest adding one more thing to your debugger:

 int __cdecl StraightToDebugger(int, char*, int*) { _CrtDbgBreak(); // breaks into debugger return TRUE; // handled -- don't process further. } 

Otherwise, your statements will simply disappear and the process will end.

The problem with this approach is that - at least for my home installation of VC Express - the debugger throws a big message "program.exe that caused a breakpoint message" instead of the usual confirmation failure, so there might not be a big improvement.

Answer 3

I'm not sure if you want the behavior to be for any assert , or just trying to use assert(false) specifically as a general purpose template to unconditionally enter the debugger on this line. If this is the first, see Answers Liao and Kim. If this is the last, then you really should use the __debugbreak built-in function.

Answer 4

Why is he claiming? assert (false) looks like "it should never be", the code was executed in CRT. I would be scared if I were you. Is it always on the same line? Are there any comments around him?

EDIT: I mean: assert occurs in CRT code because there is an assumption that it checks that you are not dating (you may have managed to associate with a mixed runtime or you created a managed assembly in C ++ and forgot to manually initialize CRT, or you are trying to call LoadLibrary from DllMain or some other thing that should never happen).

So, before you figure out how to suppress claims, find out why this is the first thing to say. Otherwise, you will most likely run into unresolved issues later and will be very funny trying to debug them. (from your question it is not clear if you know what statements are)

Code like this

 if(somebadcondition) { assert(false); // recovery code } 

literally means "this code branch should never be executed."

Answer 5

Why not use the DebugBreak Function ?

Or even use the opcode?

 #ifdef _X86_ #define BreakPoint() _asm { int 3h } #else #define BreakPoint() DebugBreak() #endif 

Prior to Visual C ++ 2005, instruction ,

__asm int 3 did not cause native code to be generated when compiling with / CLR; the compiler translated the instruction to interrupt the CLR instruction. Starting with Visual C ++ 2005, __asm ​​int 3 now leads to the generation of native code for the function. If you want a function to call a breakpoint in code, and if you want this function to be compiled with MSIL, use __debugbreak.