I have seen that sometimes breakpoints cannot be enabled in Visual Studio, they appear as empty circles, with a warning sign when enabled. This icon change is all the information VS gives.
Particularly I'm suffering that in a Windows CE 6.0 project where I cannot enable any breakpoint in any of the sub-projects or in the OS design. The target platform in this project is a Vortex x86 embedded board, I use KITL for remote debugging.
How can I retrieve more information about what is happening?
Is it not possible to use breakpoints in my case?
The hollow circles with the yellow warning sign are OK. The breakpoint should instantiate once the module that holds that breakpoint loads.This of course happens in a debug image only.
Are you running/compiling a debuggable version of your projects - I seem to remeber if there were no symbols loaded then this was the casE?
Related
I have a Xamarin Forms 5 application that is having issues being debugged via Visual Studio.
The application has a root view with tabs and each has a ListView control. The application runs fine without any issues when started without debugging.
When debugging it seems that the ListViews are continually re-creating the cells, the descendants count just keeps going up indefinitely. To the point where the UI is unusable in any meaningful way due to the connection being swamped and the CPU continually hit.
It behaves this way when running either Android or iOS, hardware or simulator.
I've just loaded the exact same projects and solutions into JetBrains Rider 2021.3 and debugging using Rider works flawlessly, using both simulators and hardware.
The only common denominator is the Visual Studio debugger.
At this point I'm not entirely sure how to address the issue with debugging via Visual Studio. Are there any configuration options that would be worth experimenting with to try and solve this?
Please include your visual studio and xamarin forms version.
Possible issue : On vs you can change hot reload option in tool -> Option -> Hot reload. In the xamarin forms section, try to change the option from "Only change XF 5.0" to "Full Page".
note : the english name of those option might not be exact (my vs is in another language).
I want to debug a C++ MFC/CLI program developped on Visual Studio 2019.
Until now, I can debug C++ native (MFC) code.
DebugType in Debug panel is set to Auto.
All breakpoints in C++/CLI modules are flagged as inactive (a red circle with an interrogation character in a yellow triangle).
After having changed DebugType from Auto to 'Mixed (.Net Framework), Visual Studio, when starting a debug session, is displaying following warning box.
But my build is in DEBUG mode !
What is happening ?
What must I do to debug pure C++ AND CLI C++ code ?
PS: I have also tried to debug in only C++/CLI code, but Visual Studio 2019 is displaying same message !
On Visual Studio 2019, how to debug pure C++ and CLI C++ in a C++
Debug program?
Since I do not have your project and cannot troubleshoot the issue quickly unless you provide a sample.
You can try the following suggestions:
Suggestions
1) try to reset all settings by Tools-->Import and Export Settings-->Reset All Settings
2) disable any third party extensions under Extensions-->Manage Extensions in case one of them causes the behavior.
3) check Use Managed Compatibility Mode option, Enable .NET Framework source stepping option and Suppress JIT optimization on module load (Managed only) option under Tools-->Options-->Debugging-->General.
4) close VS, delete .vs hidden folder, Debug folder from the solution folder and also Debug folder in the project folder. Then restart your project to test again.
I'm putting this here because it might help someone in the future, and because it's completely nuts.
I've followed all instructions I could find, including the ones on this question, reinstalled VS twice, with different versions, and nothing.
What solved for me was to simply delete the lines of code and write them again.
Yes.
I know.
I've a solution which is ported from VS (Visual Studio) 2010 to VS2017 from one machine to another. I could debug while I can't. I need to know what's the problem. When running, I see the breakpoint marks get changed to include a warning, but I can't find what can be wrong. It seems that everything is ok.
1) Try to rebuild the application. Make sure that it's in the "Debug" mode.
2) If it works fine in VS2010 but failed in VS2017, I wonder if Visual Studio gets confused the configuration of the correct code type, if so you may need manually selected the .NET version. If you are using Framework 3.5 in VS2010, but on Visual Studio 2017 you are using such as Framework 4.6, by default automatically determines the code types to debug (v4.6, v4.5, v4.0). In this case you need to click in "Select..." button on "Attach to process" window and select Managed (v3.5, v3.0, v2.0).
3) Try to clear/delete all breakpoints from the Debug menu, choose Delete All Breakpoints. The reason is that it refreshes your Visual Studio setting file of your project.
4) Potential Workaround: Uncheck "Require source files to match original versions ..." in Options, Debugging.
In my case, changing from "Release" Mode to the "Debug" mode works!
When you launch the process, if the breakpoint icon turns hollow with the warning symbol, then the debugger cannot figure out what part of the program corresponds to that line of the source code. This is typically because the build is out-of-date with the executable, DLL, or PDB file.
A common way to get into the this situation is to not notice that the build failed and then let the debugger try to run the old executable which doesn't correspond to the current sources. It can also happen if Visual Studio gets confused about some of the dependencies and doesn't rebuild everything that needs to be rebuilt (which can happen after significant changes to the solution and/or project file(s), e.g., after an upgrade).
In these cases, clean out the build directory and force Visual Studio to rebuild everything. This will usually get you back in sync.
When you set a breakpoint in DLL code, that breakpoint will appear in the hollow warning state until the DLL is loaded. If your program uses delay-loading or if it manually loads the DLL (e.g., via a LoadLibrary call), you will commonly see this. Once the DLL is loaded, any breakpoint icons in the DLL should return to the normal red-ball state. If it doesn't yet you think the DLL should have been loaded. Check the Output window in the debugger to see if it really was loaded and whether there were any warnings or errors about loading the corresponding symbols from that DLL.
I have the following problem with design-time debugging in Visual Studio 2010 Pro.
In my solution I have got two libraries. One with name Alfa that contains some of my basic components. Two with name AlfaDesign that it contains designers for components from library Alfa. And of course I have a project for developing and testing Alfa components.
AlfaDesign is having reference to Alfa library. And the test project is having a reference to Alfa and AlfaDesign.
And my problem:
When I put breakpoint in component's constructor from the Alfa library and then I put this component on the form in my testing project, the debbuger is doesn't break. Visual Studio is still running.
I followed instruction from the tutorial Walkthrough: Debugging Custom Windows Forms Controls at Design Time, but without any success.
I ran into this problem today with one of my projects, and I spent the last several hours figuring it out. What I found is that the symbols and modules will not load when your project target framework is set to anything less than .NET 4 when doing an F5 debug. Switching the projects to .NET 4 does fix this weird behavior, but you may not want this for .NET 2 applications that you don't want to use the newer runtimes/BCL.
However, you can still correct this behavior. You can run manually use Debug -> Attach To Process and select devenv.exe and that will load the modules and symbols. So, you can either have a second instance of Visual Studio 2010 already open and simply attach, or you can run it on debug (Run External Program), Detach, and Re-attach to get the modules to load.
I thought this was something wrong with my environment settings, because my install of Visual Studio is very customized, so I thought there might have been some sort of setting, conflict, or file difference, but it seems to just be a weird behavior in the Visual Studio 2010 debugger. I would be curious to see if anyone from the Visual Studio 2010 team could investigate this a bit further.
If the breakpoints are properly resolved, then it must hit properly.
Please check the following.
Is the breakpoint resolved properly or not. If it's properly resolved, it will be displayed in red during debugging sessions. Otherwise the red will turn into a disabled state (with a yellow exclamation mark with a grayed circle).
Why don't you put a breakpoint where the object is being constructed and debug through it? So that you can ensure that your construction code is working well. You can step through (F11) to get inside the constructor.
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.