Microsoft Visual Studio Debugger
Vilma Steiert
The Visual Studio debugger can help you navigate through code to inspect the state of an app and show its execution flow, which is also known as code stepping. You can use keyboard shortcuts, debug commands, breakpoints, and other features to quickly get to the code you want to examine. By getting more familiar with debugger navigation commands and shortcuts, you can find and resolve app problems faster and more easily. For a list of the most common keyboard shortcuts related to code navigation and debugging, see the Debug section in Keyboard shortcuts.
Some navigation commands start your app and automatically attach the debugger. Your app pauses on a specific line of code based on the command you used to start navigation, and you enter break mode (that is, your app is paused in the debugger).
In break mode, app execution is suspended while functions, variables, and objects remain in memory. When the debugger is in break mode, you can navigate through your code. There are two very common ways to quickly enter break mode:
For example, in the code editor in Visual Studio, you can use the Run To Cursor command to start the app, with the debugger attached, and enter break mode. Then you can use step commands to navigate the code.
When you're in break mode, you can use various commands to navigate through your code. You can examine the values of variables to look for violations or bugs. For some project types, you can also make adjustments to the app when you're in break mode.
Most debugger windows, like the Modules and Watch windows, are available only when the debugger is attached to your app. Some debugger features, like viewing variable values in the Locals window or evaluating expressions in the Watch window, are available only when the debugger is paused (that is, in break mode).
If you break into code that doesn't have source or symbol (.pdb) files loaded, the debugger displays a Source Files Not Found or Symbols Not Found page that can help you find and load the files. See Specify symbol (.pdb) and source files. If you can't load the symbol or source files, you can still debug the assembly instructions in the Disassembly window.
Code stepping refers to executing your application code one statement at a time, with the debugger attached. The debugger step commands help you observe the effects of each statement and find out more about its execution flow.
As you run each line of code, you can hover over variables to see their values, or use the Locals and Watch windows to watch the values change. You can also visually trace the call stack while you step into functions. (For Visual Studio Enterprise only, see Map methods on the call stack while debugging.)
You might not care about a function when you're debugging. Or you might know some code works, like well-tested library code. You can use the following commands to skip code when you're code stepping. The functions still run, but the debugger skips over them.
To set a simple breakpoint in your code, select the far-left margin next to the line of code where you want to suspend execution. You can also select the line and then select F9, select Debug > Toggle Breakpoint, or right-click and select Breakpoint > Insert Breakpoint. The breakpoint appears as a red dot in the left margin next to the line of code. The debugger suspends execution just before the line runs.
To run to the cursor location, in source code or the Call Stack window, select the line you want to break at, and then right-click and select Force Run To Cursor. Selecting Force Run To Cursor will skip any breakpoints and first-chance exceptions until the debugger reaches the line of code where the cursor is located.
While the debugger is paused, you can hover over a statement in source code or the Disassembly window and select the Run execution to here green arrow. Using Run to Click is similar to setting a temporary breakpoint.
While the debugger is paused, you can hover over a statement in source code while pressing the Shift key and then select Force run execution to here (the double green arrow). When you choose this option, the application attaches the Visual Studio debugger and pauses at the cursor location. Any breakpoints and first-chance exceptions found during execution are temporarily disabled.
By default, the debugger tries to debug only your app code by enabling a setting called Just My Code. For details about how this feature works for various project types and languages, and how you can customize it, see Just My Code.
Starting in Visual Studio 2022 version 17.7, you can autodecompile .NET code when stepping into external code without the need to manually load debugging symbols. For more information, see Generate source code from .NET assemblies while debugging.
In the Modules window, you can tell which modules have symbols loaded in the Symbol Status column. Right-click the module that you want to load symbols for and then select Load Symbols.
The debugger steps over properties and operators in managed code by default. In most cases, this behavior provides a better debugging experience. To disable stepping into properties or operators, select Debug > Options. On the Debugging > General page, clear the Step over properties and operators (Managed only) checkbox.
I have first to apologize for my poor level in english, I will try to do my best to be understood. Few day ago, I installed the Intel Fortran Compiler (ifort) on Windows 10, by installing the intel oneAPI Base Toolkit and the oneAPI HPC toolkit. The aim was to compare the compilation between gfortran from GNU on linux and ifort on a windows computer.
When I installed the toolkits from intel on windows 10, I wanted to be sure that the additionnal compilers where included in Visual studio 2019. In fact, it was the case, because I have now the possibility to create fortran projects, and I secceeded to debug and execute a simple fortran code on 1 file (.f).
My lack of knowleadges on how to use Visual Code will now appears. In fact, I don't know how to set up tasks to debug and compile my fortran files. So, by using only the command lines all works, here are the command I used :
Now, on Visual Sudio 2019, I don't know first if a have to create a fortran project, then I copy my fortran files into it. Also how do we create I simple task and a makefile to debug and run those files.
When you are using Visual Studio, you must create a project, which then resides in a "solution". Normally, when you create a new project, the solution is created automatically. A solution can hold more than one project and is something that builds an end result (executable, for example).
Since you have existing files, select Empty Project and click Next. The next screen will ask you to name the project and say where you want the new project/solution folder created. Click Create. On the new screen that appears, you'll see something like this on the right, reflecting your new project.
Now click Project > Add Existing Item... and select all your source files. Alternatively, you can use Project > Add Existing Items from Folder, or you can just "drag and drop" files onto "Source Files".
I added my subroutines to the Source file tab, and have the program file in the main VS screen. When I build the solution there are no errors found but an exe file is apparently not produced since starting the debug process I get a message that says '*.exe file not found'.
I am curious what it is you are trying to compare - runtimes? Numerical answers? In both cases I expect differences don't you? You know you will probably get different answers, yes? You are not expecting the same answer out to 12 digits are you?
I just want to make sure you're not wasting your time. 2 different OSes, 2 different compilers == different numerical results. Not to mention runtimes. Since you are a Physicist, it's like saying " I want to throw a baseball on earth and on Mars and to compare the two." If you expect differences, great. If you expect roughly the same behavior then you're starting with a false assumption.
I understand your question, I went too fast to explain what I'm trying to compare and why. Actually, I use 2 different OS just because gcc compilers and so gfortran, is simpler to be installed and used on Linux. And, by reading some forums, I noticed that intel toolkits where also incorporated very well to VS 2019 IDE. So ifort was used on windows.
The issue was that I taked this code wrote by my supervisor that makes big calculation in nuclear physics (the program find quadrupole momentum and binding energy of nucleus in isotopic chains). I should specify that the files were always compiled by my supervisor by using ifort from intel and on linux (ubuntu).
When I tested thoses files, I used gfortran (on linux) because I never heard about ifort or intel compilers before now. So I was surprised to see that the code was not compiled will gfortran, it signals to many errors and warnings. As you said it, I think it is due to the fact that the 2 compilers have 2 differents behaviors ; my assumption was not Ok, I thought that for a language (here fortran 95) 2 different compiler will just be different in the numerical answers or runtimes But if the compilation and the execution is a success with one compiler than it will be the same on the other ( as I said in my previous message, I didn't have lectures on theorical computing..but if you know some books to understand how it really functions, I would be interested ).
d3342ee215