DebugBreak vary between unmanaged and mixed (+ unmanaged hosting) application?

Following a simple source code (named as test.cpp):

#include <windows.h>

void main()
{
DebugBreak();
}

Use the following command to compile and link:

cl /MD /c test.cpp
link /debug test.obj

If TEST.EXE now run (on 64-bit Windows 7 systems), the following dialog:

 

 Now add the following source file (name it test2.cpp):

void hello()
{
}

Compile and link together with the first source, as follows:

cl /MD /c       test.cpp
cl /MD /c /clr  test2.cpp
link test.obj test2.obj

Note that we did not even call the function hello, just link it to come. Now run TEST.EXE again (on the same 64-bit Windows 7 systems). You will get the following results instead of the dialog box shown above:

 

Clearly, the link .Net framework in DebugBreak the behavior is different. Why is that? How can I restore the old DebugBreak behavior? It may be 64-bit Windows 7 or specific behavior?
To explain why I want to use DebugBreak, need to add that: assert framework (similar to a book supersassert John Robbin's "Debugging Windows Application") We have a custom, and I use DebugBreak function, so developers can Jump in case of problems to the debugger (or open a new debugger). Now only a simple pop-up window, can not jump to the debugger.
As another solution, I can perform divide by zero or write invalid addresses, but I found it to be a very clean solution.

This is the call stack second test (a simple dialog box) in:

ntdll.dll!_NtRaiseHardError@24()  + 0x12 bytes  
ntdll.dll!_NtRaiseHardError@24()  + 0x12 bytes  
clrjit.dll!Compiler::compCompile()  + 0x5987 bytes  
clr.dll!RaiseFailFastExceptionOnWin7()  + 0x6b bytes    
clr.dll!WatsonLastChance()  + 0x1b8 bytes   
clr.dll!InternalUnhandledExceptionFilter_Worker()  + 0x29c bytes    
clr.dll!InitGSCookie()  + 0x70062 bytes 
clr.dll!__CorExeMain@0()  + 0x71111 bytes   
msvcr100_clr0400.dll!@_EH4_CallFilterFunc@8()  + 0x12 bytes 
msvcr100_clr0400.dll!__except_handler4_common()  + 0x7f bytes   
clr.dll!__except_handler4()  + 0x20 bytes   
ntdll.dll!ExecuteHandler2@20()  + 0x26 bytes    
ntdll.dll!ExecuteHandler@20()  + 0x24 bytes 
ntdll.dll!_KiUserExceptionDispatcher@8()  + 0xf bytes   
KernelBase.dll!_DebugBreak@0()  + 0x2 bytes 
test_mixed.exe!01031009() 

This is the call stack (dialog with the "Close" and "debugging" option) The first test:

ntdll.dll!_ZwWaitForMultipleObjects@20()  + 0x15 bytes  
ntdll.dll!_ZwWaitForMultipleObjects@20()  + 0x15 bytes  
kernel32.dll!_WaitForMultipleObjectsExImplementation@20()  + 0x8e bytes 
kernel32.dll!_WaitForMultipleObjects@16()  + 0x18 bytes 
kernel32.dll!_WerpReportFaultInternal@8()  + 0x124 bytes    
kernel32.dll!_WerpReportFault@8()  + 0x49 bytes 
kernel32.dll!_BasepReportFault@8()  + 0x1f bytes    
kernel32.dll!_UnhandledExceptionFilter@4()  + 0xe0 bytes    
ntdll.dll!___RtlUserThreadStart@8()  + 0x369cc bytes    
ntdll.dll!@_EH4_CallFilterFunc@8()  + 0x12 bytes    
ntdll.dll!ExecuteHandler2@20()  + 0x26 bytes    
ntdll.dll!ExecuteHandler@20()  + 0x24 bytes 
ntdll.dll!_KiUserExceptionDispatcher@8()  + 0xf bytes   
KernelBase.dll!_DebugBreak@0()  + 0x2 bytes 
test_native.exe!00af1009()  

From the difference ! ExecuteHandler2 ntdll.dll @ 20 () begins. In non .net application, it calls ntdll.dll!@_EH4_CallFilterFunc. In .net application calling clr.dll! __ except_handler4 () .

In the following pages I found a solution: TTP: //www.codeproject.com/KB/debug/DebugBreakAnyway.aspx .

In addition to the preparation DebugBreak, must also _ the try / embedded DebugBreak calls between _except, as follows:

__try
   {
   DebugBreak();
   }
__except (UnhandledExceptionFilter(GetExceptionInformation()))
   {
   }

Obviously, the UnhandledExceptionFilter DebugBreak exception handling of default function in mixed mode applications, the abnormality appears to be rejected. Now get the original box.