I am new to Visual Studio, so I am used to IntelliJ and Eclipse style of functioning. I usually do not use a debugger when I develop, so I do not want to use it in Visual Studio too.
Is it possible to disable all special debugging functionalities which Visual Studio provides when you start your application? I want to have only normal output for the errors. When I disable all debugging, then I do not have usual output too, so this is not an option.
I tried many settings, but nothing seems to work and give me the results I want - no extra popup windows, no shiny layout changes when you have an error, just ordinary output.
Thanks!
Everyone's definition of "normal output" is different. Personally, I like the way Visual Studio handles debugging.
The console window in Visual Studio is a debugger feature and hence that is why it doesn't work when it's not attached to the process. If you want a stack trace without attaching, you could use your language/framework's built-in facilities such as an Exception or StackTrace in the case of .NET. You could also have Windows write a crash dump, but then you are debugging the corpse inside of Visual Studio.
Related
While doing pair-programming on an React project with Visual Studio Professional 2017, my partner was working on my machine and disabled some debugger option to see less warnings. I want to undo what he did, but he is not available any more, so that's why I am asking here. I remember faintly that he said something about disabling "some breaking".
I am sure it must be somewhere in the options window which appears after Debug > Options and on that popup somewhere under the entry Debugging. I attached a screenshot of Debugging > General. I already tried the toggling the 3rd check-box, but that did not do the trick.
The interesting thing is that in the sub-window Output I used to see all those exceptions logged, but I do not see them anymore.
References
How to turn off warnings while debugging in VS Code?
Enable a single warning in Visual Studio
How to re-enable breaking on unhandled exception in Visual Studio 2012 Express for Web?
When Roslyn installed, it comes with a couple of great demo tools. Firstly, the most valuable I think for those who want to learn syntax trees more thoroughly is the Syntax Visualizer Tool Window which shows the syntax tree of active *.cs files.
Everything worked fine when I launched this extension and tried it in a test instance of Visual Studio. But when I have installed this extension, it's not working anymore. I still have View -> Other Windows -> Roslyn Syntax Visualizer but just an empty window tool pops up.
Does anyone have the same problem and know the solution?
I guess that maybe I need to copy DLL files which this extension produces when rebuild but I don't know where should I put it.
Later I found another interesting detail - when I launch my own extension, Syntax Visualizer Tool works! So, it works only in test instance of Visual Studio. Why it should be like that?
The Syntax Visualizer only works when you are running Visual Studio with Roslyn enabled. When you start a test instance of Visual Studio, Roslyn is automatically enabled. Manually starting Visual Studio with Roslyn can be done by adding /rootsuffix Roslyn to the shortcut, but take care that Roslyn is not finished yet. It might not be advisable to enable it by default, depending on what you are working on. Of course, you can also just create another shortcut with Roslyn, so you can choose which one you want.
If you see [Roslyn] in your code tabs in Visual Studio, then you can use the visualizer. Another way of verifying if Roslyn is enabled is to view your extensions. The Roslyn Language Services has to be there for it to work. If this is not the case, then the visualizer can be opened, but it won't show any contents.
You can find more information about the visualizer extension here.
Nico most likely has the answer. Look in the Debug properties of the Syntax Visualizer project to see that it is launching with /rootsuffix Roslyn. Also, without launching this way, you should be able to see the Syntax Visualizer in the C# REPL and C# Script editor windows; as these are Roslyn CSharp editors.
I am using Visual Studio 2008. I don't need to debug some DLLs in my project, so can I disable symbol loading when debugging a Visual C++ program? Does it help to make startup time faster when debugging?
The symbols are all local, so I don't have those slow loading problem, just want to make debugging faster and faster.
For example I am using Qt libraries, when I hit "Starting Debugging", the Output window shows that the symbols for Qt libraries are loaded. If VS can stop loading those symbols, the debugging startup time should be faster. Of course, I still want VS to load symbol for my executable.
Just found out that Visual Studio 2010 actually do what I want.
To load only the symbol for your executable file, without loading other symbols (eg: DLLs):
Go to Tools->Options->Debugging->Symbols
Click "Only specified modules"
Clear "Always load symbols located next to modules"
Click "Specify modules"
Click the new icon
Enter your executable filename (eg: my-awesome-app.exe)
Also found out that Visual Studio 2010 seems to perform better than Visual Studio 2008 when debugging. At least the IDE layout switches back faster when the debugging is stopped.
I am not sure what you mean by 'startup'. I assume you are talking about the launching of the actual application. The time to launch the target application is expensive regardless of mode you launch it. It may be less in Release but that will be negligible.
Turning off all symbol paths as mentioned in the other solution is a viable option. However, I am not sure why you are debugging if you do not want symbols for your launched application. Without the applications symbols you will not be able to see where you are in the source code when you are debugging.
If you are looking for a faster debugging experience you can use WinDbg. It comes with the Windows SDK but can also be downloaded seperately. If is a faster UI than Visual Studio, but it is much more cumbersome to use if you are more comfortable with a GUI. WinDbg uses commands to perform almost all tasks, but you can do some great debugging and it is faster in many cases compared to Visual Studio. In the event you want to debug C++\CLI or any managed application (e.g. C#), I would stick with Visual Studio. There is an extension in WinDbg called SOS, but it requires some advanced debugging experience to use correctly.
Is it possible to use windbg commands like !locks and .loadby sos mscorwks from the Visual Studio command window (in a debug session)? I've noticed I can use eg k to print a stack trace, so I was wondering if there is some way to get access to the other commands.
Yes you can do this.
Attach Visual studio 2008 to your process for debugging.
Break at some code.
Go to immediate window
type !load sos
Now you are free to use any of the windbg commands like !EEHeap,!DumpHeap
There are some conditions. You need to enable unmanaged code debugging in your project properties. Normally in 64 bit version studio doesn't support this.
Have fun.
Visual Studio 2012 has the "Windows User Mode Debugger" transport in the "Attach to Process" dialog. This allows you to use windbg commands in the immediate window.
Source: Use the WinDbg Engine in Visual Studio User-Mode Debugging
Starting with Windows Driver Development Kit (WDK) 8.0 the Windows debugger is integrated into Visual Studio (see Debugging Environments). Installing the WDK on top of a Visual Studio installation will enable a developer to pick a number of debuggers from the Attach to Process dialog, or set the debugging engine in a project's Debugger settings. This has been verified for Visual Studio 2012 and 2013. The way I read the MSDN link above, this should also work for any other IDE that is supported by the WDK 8.0 and above.
While WinDbg offers a lot of powerful commands, there are some drawbacks as well. This list is not exhaustive, and merely contains those issues I did encounter:
Cannot attach to more than one process at a time. While not generally an issue, this is quite unfortunate, if you do need to debug more than one process at a time. The Visual Studio debugger can attach to any number of processes simultaneously.
WinDbg will not use the symbol settings from your Visual Studio IDE (tested on VS 2012 Update 4). While you can configure the IDE where to look for debugging symbols, WinDbg will not honor those settings. WinDbg will use the _NT_SYMBOL_PATH environment variable, and/or the configuration set through .sympath.
Different syntax for function breakpoints. This is a minor annoyance, since you cannot use Visual Studio's syntax to specify function breakpoints. This also means, that function breakpoints are ignored that have been set using the Visual Studio syntax. What's more annoying, though, you do get a warning dialog for each when launching a debuggee.
No support for Tracepoints. I've been using tracepoints extensively, to unintrusively insert tracing into a debuggee. If you are using tracepoints as well, this may prove to be more than just an annoyance.
If an application†crashes,
I hit "Debug" and Visual Studio is my currently registered Just-In-Time (JIT) debugger:
Visual Studio appears, but there's no way to debug anything:
I do not see any disassembly
I do not see any registers (assuming it runs on a CPU with registers)
The call stack is empty (assuming the CPU has a stack pointer)
I do not see any symbols (assuming it had any)
I do not see reconstructed source code from reflection (assuming it was managed)
Other JIT debugger products are able to show disassembly, but they are either command-line based (Debugging Tools for Windows), or do not support symbols (OllyDbg, Delphi). Additionally, my question is about debugging using Visual Studio, since I already have it installed, and it is already my registered JIT.
How do you debug a program using Visual Studio?
Alternatively: has anyone written a graphical debugger that supports the Microsoft symbol server?
†Not, necessarily, written in Visual Studio.
Edit: Changes title to process rather than application, since the latter somehow implies "my application."
Edit: Assume the original application was written in assembly language by Steve Gibson. That is, there is no source code or debug information. Visual Studio should still be able to show me an assembly dump.
Looking at the screenshot it appears that Visual Studio is currently debugging in Run mode - you need to break execution of the process before it makes sense to look at things like the call stack, etc...
To break execution of the process you either need to hit a breakpoint, or you can break execution of the process at any time by using the Pause / Break all toolbar item (Control + Alt + Break).
Then you should be able to access the following windows under the Debug -> Windows menu:
The disassembly window
The registers window
The call stack window
The modules window shows a list of loaded modules along with where their corresponding symbols are loaded from (if loaded)
Some other useful windows:
The processes window is useful if you are debugging more than one process at a time
The Threads window
The Memory window (there are four of them)
The Locals window
Some of these might not be visible by default depending on which window configuration you selected when you first started Visual Studio - if you can't find them then right click on the toolbar and goto customise to add them.
Visual studio doesn't reconstruct soucre code from disassembly - you really need to have the original source code available to you, otherwise the symbols almost certainly won't match the source code you are debugging.
If you are debugging unmanaged modules without source code then I recommend you at least try WinDbg - its user interface is a bit clunky at times, and it does have a steep learning curve, however it is a very powerful debugger supporting many features that Visual Studio doesn't - it may be more suited to the sort of debugging you need to do.
(Visual Studio is a fantastic debugger, however it's primarily used to debug modules where the source code is available and so it lacks certain features in favour of a better user experience).
Assuming this is your application that you wrote in VS, just press F5 to run the program and either use a breakpoint, or manually break the program to start debugging.
The problem in the last screenshot is that Visual Studio did not enter break mode automatically. That seems like a bug. If you hit the 'pause' button on the toolbar, it would enter break mode, giving you disassembly, and a callstack.
According to that last screenshot you were actually attached to the program ... the output windows shows it loaded stripped symbols for OLE and the crt.
You can debug a program with Visual Studio if you have the debug information available for this program. It's the difference between compiling a Release version (normally without debug information) and compiling a Debug version.
This dialog to debug a program is handy if you are testing the debug version of your self-written program. You can attach it "on-the-fly" to your Visual Studio debugger and look for the problem.
If it is not your program or it is your program, but does not provide debugging information which Visual Studio can understand, then you are out of luck.
Use menu Debug -> Windows -> Disassembly (I think the keyboard shortcut is Alt + 8, but I am configured for VC 6.0 bindings, because that's how I roll, and it may have changed).
You can get public symbols for the operating system from http://msdl.microsoft.com/download/symbols. Add it to the list in menu Tools -> Options -> Debugging -> Symbols -> Symbol file locations.
Also, make sure you are running in the same integrity level as the application. Or always run Visual Studio as Administrator.
I guess you are already in the Debug mode. The "Run" button is disabled. Just go to Debug -> windows -> Disassembly to view disassembly.