Is there a way to print messages to output window with CppUnitTestFramework in Visual Studio.
There is TRACE() function to display messages from program in the debugger Output window in MFC.
I want to know whether that kind of function exists or not with CppUnitTestFramework.
The Logger class in the CppUnitTestFramework namespace has two simple functions for this:
Logger::WriteMessage(const wchar_t* message);
Logger::WriteMessage(const char* message);
In the VS IDE, the output can be seen in the "Tests" console output window and can also by clicking the "Output" link seen in the detail panel at the bottom of the Test Explorer.
On a build server the message will appear in the log for the test phase.
I just realized the following when debugging a CMake (non-qt) project with QtCreator (not using it because of Qt but because it's a nice IDE) and CDB.
The program has a simple cout code line which is properly displayed in the "Application Output" pane when I run the program with Ctrl+R. However, if I debug the same build&run configuration with F5, I cannot see any output.
Where does QtCreator forward stdout to in the second case?
You can see the output printed on the debugging logs, which is a pane under Window->Views->Debugger Log
The right pane shows the expected output. Not a full solution but a very close workaround.
I believe qt creator sees only the output from cdb and it doesn't forward the program's output, but only its own. In fact, the application output pane displays one line of cdb's output related to a system call I make within my program.
This workaround causes a weird side-effect. When cdb hits a breakpoint, the colorscheme of that pane gets reset to default.
On a sidenote, there was a closed bug report stating
There is a difference to the old debugging engine in that the
printf()-output of console-applications is suppressed in
debug/console-builds of Qt Creator builds. In previous versions, the
output used to go to the terminal Qt Creator was started in.
Not true in my case, as launching qtcreator from cmd detaches from cmd.
Try using std::endl or std::flush (if you don't want to change line) at the end of cout, e.g. std::cout << "Hello" << std::endl;
In Windows, OutputDebugString() goes to the "Application Output" window.
You can filter out noise by adding your own Message function:
https://doc.qt.io/qt-6/qtglobal.html#qInstallMessageHandler
I wanted to set breakpoint in the dll code so I introduced the statement "_asm int 3;". IE is supposed to open a dialog box saying that an unexpected exception has occured, and whether to close or debug. But it simply cuts down the window. The dll is a _Debug version not _Release version.
Another thing I noticed is that using the "debugger;" statement in the javascript code also causes the same behaviour - window dies without notice.
Why is this happening?
JIT debugging might be disabled. In your Visual Studio options, under Debugging > Just-In-Time, check the Native and Script options.
As an aside, you should probably call DebugBreak() instead of issuing _asm int 3. It's clearer that way.
When developing a Win32 Application (non-console application) in Visual Studio 2005, is there any way to get the same sort of output as you do from the console?
For instance, say I want to see log statements (such as I would with cout in a console application) to trace the path my program has taken in the code.
My first thought would be that this could be done through the Output tab selecting something from its "Show output from:" dropdown, when debugging but I don't know what API I need to do this...
For example say I had the following in my windows application and wanted to know when the following function enters and exits writing the result to the Visual Studio window above.
void someFunction(void)
{
Win32APIConsoleLog("BEGIN: someFunction()");
// ...
Win32APIConsoleLog("END: someFunction()");
}
Is this possible? And if so, what what libraries do I need to include and what function calls do I need to make to write out to the console window?
OutputDebugString.
I assume that you want to write to the debug console, since that's what your screenshot shows. OutputDebugString is a nop when no debugger is attached, but it allows you to log whatever you want to the debugger's output.
OutputDebugStringW(L"This will go to the output.\n");
// or
OutputDebugString("This will go to the output.\n");
When an application crashes on Windows and a debugger such as Visual Studio is installed the following modal dialog appears:
[Title: Microsoft Windows]
X has stopped working
A problem caused the program to stop
working correctly. Windows will close
the program and notify you if a
solution is available.
[Debug][Close Application]
Is there a way to disable this dialog? That is, have the program just crash and burn silently?
My scenario is that I would like to run several automated tests, some of which will crash due to bugs in the application under test. I don't want these dialogs stalling the automation run.
Searching around I think I've located the solution for disabling this on Windows XP, which is nuking this reg key:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
However, that did not work on Windows Vista.
To force Windows Error Reporting (WER) to take a crash dump and close the app, instead of prompting you to debug the program, you can set these registry entries:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting]
"ForceQueue"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\Consent]
"DefaultConsent"=dword:00000001
After this is set, when your apps crash, you should see *.hdmp and *.mdmp files in:
%ALLUSERSPROFILE%\Microsoft\Windows\WER\
See here:
http://msdn.microsoft.com/en-us/library/bb513638.aspx
regedit
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI = "1"
will make WER silently report. Then you can set
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\Disabled = "1"
to stop it from talking to MS.
I'm not sure if this refers to exactly the same dialog but here is an alternative approach from Raymond Chen:
DWORD dwMode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
SetErrorMode(dwMode | SEM_NOGPFAULTERRORBOX);
I had to disable this for release automation work on Windows 64-bits for Firefox and I did the following:
gpedit.msc
Computer configuration -> Administrative Templates
Windows Components -> Windows Error Reporting
Set "Prevent display of the user interface for critical errors" to Enabled
It is similar what was accomplished for Customer Experience reporting in:
http://www.blogsdna.com/2137/fix-windows-installer-explorer-update-has-stopped-working-in-windows-7.htm
In my context, I only want to suppress the popup for my unit tests and not for the entire system. I've found that a combination of functions are needed in order to suppress these errors, such as catching unhandled exceptions, suppressing run time checks (such as the validity of the stack pointer) and the error mode flags. This is what I've used with some success:
#include <windows.h>
#include <rtcapi.h>
int exception_handler(LPEXCEPTION_POINTERS p)
{
printf("Exception detected during the unit tests!\n");
exit(1);
}
int runtime_check_handler(int errorType, const char *filename, int linenumber, const char *moduleName, const char *format, ...)
{
printf("Error type %d at %s line %d in %s", errorType, filename, linenumber, moduleName);
exit(1);
}
int main()
{
DWORD dwMode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
SetErrorMode(dwMode | SEM_NOGPFAULTERRORBOX);
SetUnhandledExceptionFilter((LPTOP_LEVEL_EXCEPTION_FILTER)&exception_handler);
_RTC_SetErrorFunc(&runtime_check_handler);
// Run your tests here
return 0;
}
In WPF application
[DllImport("kernel32.dll", SetLastError = true)]
static extern int SetErrorMode(int wMode);
[DllImport("kernel32.dll")]
static extern FilterDelegate SetUnhandledExceptionFilter(FilterDelegate lpTopLevelExceptionFilter);
public delegate bool FilterDelegate(Exception ex);
public static void DisableChashReport()
{
FilterDelegate fd = delegate(Exception ex)
{
return true;
};
SetUnhandledExceptionFilter(fd);
SetErrorMode(SetErrorMode(0) | 0x0002 );
}
You have to implement an unhandled exception filter which simply quits your application, then set that filter function with SetUnhandledExceptionFilter().
If you're using the secure CRT, you also have to provide your own invalid parameter handler and set this with _set_invalid_parameter_handler().
This blog post has some information too:
http://blog.kalmbachnet.de/?postid=75
During test you can run with a 'debugger' like ADPlus attached which can be configured in many useful ways to collect data (minidumps) on errors and yet prevent the modal dialog problems you state above.
If you want to get some useful information when your app crashes in production you can configure Microsoft Error reporting to get something similar to ADPlus data.
This isn't a direct answer to the question since this is a workaround and the question is about how to disable that feature, but in my case, I'm a user on a server with limited permissions and cannot disable the feature using one of the other answers. So, I needed a workaround. This will likely work for at least some others who end up on this question.
I used autohotkey portable and created a macro that once a minute checks to see if the popup box exists, and if it does, clicks the button to close the program. In my case, that's sufficient, and leaves the feature on for other users. It requires that I start the script when I run the at-risk program, but it works for my needs.
The script is as follows:
sleep_duration = 60000 ; how often to check, in milliseconds.
; 60000 is a full minute
Loop
{
IfWinExist, ahk_class #32770 ; use autohotkey's window spy to confirm that
; ahk_class #32770 is it for you. This seemed to be consistent
; across all errors like this on Windows Server 2008
{
ControlClick, Button2, ahk_class #32770 ; sends the click.
; Button2 is the control name and then the following
; is that window name again
}
Sleep, sleep_duration ; wait for the time set above
}
edit: A quick flag. When other things are up, this seems to attempt to activate controls in the foreground window - it's supposed to send it to the program in the background. If I find a fix, I'll edit this answer to reflect it, but for now, be cautious about using this and trying to do other work on a machine at the same time.
After trying everything else on the internet to get rid of just in time debugger, I found a simple way that actually worked and I hope will help someone else.
Go to Control Panel
Go to Administrative Tools
Go to Services
Look down the list for Machine Debug Manager
Right Click on it and click on Properties
Under the General Tab, look for Start Up Type
Click on Disable.
Click on Apply and OK.
I haven't seen the debugger message since, and my computer is running perfectly.
Instead of changing values in the registry you can completly disable the error reporting on Windows Server 2008 R2, Windows Server 2012 and Windows 8 with: serverWerOptin /disable
https://technet.microsoft.com/en-us/library/hh875648(v=ws.11).aspx