I have a very similar problem to this post, but with a single-threaded C++ program: when an assertion fails during debugging in Visual Studio 2013, the debugger exits immediately without showing the assertion failure message box, which is supposed to look something like this:
(This picture is not from my own code.)
The only error message is:
The program '[5156] myprogram.exe' has exited with code 3 (0x3).
which makes it nearly impossible to figure out where the assertion failure occurred since the code base is very large.
The response to the linked question suggested adding a call to:
_CrtSetReportMode(_CRT_ASSERT, _CRTDBG_MODE_DEBUG);
at the beginning of the program, so that the assertion error is at least printed to the output window. However, this is not only hacky, but also not necessary for any other program I have debugged in Visual Studio.
This is not my own Visual Studio project, and I'm wondering if there is a rogue setting somewhere. I have enabled "Break when an exception is thrown" for assertion errors in Debug -> Exceptions, so that is not the issue.
How can I force the "Debug Assertion Failed!" message box to appear when an assertion fails?
In my case, the problem was that Configuration Properties -> C/C++ -> Code Generation -> Runtime Library was set to "Multi-threaded" for both the Debug and Release builds. The correct setting is "Multi-threaded Debug" for the Debug build and "Multi-threaded" for the Release Build.
You can try set a custom invalid_parameter_handler.
I encounter a similar problem when using vs2017.
the following code will not trigger debug assertion fail notice when i use my vs2017 to debug.
char dst[128] = { 0 };
char src[256] = { 0 };
memcpy_s(dst, sizeof(dst), src, sizeof(src));
but when i set a custom handler. it works. Checkout this link
Related
I have taken over a Xamarin.Forms (C#) application from an external source for fixing.
Problem is, that the application does sometimes fail with a runtime error:
System.NullReferenceException: Object reference not set to an instance of an object
The message appears in the output console and in a separate message window in Visual Studio. Unfortunately neither gives any more information about the failed object, a source code line number or a classname, there is just the bare message. Furthermore the "Call Stack" window in Visual Studio is always empty --> I have no easy way to find out where the failure occurs in foreign source code, because virtually no documentation of the program flow exists.
Full source code is available, and I have re-built the application with "Debug" configuration.
Right now the only option I can think of is to scatter breakpoints and Debug.Writelines all over the source code to get an idea where the problem occurs.
Is this really my only option, or did I miss some setting somewhere, so I can retrieve more info, so I can somehow go straight to the code where the failure occurs?
Thx!
I have a series of Google Unit Tests that are launched via a bat file. Some of these tests are broken and a window appears when they run:
Microsoft Visual C++ Debug Library
Debug Error!
... Info about error
This window waits for a user to press Abort, Retry, Ignore. Of course, this halts my test. Currently, I delete the broken tests before I run the batch. I want a way to force this window to abort or ignore - so I don't need to skip the broken tests.
This problem is similar to; however, I cannot write to reg keys
How do I disable the 'Debug / Close Application' dialog on Windows Vista?
Update: My manager says this window might not appear if this project was in release. Trying to do that now. However, if there is a solution besides changing my project to release, I would appreciate it! :D
That's what you get from a failed assert() in the source code. Useful to debug the test. But actually running unit tests against code that was compiled in the Debug configuration is not useful. Your customer isn't going to run the Debug build either.
Only test the Release build, that disables those assert() calls as well.
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.
VS 2005
For example,
My employees gave me a project with about X try-catch statements.
X > 100 .. 300
I need to test a project. Is there a way to mark each (every) beginning of catch as a breakpoint ? I don't want to do it manually. Maybe there is some settings that fit to me ?
Go to Debug > Exceptions (Visual Studio 2013 and earlier) or Debug > Windows > Exception Settings (Visual Studio 2015 and later).
In this dialog you can enable first chance debugging of exceptions - when an exception is thrown, the debugger will automatically break at the throwing code before the "catch" code is executed, allowing you to debug it.
What you want to do is ask it to break when CLR exceptions are thrown, not only when they're unhandled (image from Visual Studio 2013 - 2015 is similar but now is in a view rather than a dialog):
(Note: This won't get the debugger to break whenever you execute a try block, only if the exception is actually thrown)
Short answer is no. But you might be able to make some an aspect-oriented plugin to your project that captures the catch crosspoint, then you just have to put one breakpoint at in your aspect
I am not aware of a possibility that allows setting breakpoints in code by some pattern. The closest you can come to is Debug/New breakpoint/Break at Function where you can specify the file and line number. If you can get this automated and working down a list generated by a grep search, you might find a way. Here is something from the IDE samples that might get you started:
' Sets a pending breakpoint at the function named "main". It marks the
' breakpoint as one set by automation.
Sub AddBreakpointToMain()
Dim bp As EnvDTE.Breakpoint
Dim bps As EnvDTE.Breakpoints
bps = DTE.Debugger.Breakpoints.Add("main")
For Each bp In bps
bp.Tag = "SetByMacro"
Next
End Sub
However, why do you want to set those breakpoints anyway? If it's in order to catch exceptions as they are thrown, you can make the debugger break automatically whenever the happens under Tools/Exceptions.
You can use this if you are using older IDE's (anything pre-2012)
Programmatically apply / deactivate breakpoints in Visual Studio
Unfortunately they removed the macros from the newer IDE's.
There are extensions you can download and one of them allows you to modify a *.js file. Issue is going to be converting what the gentleman wrote in the other post to have it read properly.
For now I'm just using System.Diagnostics.Debugger.Launch(); it's just a pain and it would be awesome if someone could translate that file over.
since moving to Windows 7 (IIS 7.5), the debug assertions do not prompt a pop up dialog anymore.
I have tested this in a separate project, and noticed that they do work when using the integrated Visual Studio Developer server (Cassini) but they do not work when using IIS Web Server.
This is a big issue for us since we are counting on debug assertions to identify potential programming errors, so any help would be appreciated.
Thanks. Eyal.
That's because failed debug assertions are displayed in the Output window now instead, under the Debug section.
To view the Output window in Visual Studio 2008 go to the 'View' menu and click 'Output'.
I also find it inconvenient. Some more info...
You can work around by using
System.Diagnostics.Debugger.Launch();
You can make for example this function
[Conditional("DEBUG")]
public static void AssertEx(bool condition, string message)
{
if (condition) return;
System.Diagnostics.Debugger.Launch();
// Still write the message on output
Debug.Fail(message);
}
and get similar results.
That is the default behavior now and it cannot be changed.
What you can is generate a file with the assertions that failed in your app. That will still help you track your issues without halting the app when running inside the IIS.
Take a look at this good article about it.