I tried looking on MSDN, Google and Stack Overflow and I couldn't find an answer to what I'm looking for.
Is there a way to edit, through the Memory Window, the code at a given address? I use the Disassembly Window to get the address of the instruction I would like to overwrite, find it in the Memory Window but "Edit Value" is grayed out. Any reason why? Is it because my code gets cached and VS prevents me to edit it? Is there a way to change that through project settings?
Thank you
The application is consisted of data parts and executable parts of code. Windows forbids the changes to executable parts by default, but this can be changed from the code with VirtualProtect function (also pay attention to remarks and FlushInstructionCache).
Maybe your ultimate goal is not to change some code from debugger, but something else that can be achieved differently. What do you really want?
Related
I have a feeling the answer to this is either "you can't" or it will be embarrassingly obvious, but when you hover a variable in the VS (2015) debugger, how do you know what type it is?
In this case, it's System.IO.FileNotFoundException, but I only know that because I checked it in the Watch window.
DataTips just provide a convenient way to view information about variables in your program during debugging, it doesn't have a column to show the type of the variables, we often add them to other debugger windows like Watch windows or others if you really want to view more detailed information about it.
But I think it is a good feature request: https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/16283041-show-the-type-from-visualstudio-debugger-datatip
How to avoid the window "No source available" while stepping into debug mode on VS2010 SL5
In Tools, Options, Debug, General Page. Check if you have 'Enable .NET Framework source stepping' enabled, if it is enabled, disable.
I tried all the suggested fixes; Nothing worked for me.
I finally figured out the solution after several hours of trial & error iterations.
It turns out that the 'No Source Available' error is due to a stack-overflow within the VS debugger env.
The C/C++ code function that was supposed to be stepped-into (by VS debugger), was using a variable that was initialized to a stack array of a few MB in size. When I replaced this with a heap allocation, VS was successfully able to step into the code.
This worked for me.
Please note that in my case, the actual code (with the stack allocation) ran without a stack-overflow error within the debugger (if I skip the No source available error). It was just that VS's debugger's was not able to step-into a particular function sitting inside another C/CPP file, because of the internal stack overflow.
Hope this helps.
You can hit Shift+F11 to step out and it will complete whatever unavailable function it is in and stop at the next line (it may be unavailable as well, but continue to use Step Out until you get to code you want to examine.)
Regarding VS2019, a description for the issue is provided at MSDocs.
For the requisite vcruntime and ucrt source files, the problem can occur after importing from a previous VS version which has since been uninstalled.
To prevent VS from using the old directories, find the solution property pages and navigate to the Debug Source Files Dialog Box.
Click the tick button to check the entries where any invalid ones can be removed.
The vcruntime and ucrt source should always exist in the directories, and the path at the top of the Browse to find source code dialog should always show the correct path.
In my case, because of a venerable drive bug, it is given to prompt for the "D" drive instead of the "C" drive. Further, the provided path cannot be pasted over to refresh the view, so, if none the wiser, one has to use the dialog to navigate all the way up to the required location from the desktop or equivalent.
Here there is an extension for this issue:
http://erwinmayer.com/labs/visual-studio-2010-extension-disable-no-source-available-tab/
But in my own experience before finding this article (I was in page but I was trying to fix it myself without reading article) I have fixed this problem just by accepting a confirmation message saying something like "Selected source file is different from compiled assembly. Are you sure you want to use this file for debug?". But I can't remember exactly what I did to get this message. I think there was a linklabel which I clicked on "No source available" window and then confirmation message appeared and after confirm the problem ran away.
Hy everybody,
I'm wondering if it's possible to add a new button via C++ or C# to windows 7 explorer "context strip"(don't know if this is correct name) - like on picture below.
My reason for this is because a lot of times I'm switching on&off "Show hidden files, folders and drives" functionality under Tools->Folder option->View. Therefore i want to simplify this process with a click of a button.
I was looking into ShellExecteEx function, but I am not sure I can do that. Can Anybody direct me in right direction?
thanks,
regards
I highly recommend using AutoIt for this task. Second URL comes complete with examples of how to insert buttons in various programs - however, be sure to read complete topic for misc. updates to the provided code.
See:
http://www.autoitscript.com/forum/index.php?showtopic=9517
Btw: I misread topic to begin with; gui 'context' related material in Windows is often taken to deal with right-click menus
Edit: limit on urls for new users on Stack Overflow mean I had to cut out some of less essential links - google away.
To answer part of the question, I think it is possible as for quite some time we've seen small programs to add a "New Folder" button to the explorer. I think those still works with Win 7.
Look at http://tools.tortoisesvn.net/StExBar for example
[Edit] Forgot to clarify that Source Code for StExBar is on Google Code
Is it possible to view the heap and stack during debugging?
AFAIK, the main windows you'd want to use are the Locals (Ctrl + Alt + V, L) and Autos (Ctrl + Alt + V, L) windows which MSDN has as:
The Locals window displays variables local to the current context or scope. Usually, this means the procedure or function you are currently executing. The debugger populates this window automatically. In Visual C#, when the Exception Assistant is disabled, the Locals window also displays a pseudovariable $exception whenever there is an active exception. You can expand the pseudovariable to see details of the exception.
The Autos window displays variables used in the current line of code and the preceding line of code. For native C++, the Autos window displays function return values as well. Like the Locals window, the Autos window is populated automatically by the debugger.
...and for the Stack there's the Call Stack window (Debug -> Windows -> Call Stack) or Ctl + Alt + C.
However, I get the feeling this isn't what you're after.
If you are looking for an "in-memory" view you might be able to make use of Visual Studio's Memory windows which can be accessed from the Debug -> Windows -> Memory -> Memory x menus (where x is 1-4) or Ctrl + Alt + M, 1-4.
As a few people have now mentioned, there are a couple of other external tools which are quite useful for memory debugging (I use mainly SysInternals tools and the Debugging Tools for Windows).
You need the "Call Stack Window"...
http://msdn.microsoft.com/en-us/library/a3694ts5.aspx
By using the Call Stack window, you can view the function or procedure calls that are currently on the stack.
And for the Heap, the "Memory Window"...
http://msdn.microsoft.com/en-us/library/s3aw423e(VS.80).aspx
The Memory window provides a view into the memory space used by your application.
"Restoring Hidden Debugger Commands" may also be useful...
http://msdn.microsoft.com/en-us/library/9k643651(VS.80).aspx
As you get into debugging memory, other debuggers will be more useful. As someone suggested, WinDbg is excellent for memory debugging. I use IDA Pro Disassembler a lot myself.
You can view the call stack while debugging, but I assume that's not what you're looking for. You might want to try Windbg and SOS, which are GREAT for debugging memory issues. A bit steep on the learning curve, but the payback is HUGE.
Microsoft Debugging Tools for Windows
If you actually want to look at the raw memory for some reason you can open the "Memory" debug window from "Debug->Windows->Memory" and write the address you want to look at in the edit box. You can also write in the edit box any expression which evaluates to an address and it'll show you that address, for instance &variable
This is not very useful for actually looking at variables because you'll have a tough time parsing the raw bytes into meaningful values but it can be useful for debugging situations where you suspect there are buffer overruns or memory that is overwritten unexpectedly. It is particularly useful when used in conjunction with data-breakpoints.
I know this is an old question, but I figured I'd update it anyway...
Visual Studio 2015 comes with the Memory Usage Monitor built right in to the Diagnostic Tools panel. If you take snapshots before, during, and after what you want to inspect, you can retroactively peek at the heap view of those snapshots.
Hope this helps someone.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As much as I generally don't like the discussion/subjective posts on SO, I have really come to appreciate the "Hidden Secrets" set of posts that people have put together. They provide a great overview of some commonly missed tools that you might now otherwise discover.
For this question I would like to explore the Visual Studio .NET debugger. What are some of the "hidden secrets" in the VS.NET debugger that you use often or recently discovered and wish you would have known long ago?
One of my favorite features is the "When Hit..." option available on a breakpoint. You can print a message with the value of a variable along with lots of other information, such as:
$ADDRESS - Current Instruction
$CALLER - Previous Function Name
$CALLSTACK - Call Stack
$FUNCTION - Current Function Name
$PID - Process ID
$PNAME - Process Name
$TID - Thread ID
$TNAME - Thread Name
You can also have it run a macro, but I've never used that feature.
You can right-click an object in the Watch window and click Make Object ID.
It will assign that instance an ID number, allowing you to see, in a complicated object graph, which objects refer to the same instance.
For .net applications System.Diagnostics has lots of useful debugging things. The Debugger class for example:
Debugger.Break(); // Programmatically set a break point
Debugger.Launch(); // Launch the debugger if not already attached
Debugger.IsAttached // Check if the debugger is attached
System.Diagnostics also has lots of good attributes. The two I've used are the debugger display attribute for changing the details put into the locals window and the step through attribute for skipping code you don't care about debugging:
// Displays the value of Property1 for any "MyClass" instance in the debugger
[DebuggerDisplay("{Property1}")]
public class MyClass {
public string Property1 { get; set; }
[DebuggerStepThrough]
public void DontStepInto() {
// An action we don't want to debug
}
}
As a web developer who works with Web Services that are within the same solution as my front-end code most of the time, I found the ability to "attach" to a process to be a HUGE time saver.
Before I found this hidden gem, I would always have to set a breakpoint on some front-end code that called a web service method and step into it. Now that I know about this trick/feature I can easily set breakpoints on any part of my code that I want to which saves me loads of time and effort.
$exception in the watch window will show the exception that is currently being processed even if you don't have a catch that assign the Exception instance to a named variable.
The threads window, from Debug -> Windows -> Threads. You can Freeze and Thaw threads, and switch the active thread. This is awesome when debugging or replicating an issue with a multithreading application.
You can drag & drop the yellow "Next Statement" arrow to another place. When the program resumes, it will resume execution at that statement. You can add it to the toolbar, a blue arrow called Set Next Statement, but it's not there by default.
You can "undo" the navigation you did, like scrolling, going to another file, or jumping to a reference. The shortcut is ctrl-- (control minus.) That way you can jump into a function, examine the code there, and go back to where you were without looking.
Conditional breakpoints.
You can load windbg extensions into the Visual Studio debugger and use them from the immediate window.
As posted in another post Sara Ford is doing a current series on the VS debugger.
Her blog is the best source of VS tips: http://blogs.msdn.com/saraford/archive/tags/Visual+Studio+2008+Tip+of+the+Day/default.aspx
This is kind of an old one. If you add a watch expression err,hr, then this will hold the result of GetLastError(), formatted as an HRESULT (VC++ debugger only).
You can drag current line cursor (yellow arrow) up and down your code when execution is paused.
Additionally, in order to enable this during pause on exception you have to click "enable editing" on exception details first.
You can also make VS break on handled exceptions by checking one's of interest under:
Debug->Exceptions : Thrown column
Some useful shortcut keys.
F11 to step into a method.
Shift-F11 to step out of a method.
F10 to step over a method.
Things I use often:
Click the menu item "Debug | Exceptions" (or Ctrl-D, E for short) and you can enable breaking at the time that any exception is thrown, or choose to not break on certain exceptions.
You can set up the debugger to download some of the framework source code and symbols from a MS server and step into the framework code. (Some libraries, like System.ServiceModel, are not yet available). It in the Options windows under Debugging. See MSDN How-To.
You can use the VS.NET debugger to debug Javascript running in IE. You just need to install the IE javascript debugger, and enable javascript debugging in IE's settings. Then on a JS error it will pop up a "do you want to debug" dialog box, and you can choose to debug in VS.NET.
You can open and place a breakpoint in a source file if the file belongs to another solution (external file). The debugger can still hit the breakpoint. No need to open another Visual Studio instance to debug the external file. Helpful in debugging web services which you source to. This works as long as all the sources are current and compiled.