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.
Related
We want our continuous integration scripts to run our apps on the test environments with MSVC attached to the apps.
I've tried several options like this or this that launch vsjitdebugger.exe but it pops several pop-ups like "Do you really want to start debgging? Yes. Cancel debugging" and "Choose the debugger"( with only one choice in the list). That is unacceptable because ... it is supposed to be automated - to work without humans.
Anyone done that and knows how to truly automate it?
It will have the JIT debugging pop windows during using command line or IDE if we enable JIT debugging to capture the Exception, I often use the following sample as the debugging tool even if it doesn't really meet your requirement:
https://www.codeproject.com/articles/1090417/how-to-set-debugger-to-auto-attach-on-process-star
We could disable JIT without pop window, but it means that it will not really call it:
https://msdn.microsoft.com/en-us/library/5hs4b7a6(v=vs.140).aspx
No other good workaround for it, but I will help you submit a feature request to the product team:
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/17280578-launching-msvc-debugger-to-debug-an-app-from-comma
You could add your comment and vote it:)
i coded a big project that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs. I searched a long time to find the heap error, but didnt find anything. The problem is i need the running .exe of the programm, so i wanted to ask if there is a possibility to link the windows debugger to the .exe so it always starts with it.
If it doesn't crash right away, maybe this helps:
You can run the executable.
Open your solution in visual studio. Make sure it's the same build.
Open the DEBUG menu and click attach to process.
A window will open, listing all processes that are running. Select the executable that's crashing
Click the DEBUG menu again and select Exceptions (ctrl-alt-E)
Make sure the checkbox "Thrown" is checked for Common Language Runtime Exceptions
Now crash your application.. It will halt at the line that causes it.
Also look for environment directives. like #IF DEBUG #END IF. or #IF RELEASE That kind of stuff. Tricked me a couple of times too..
Good luck. Hope this helps!
You can do various things. First make sure you have a "big out try block" in main. i.e. put the main logic in a try can catch exceptions and report these clearly. This probably isn't what's happening in your case.
You can attach a debugger - including Visual Studio, to a running process - see the "Attach to process" option under the debug menu. If it's built with debug symbols, which you can do, even for release code this may help. If it's optimised you may find it difficult though.
Finally, you could generate a crash dump and inspect that after it's failed. See docs on MiniDumpWriteDump. There are several examples on its usage. Or you can install an abort handler: See here. This mentions _set_abort_behavior which if invoked with _CALL_REPORTFAULT will generate a crash dump too.
I need to debug a process (starting from an external exe) that terminates immediately after start, so I don't have time to attach. How can I debug it?
UPD I don't have source code of that external exe; I can decompile it, but it's impossible to compile it back
You need to launch your process for debug in a suspended state. Visual Studio is capable of that, just invoke the debugger like this:
devenv /debugexe yourprog.exe <arguments>
The process will start suspended so you'll be able to iterate through first instructions before the crash.
See the detailed answer here.
You just need to open Visual Studio, go to File -> Open -> Project / Solution
and select the exe.
Press F5 and you will see the exception in the Output window. If you go to the Debug -> Exceptions window and select everything you will see the first chance exception before it shutdowns the application.
Note that you don't need the source code at all to do this.
Hope it helps.
You need to start it with the debugger. This will start the program with the debugger already attached.
If you cannot do that with Visual Studio, you can use the Windows Debugging Tools, part of the Windows Driver Kit. Note that the linked kit is for Windows 8.1, you may need to find older versions if you're not on Windows 8.
You can enable debug mode runtime by placing some piece of code.
write a method as below:
[Conditional("DEBUG_SERVICE")]
private static void DebugMode()
{
Debugger.Break();
}
and call this method where you want to start debugging, for example in the OnStart event.
you have to build your code with debug mode. dont forget to remove this piece of code after debugging and want to release.
So there I am, working on a Silverlight app, and between one build & run and the next, my debug output goes away. Where before I had dozens of lines of Debug.Writeline text, I now have only the module load and thread messages.
Yes, I'm in debug mode (vs. release mode).
Yes, my Output window says "Show output from: Debug".
Yes, when I right-click on the output window, every option is checked.
No, my Tools > options > debugging > general > "Redirect all output text to the immediate window" is not checked.
All I can figure (and it's a wild guess) is that for some reason, the VS debugger isn't attaching to the Silverlight app like it should.
What's weird is this has been happening for the last couple of days, out of the blue. And just as suddenly, all my debug messages start showing up again.
This is VERY frustrating.
EDIT: Of course, after returning to the project after the weekend, all Debug messages are back. No idea what was causing the issue, so I'm sure it will happen again.
Now the question is: should I leave this question open in case the problem arises again in the near future? What happens to an unawarded bounty?
I found the same problem and just by setting options → debugging → output window → Thread Exit Messages to true the output windows was begin to send the right messages !?
I had exactly the same issue. Out of the blue, debug.print stopped working. In my case, it used to go to the Immediate Window. Nothing there. Nothing in the Output window. I followed several suggestions to no avail until I found this one at http://www.experts-exchange.com/questions/26894732/Debug-Print-and-Debug-Write-no-longer-work-in-Visual-Studio-2010.html
There is a context menu in the Output/Debug pane. The "Program Output"
menu item was accidentally cleared.
Checked the item and it started working again (even though my output was the immediate window). What a relief...
Ensure that the DEBUG conditional compilation symbol is defined. The Debug class suggests that you "add the /d:DEBUG option to the compiler command line when you compile your code using a command line, or add #define DEBUG to the top of your file".
Did you create or modify an Application config? If yes: the initial created configuration by VS does contains the necessary wiring configurations to enable the debugging at all. Not sure what and if there are counterparts in Silverlight, but in WPF environments simply replacing the app.config will have the same effect as you expierience.
Check the Immediate Window. Check the options. There is a general setting that says "send Debug output to Immediate Window"
I am testing an F# project using NUnit. On the debug tab of project configuration I have set the debugger to use an external program which is nunit-console here and the working directory to the debug folder of my project. I prefer using nunit-console with the debugger since the GUI version doesn't hit the test file's breakpoints.
When I debug the test the console window appears and disappears and there is no chance to read the output. I have tried Console.Readline(), but it doesn't work because when I directly run the test from a terminal using nunit-console, it fails due to this command.
Is there a way to redirect the nunit-console output to the Visuals Studio's output window?
UPDATE: I could use Thread.Sleep() to delay the nunit-console.exe when I run the test from the console. But from Visual Studio it doesn't happen so I am pretty sure that nunit-console.exe fails to read the test file when the command is issued by Visual Studio. Still, it would be very nice to be able to read the console output, thus the redirection is still desirable.
Either use Tools->Options...->Debugging->General:"Redirect all Output Window text to Immediate Window" and then make sure that the "Immediate Window" is visible with Debug->Windows->Immediate.
Or use NUnit's "/wait" command line option.
Unless I am missing something, you should be able to hit all your breakpoints with the GUI as well, set the startup project to nunit.exe and pass the name of your test DLL as a command line parameter. You will hit the breakpoints in Visual Studio, and your print statments will be in the GUI's output tab.