Archived

This topic is now archived and is closed to further replies.

trzy

ReadProcessMemory() under Win32

Recommended Posts

Hello, I''ve been trying to write a utility to dump a process''s heap. I''ve tried using Toolhelp32ReadProcessMemory() and ReadProcessMemory() (both take the same arguments) but whenever these functions executes, a debug error window pops up saying something like this: DAMAGE: after Normal block (#25) at 0x00780EA0. The function which actually dumps the memory is:
static int WriteBlockOut(FILE *fp, HEAPENTRY32 *h)
{
	byte	*buf;

	if (h->dwFlags & LF32_FREE)	// nothing in the block
		return 0;

	if ((buf = malloc(h->dwBlockSize)) == NULL)
	{
		fprintf(stderr, "out of memory\n");
		return 1;
	}
	
	if (Toolhelp32ReadProcessMemory(h->th32ProcessID, (void *) h->dwAddress, buf, h->dwBlockSize, NULL) == FALSE)
	{
		free(buf);
		fprintf(stderr, "failed to read process memory\n");
		return 1;
	}

	fwrite(buf, sizeof(byte), h->dwBlockSize, fp);

	free(buf);
	return 0;
} 
For the complete source code (compiles as a console application under MSVC), check out http://www.dynarec.com/~bart/heapdmp.c Run it without any arguments on the command line to get a list of running processes. If you specify a process number in hex on the command line (heapdmp fffaf535), the program will attempt to dump the heap. Any suggestions as to what I may be doing wrong? The functions I use are documented in the MSDN library. --- Bart

Share this post


Link to post
Share on other sites
the .c file runs without any problems, msvc7 @ xp. are you sure this function is the one causing the problem?

Share this post


Link to post
Share on other sites
It must be. If I comment it out, the program runs just fine (except that no heap data is read and written out to the file, of course.)

---
Bart

Share this post


Link to post
Share on other sites
find the allocation number which gets corrupted and use _CrtSetBreakAlloc (or something like that) to break on that allocation.

just because commenting that function makes the problem go away doesn''t mean that that function is actually causing the problem; it may be just letting it surface.

Share this post


Link to post
Share on other sites
I''m not very familiar with what my options are to debug this problem. Assuming I locate the problematic block, what can I do about it?

I''m not even completely confident in my method for scanning through the heap blocks of a given process.



---
Bart

Share this post


Link to post
Share on other sites