I want to set a break point and wants it to be triggered when a piece memory (begin address and length are known) are changed. I am working on Windows Server 2003 x64 platform. Either solution in Windbg or solution in Visual Studio are fine. My purpose is to monitor when the memory content is change.
thanks in advance,
George
Try setting a data breakpoint.
In Visual Studio:
Go to Debug >> New Breakpoint >> New Data Breakpoint
Enter the address you want to watch (or an expression that evaluates to an address; such as &foo)
Enter the number of bytes to watch at that address
Click OK, run your program in the debugger, and wait!
This can be done in GDB also. In GDB, this is a watch on a specific address (I've had success setting watches on the address of C++ object members in this way).
Not sure about VS, but with windbg you can use the following command
ba w size address
Replace size with the length of the memory and address with the start address of the memory.
You can set a data breakpoint but you'll need to know the address of the memory location you're interesting in before you can set such a breakpoint. Typically, I either set a breakpoint at the beginning of my program or have the debugger suspend on attach so I can find the memory address of the variable I want to monitor, then set the data breakpoint.
Related
I'm trying to get log of activity of my application with WinDbg. At the moment I'm on Win10 Pro x64. The entry point of my application is 0x10004D7EC. After start of WinDbg I press Ctrl+E to select my app. I input the next command
bp 10004D7EC
then hit F5 but WinDbg says that ERROR_PARTIAL_COPY has been occured (0x12B) so it seems that loading logexts is a bad idea because there is no garanty that information will be correct. So, how to fix this or maybe I do something wrong?
I believe that you're getting the error because you are putting your breakpoint on an invalid memory location. Check in the memory/disassembly window in windbg what is at this memory location - you'll probably find nothing there.
I guess that 10004D7EC is the address of your entry point on the disk - which might be different from the entry point address at runtime. You can search for the entry point with: x <your module name>!*<your entry point name>* (i.e. x myApp!*main*)
When I am debugging in Microsoft Visual Studio 2017 my "Registers" window shows no data available. What can I do to fix this?
As Sneftel stated, you cannot inspect data in the debugger unless you break the execution of the process. During execution, things would be changing far too quickly for any data display to be meaningful.
You can use the "Pause" button in the toolbar to break execution, and then you will see everything in the debugger: the current source line, the contents of registers, your "watch" variables, the full contents of memory in the "Memory" window, etc.
You can also set a breakpoint on a particular line of code, and then execution will break once that point is reached.
Once paused, you can then single-step through your program's code. This means that one line of code (the very next one) will be executed, and then the program will break again so that you can see everything in the debugger. This is an excellent troubleshooting technique—one that you should be well-acquainted with. In fact, I recommend that you single-step through every line of code that you write, just to make sure that it works correctly. You can also modify the contents of registers and variables (or, really, any location in memory) while you are single-stepping, giving yourself a way to test potential bug fixes or even introduce bugs (e.g., invalid input) to see how your code handles them. The default keyboard shortcut for single-step is F11.
You'll find more information about using the debugger, and the available keyboard shortcuts, here on MSDN. As you can see, that article confirms my answer:
Most debugger features, such as viewing variable values in the Locals window or evaluating expressions in the Watch window, are available only while the debugger is paused (also called break mode). When the debugger is paused, your app state is suspended while functions, variables, and objects remain in memory. While in break mode, you can examine the elements' positions and states to look for violations or bugs.
(Edit-and-continue is not available in assembly projects. You will need to stop execution and rebuild if you want to make changes to your code.)
For those with the "No data available" message, you can right click in the Registers window and choose what you want to see (UC, MMX, SSE, etc). It seems like by default there's nothing selected in Visual Studio 2019. At least, on mine there was nothing selected.
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?
Is there a way to follow a program's execution through DLL code in hex?
For example, I want to see what sections have just been read when I press a button. It has to work for x64 DLL's.
Thanks!
Yes you load the process into debugger and single step it.
Load the project in visual studio.
Press 'Play' or F5 to start the program in the debugger.
You will need to eventually halt execution sometime so you can start stepping through code or assembly code. You can do this by inserting a breakpoint, or breaking the execution by hitting the break command in the visual studio IDE.
Once halted, you can right click in the code view window, and select "Show Disassembly". Then it will show you the machine instructions.
Also in the watch window in the visual studio debugger, the right click pop up menu has an option to display all variables as hexidecimal. I'm beginning to prefer hex myself lately, because I can see invalid memory patterns easier.
You can use the tool at http://ircdb.org to log function calls arbitrary DLLs.
It's name is SocketSpy, because initially it was created for tracing winsock.dll only, but it does allow you to trace other dlls.
From http://fixunix.com/programmer/95098-tracing-library-dll-calls-win32.html
Use Option->Default Break Point List
Menu to add or remove soft breakpoints
from attached DLLs. Put soft
breakpoints only at function you need
to maximize execution time.
Soft breakpoint means that socketspy
does not stop at this breakpoint, only
log breakpoint information. Hard
breakpoint means that socketspy DOES
STOP at this breakpoint, and
Breakpoint dialog is opened. Specify
what calls should be captured ALL,
FROM EXE FILE or from DLLs (Combobox).
Specify log file File->Open Log File
menu if you want to save function
DLLs' calls into the text file, enable
logging (check box).
Then select a new or already action
process (Select Process button). The
tool can be used in NT/2000/XP only
Alternatively, there is StraceNT, which can trace arbitrary Dlls. It is available for free from http://www.intellectualheaven.com/default.asp?BH=projects&H=strace.htm
I've not used it, but I once stumble upon an Intel tool, which samples the context of the Instruction Pointer, and is able to use symbol files to convert IP to an actual function name... VTune maybe?
I guess there might be other such tools
UPDATE: aka. "statistical profilers"...
Debugging using IDE does not show you the assembly language equivalent of the execution of an IL instruction. You need to write your own hooks to a proper disassembler.
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.