I'm trying to follow this tutorial but with the immediate window in vs2010 rather than WinDBG:
http://blogs.msdn.com/b/dougste/archive/2005/11/25/497016.aspx
but I'm getting stumped by the following:
Each static is represented by a
particular element in this array. So
we can find it by searching for it in
the memory occupied by the Object[]:
0:003> s-d 0 L?0xbfffffff 03651ec4
01cc2fc8 03651ec4 00000500 01cc3008 11000001 ..e......0......
02060094 03651ec4 e13989e8 c35e9077 01cc1880 ..e...9.w.^.....
this "s-d" isn't a part of the sos.dll, so I assume it's either WinDBG or some other extension that dumps the memory at an address.
Is it possible to run this command in the immediate window, or otherwise get the memory dump at an address from Visual Studio?
Well, it seems to be searching memory for a particular bit pattern, so it would seem to resemble .S
Related
I am trying to change bytes in memory, in a memory window, when debugging a C++ project in my Visual Studio 2017. The memory window is pointing at memory holding code, as I am trying to patch a piece of code quickly (just need to change parameter value) without needing to stop and re-compile.
I also noticed that you cannot change values in the memory window even for data memory.
Is there some hidden configuration setting to let you do that. It was possible to do this in VS6.
I found a kind of work-around, that works even for modifying executable code memory.
Here are the steps:
Define a spare global pointer in your code (you can actually use any memory pointer in your code as long as you do not care that you will change its value):
char* memptr;
Set the pointer in a watch window.
Set the pointer value to the memory address that you want to modify.
Expend the content (BTW you can use "memptr,100" in your watch window to access more than one byte).
Type the updated value in the expended byte value cells.
This works even if you set the pointer to executable machine code memory, so you can use it to patch code.
It can be an int pointer or any other type, or you can use a cast in the watch window if you desire to edit any other kinds of objects.
Be careful this can be dangerous, modifying of memory has to be done with the greatest of care.
How do I change memory bytes in Visual Studio 2017?
As far as I know, Microsoft does not support changing the memory bytes directly in the latest Visual Studio including VS2017 and there is no such hidden option to realize it.
In general, during debugging, the Memory window shows the memory space your app is using. And the Memory window isn't limited to displaying data. It displays everything in the memory space, including data, code, and random bits of garbage in unassigned memory.
Besides, memory bytes changes with the values of variables in debugger windows such as Watch, Autos, Local Variables, and QuickWatch dialogs. Then analyze its changes in memory usage to improve the program. Because of it, we cannot change it directly.
In addition, more info about Memory Window, you can check this official document.
I'll be using Visual Studio for C/C++ as a framework because that's the debugger I'm most interested in.
When I set a breakpoint in the code, it becomes "immediately" active even if the code is already running. As far as I understand, this is done by Read/WriteProcessMemory. What I don't understand is how you get the exact memory address that you write the int 3 instruction into.
For static breakpoints, it's easy because then the compiler could essentially parse the breakpoint alongside the source code, and insert the int 3 instruction as a natural part of code gen. But with dynamic breakpoints I don't see how you can map a breakpoint on an arbitrary line of source code into the correct address for the executable as it is running. How do you calculate it?
When I inspect a string variable text using Visual Studio's Memory window, I get to see its value:
Out of curiosity, is there a way to inspect (also in the Memory window) the location where that value gets referenced?
(Of course I can already see the memory location's address. I am asking this because I am curious how the CLR represents, and works with, class-type instances. Based on what the CLI specification states, I am assuming that the CLR represents them at least as a combination of a pointer, a type token, and a value. I am seeing the latter two above, but would like to see the pointer, and what else might be stored along with it.)
In general there's not just one location, especially since this is an interned string. But you do have one since you know that the text variable points to the string. So use the address-of operator to get the address of the reference, type &text in the Address box.
You'll probably want to make it a bit more recognizable, right-click the Memory window and select "8-byte integer". You'd see 000000000256D08. The area of memory you are looking at is the stack of the main thread.
Do beware that this is all a bit academic. This works because you are using the debugger and the jitter optimizer was disabled. In an optimized program, that pointer value is going to be stored in a cpu register. And in the specific case of your test method there would be nothing to look at because the assignment statement will be optimized away.
You can see the "real" code with the Release build and Tools + Options, Debugging, General, untick the "Suppress JIT optimization" option. Beware that it makes the debugger stupid, it no longer knows much about local variables. The most important debugging windows then are Debug + Windows + Disassembly to see the code and Debug + Windows + Registers to see the CPU registers. Right-click the latter window and tick SSE2 so you can see the XMM registers, the x64 jitter likes to use them.
My solution in needed only in Win7/8-64bit.
Some program (I have no sources, 32-bit) loads some dll's. One of this dll is mine. I would like to search whole process memory with all loaded dll's for existence of some string (I would like to change one byte of this string in all occurrences)
I know there is WinAPI ReadProcessMemory, but since my dll is in the same address space, maybe I could read its memory just like that.
Opening process RAM in HxD program shows that addresses from 0x10000 to 0x21000 is readable. Then 0x41000 is not readable etc. I've tested it, and it gives me Reading Memory error when reading 0x4100 from dll.
Is it possible to read all process data without use of ReadProcessMemory? How to know which addresses are readable?
I was wondering if there is any feature in Visual Studio 2008 that would show me data stored at address XY? Specifically I need to check data the pointer points to. Something like this:
BYTE *pMem = (BYTE*)GlobalAlloc(GMEM_FIXED | GMEM_ZEROINIT, FileSize);
<do some magic at pMem+offset1>
//bug occurs, need to check data at pMem+offset2>
Basicly the "Locals" window shows me only first few bytes of the *pMem while I need to see 100th byte for example.
Of course I can store it in some another variable and check it when the execution hits the breakpoint but thats not as much handy/quick as looking at some window or writing some command somewhere in special console while the app is paused.
Thanks for any info.
Kra
P.S. its C++, not managed code
Use a memory Window (Debug | Windows | Memory) of which there are four to look at four different areas of memory.
Enter the address or expression that gives the address and you'll see the memory. VS will highlight the changes as you step through code).