I have recently bought new laptop:Hp specter x360 i7-6500 with 8gb RAM.
I have installed Visual Studios 2015 Community in an offline mode, later I updated it.I am currently working in c# window forms.
The point is when I press the button 'Start Debugging', VS build the program in normal speed, but it takes like 10-15 sec to show the output, even for the small programs. This whole thing is for first time debugging after code editing, if I close it and run it again without changing the code, it shows the output on the spot.
And if I run the same program in my old laptop, which has lower specs and same VS, that laptop show the result much quicker.
Based on your screenshot, I see that VS tries to download PDB symbols for system assemblies, which are used by your application. Loading the debug symbols provides simplify debugging of an application but it also slows down the application loading.
You can change symbols loading settings, in the Tools-Options-Debugging-Symbols menu of Visual Studio. Here you can disable symbol loading (if you would use this option you need to load symbols manually using the Debugging-Windows-Modules interface). Or exclude system modules which usually are not necessary to debug a common application.
Check this blog post which provides a great description about how VS uses debug symbols.
Related
Im struggling with extremely slow Visual Studio. I use it to build C++ projects mostly.
Everything could be super slow. Menu's loading, intelIsense tips, builds. I've just tested building simple solution in 1 file, and build took around 5 minutes. But! I found this article about Windows Performance Analyzer which I used to trace this solution build. Despite overall time taking around 5 minutes, WPA report build took only around 0.686 seconds, attaching screenshot:
apparently I press "rebuild" in VS and build itself started ~300 seconds later(timeline).
Currently I use VS2019. Same problem I observed on VS2017. I did removed all VS components and installed VS2019 and problem is not gone. All other programs run fine. No excessive CPU load(intell 6700k), no noticeable harddrive usage(windows and VS components are on m2 ssd, lightning fast), 32 gb ram and enough free space on system disk.
Only VS extension I installed myself is QT extension for VS2019. Which actions can I take next to find the problem?
Things to try:
devenv /safemode from a command line starts the IDE in safe-mode with all plugins disabled.
Visual Studio Installer and repair install
Disable graphics acceleration in Visual Studio (Tools|Options|General ... there are a few "rich client visual experience" related things)
Check paths on your computer. If other apps run fine but one does not, it could be that this app tries to access a network drive or website which is not available.
Run "procmon" and "procexp" (Process Monitor/Process Explorer from Sysinternals) and take a look at what's going on.
Try VS 2022.
I recently changed my work computer and I'm struggling developing with Visual Studio 2019.
This is a simple operation that highlights the problem. This happens when application is in debug mode with debugger attached.
As soon as I detach the debugger (Debug > Detach all in VS) the speed returns to normal. Speed is OK also with the installed version of the software. I tried using the Performance Profiler to see where the time is going but since the debugger is not attached in that configuration speed is fine there too.
I must add that only some operations, like the one pictured, are incredibly slow. In many cases the application runs as smooth as the installed version.
I've compared every option under Tools > Options > Debugging with my previous computer and one colleague and they match perfectly. The operating system is the same, Windows 10, and the installed version of VS is the same.
I tried cleaning the build, removing the .vs folder, repairing Visual Studio with no luck. I've always used a desktop PC (my last one was an I7 8xxx), the new one is a laptop with Ryzen 7. Other colleagues have a laptop with Intel processors and they show no issue.
Any help would be greatly appreciated.
As pointed out by Hans Passant in a comment, this was due to an excessive amount of lines written in the debug window. Lines of log written to an external file (via an Enterprise Library logger) were echoed in the debug window, so I think the whole process was waiting for that window to be constantly updated.
I'm using Visual Studio 2010 to debug a mixed application. When I attach to that process(Managed + Native), the VS is hung. Then 30 minutes later(not exactly this time, but it's really long), it comes back.
Anybody know how to resolve this?Thanks in advance!
I have 'Delete all breakpoint', tried repair VS and so on. The issue still exists.
I would guess you have a symbol server that is dead and VS is still trying to get symbols from it / VS is hitting the MS symbols server which is a slow operation / VS is not finding the symbols in the paths you have, but is still trying to hit them every time and that takes forever (both known issues that we fixed in VS 2012)
If you don't need any symbols - I would do what Hans suggested - Tool/Options/Debugging/Symbols uncheck all symbol servers, plus choose Automatically load symbols for: Only specified modules and specify your modules in that list (it can be empty as well) -> this will work if your app is trying to load a lot of symbols that you don't need. And you can later load them manually (the ones you want) from the Modules window
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.
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.