Simply I want to debug shaders, I tried Visual studio 2019 & 2022's graphic debuggers but they don't work and I tried the solution but it doesnt work either. DirectX12 is not supported by Visual Studio Graphic Debuggers
Thus I looked for an alternative and I found Pix, but I am struggling with the basics for instance, I can't use the watch menu to check the value of constants, it shows them as unavailable most of the time, I have to use constant menu to do so(but at-least this works).
The biggest Issue is this, When I step over/in lines, it does skip a single line or multiple lines and when I set a break point at any of these lines, it shows this message "No code exists at this location"
I cant tell whether these lines get processed or not from the debugger, and Most importantly I want to know the values they hold. Any Idea how to force pix to calculate every line?
Related
Very frequently, I will be looking for a specific section of code where something happens, and will reach there by starting at a function at a high level of abstraction and go lower by successively opening the code of called methods. Eventually I will find what I'm looking for, and I would like to save the path that I took to get there - which is pretty much what the call stack would be if I had put a breakpoint in that code and stopped here at runtime, except that I'm just inspecting the code.
I'm aware the little arrow next to the "Back" arrow lets me somewhat get that in the UI and I can then take a screenshot of what I'm shown, but that's not a fantastic solution. The names of the functions are trimmed (leading to cases where it could match several functions), the line number is seldom shown (only if there was no code at that line), and I would much rather have the text format to begin with so I can copy the function names into a search tool rather than type them from the screenshot later.
So I was wondering: is there a way to dump the navigation history in Visual Studio ?
Where I could for ex. ask for the last 50 cursor positions, and get the file, file path, line number & possibly the code at that line in text format or some more intelligent thing, should the IDE support that.
Thanks.
PS: I found this very similar question Is there extension for viewing navigation history in Visual studio? that's >5 years old and didn't have a satisfying answer, so I'm trying my luck again, hoping things have changed since if there was no solution back then.
When I'm working at someone else's code, sometimes it happens that I've found something useful that I likely will need to return later to.
Except the chances are that I forget where I've found that part and then I need to find it again. Nowadays I'm mostly using breakpoints to set these down, But I don't need these breakpoints for debugging, so I don't think that's the most efficient method. Something that could work for me is a sort of marker that functions marking down like a breakpoint, but does not affect debugging.
Will all these ways of breakpoints, search functions, finding references, and adding a Watches. I do have a feeling that such feature is present in Visual Studio already. But I havn't found it yet, I've already tried searching it up, but it looks like it hasn't asked before.
So, is there a feature in Visual Studio that let you mark down code like breakpoints, but just for the purpose of marking down?
There is more than one way to do so.
If I finde something interesting I mark it with a Bookmark.
Just STRG + K, STRK + K and it will be places on your current row.
With these Buttons you can switch to your bookmarks or delete them all. They are client based.
Visual Studio also gives you a "To Do List" Function. This one is triggered by comments in the code and seen for everyone with the right options used.
See here how it works in detail.
Yes, it's called a bookmark. This little toolbar is for bookmarks:
You can also use the Edit, Bookmarks... menu item and the View, Other Windows, Bookmark Window which among other things lets you see all of them and give them names.
One caveat: the bookmark binds to the line number, and doesn't move if you add or remove lines. So if you bookmark the first line of a function, then make changes above that, the bookmark won't be on the first line of a function any more.
Similar questions: One, Two. But this is not what I am looking for.
Similar questions, but said options are diabled: Three, Four, Five.
Situation: I want to identify the line where the value of the variable ApplianceState changes to the value normal. ApplianceState is an enum type and can have one of 4 different values. The project I am working on is quite huge and looking for it line-by-line could take days.
Question: Is there a way I can set a watch so that visual studio breaks at the line where the value of ApplianceState changes to normal?
I know I can set a conditional breakpoint, but that would mean I have to set a break point on certain line, and I don't want to do that.
Also, I have enabled native code debugging and the menu item New Data Breakpoint, in menu Debug -> New Breakpoint, is disabled (greyed out). So, I can't select it.
I'm in the process of migrating to VS2013 and am finding the operation of the Navigate To preview annoying and unusable at times.
We have a large number of files in the solution with names starting with 4 digits, i.e. 0001..., 0065..., 1735..., etc.
When using the preview tab to try to select one on these, it seems that it is either selecting much too quickly or interpreting something incorrectly as when I type the sequence Ctrl-,006 to look at files in the range 0060... to 0069..., VS2013 invariably opens the 0001... file and the '6' gets inserted as first character.
This seems to happen no matter how fast I try to type the filename, often in well under a second. It also only seems to happen with files having a numeric prefix; if I type Ctrl-,document, for example, I can pause, review the list and resume typing without a problem.
How do I adjust or reset the preview's autoselect time so I can get a chance to see the list and the preview and select the right file when typing digits as the start of the filename?
So far, the only workaround I've found is to turn off the Preview Tab in the Navigate To options, which is rather disappointing as, when it works, it's extremely useful.
FYI, the VS2013 version is "Microsoft Visual Studio Professional 2013 Version 12.0.30110.00 Update 1".
Is there a way in which I can debug my compiled Matlab components, using native Matlab debugger, like Visual Studio "Attach to process" option, or something like that?
I mean EXE stand-alone files, DLLs, COM in-process servers or .NET components.
You can't debug them in the sense of being able to step through the MATLAB code line by line, as you can with MATLAB's own debugger prior to compilation. One of the steps that the MATLAB deployment products take is to encrypt the MATLAB code (so you can preserve your IP when distributing the deployed component). The ability to step through the code in a debugger after deployment would defeat the purpose of that.
I experimented with using something like :
try
catch ME
waitbar(0,ME.message)
end
This was quite an effective and generic solution.
you may want to break down the code into multiple parts and debug each to save compiling time.
good luck,
dan
You can follow the instructions to debug:
Debugging:
Using the Debugging Tool will let you stop your program in mid-execution to examine the contents of variables and other things which can help you find mistakes in your program. M-file programs are stopped at "breakpoints". To create a breakpoint, simply press F12 and a red dot will appear next to the line where your cursor is. You can also click on the dash next to the line number on the left side of the M-file window to achieve the same result.
Then press F5 or Debug->Run from the menu to run the program. It will stop at the breakpoint with a green arrow next to it. You can then examine the contents of variables in the workspace, step, continue or stop your program using the Debug menu. To examine contents of a variable, simply type its name into the workspace, but be warned: you can only look at the values of variables in the file you stop in, so this means that you'll probably need multiple breakpoints to find the source of your problem. There are several different ways you can move through the program from a breakpoint. One way is to go through the whole program, line by line, entering every function that is called. This is effective if you don't know where the problem is. There's also a way to simply step through the function you're currently stopped in, one line at a time, and instead of going through the child functions line by line MATLAB will simply give you the results of those functions.
Finally, note that you cannot set a breakpoint until you save the M-file. If you change something, you must save before the breakpoint "notices" your changes. This situation is depicted in MATLAB by changing the dots from red to gray. Sometimes, you'll save but the dots will still be gray; this occurs when you have more than one breakpoint in multiple files. To get around this (which is really annoying), you have to keep going to "exit debug mode" until it turns gray. Once you're completely out of debug mode, your file will save and you'll be ready to start another round of debugging. Using comments to help you debug code. you want to test the effects of leaving out certain lines of code (to see, for example, if the program still returns Inf if you take them out), you can comment out the code. To do this, highlight it and then go to:
Text -> Comment
Or press CTRL+R. This will simply put a '%' in front of every line; if the line is already commented out it will put another '%' there so when you uncomment them the pattern of comment lines will not change. Commented lines will be ignored by the compiler, so the effect will be that the program is run without them.
To uncomment a line go to
Text -> Uncomment
Or press CTRL+T.
Another use of commenting is to test the difference between two different possible sets of code to do something (for example, you may want to test the effect of using ODE113 as opposed to ODE45 to solve a differential equation, so you'd have one line calling each). You can test the difference by commenting one out and running the program, then uncommenting that one and commenting the other one out, and calling the program again.
How to escape infinite loops?
MATLAB can't directly tell you you have an infinite loop, it does attempt to give you some hints. The first comes when you terminate the program. Terminate it by pressing CTRL+C and MATLAB will give you a message telling you exactly what line you stopped on. If your program is running a long time, it is likely the line you stopped in is in the middle of an infinite loop. sometimes MATLAB won't even let you return to the main window to press CTRL-C. In this case you probably have to kill the whole MATLAB process. After this, add a "pause (0.001)" or a similarly small value in the loop you suspect to be the infinite one. Whenever MATLAB passes this instruction you will be able to interact with MATLAB for a (very) short time, e.g. go to the main window and press CTRL-C with MATLAB being able to respond to your command.