[aeotaph]

Hi,

I'm playing around and trying to get my head around Windows memory management, but I'm entirely stumped on this. I have a Macromedia Flash .swf applet running in an instance of Internet Explorer. I know that this swf is storing a particular integer variable (the score in a somewhat dubious Tetris clone - but I'm just trying to understand the principle, and it seemed like a good example to start from).

Using the ReadProcessMemory API, I can take a snapshot of the memory assigned to the Flash8.ocx module, having assumed that's where Flash would keep its data. I'm using this in sync with the Visual Studio debugger to suspend the process, dump the memory snapshot, and restart it. I can then take several snapshots, recording the score each time. I then iterate through all the snapshots simultaneously and try to find the location whose value is equal in each to the recorded score for that dump. (Keeping the score below 256 so I'm just looking for a single byte).

The problem is that there is no such location in the memory assigned to Flash8.ocx. In fact, when I step back and repeat the process more heavy-handedly, there is no location anywhere in any module owned by the Internet Explorer process that contains the score value.

This started out as just an exercise to practice the various APIs for examining another process' memory space, but now I'm just really intrigued as to what the answer is. Does anyone have any thoughts as to where this mysterious variable is really stored?

Thanks in advance!

--
Ben

[lotuseclat79]

Originally Posted by aeotaph

Hi,

I'm playing around and trying to get my head around Windows memory management, but I'm entirely stumped on this. I have a Macromedia Flash .swf applet running in an instance of Internet Explorer. I know that this swf is storing a particular integer variable (the score in a somewhat dubious Tetris clone - but I'm just trying to understand the principle, and it seemed like a good example to start from).

Using the ReadProcessMemory API, I can take a snapshot of the memory assigned to the Flash8.ocx module, having assumed that's where Flash would keep its data. I'm using this in sync with the Visual Studio debugger to suspend the process, dump the memory snapshot, and restart it. I can then take several snapshots, recording the score each time. I then iterate through all the snapshots simultaneously and try to find the location whose value is equal in each to the recorded score for that dump. (Keeping the score below 256 so I'm just looking for a single byte).

The problem is that there is no such location in the memory assigned to Flash8.ocx. In fact, when I step back and repeat the process more heavy-handedly, there is no location anywhere in any module owned by the Internet Explorer process that contains the score value.

This started out as just an exercise to practice the various APIs for examining another process' memory space, but now I'm just really intrigued as to what the answer is. Does anyone have any thoughts as to where this mysterious variable is really stored?

Thanks in advance!

--
Ben

Hi Ben,

Applets may be executed in their own thread separate but under the aegis of the process. I would hazard a guess that the mysterious integer is stored in that thread's memory. Oh, and make no assumptions about in what module the integer is stored. Since threads can be multiprocessed, data that is necessary to be preserved between executions of the thread, possibly on a different processor, may need to stored in the thread 'private' memory - but, that is a detail that may or may not have been observed by the applet programmer, and if not, may constitute a bug depending on whether the code is executed on a multiprocessor or not.

If you know the name of the variable storing the integer, set a watch point on it with the debugger, and let it take you to the variable when the value changes. However, my guess is that you do not know the name of the variable, and do not have the source code for the applet.

My advice is take a course on Windows Internals or consult a book such as Windows Internals from Solomon and Russinovich or Windows System Programming (3rdEd) by Johnson M. Hart to learn more about Windows memory management. And, by all means, do keep your curiosity alive!

-- Tom

[aeotaph]

Originally Posted by lotuseclat79

Applets may be executed in their own thread separate but under the aegis of the process. I would hazard a guess that the mysterious integer is stored in that thread's memory.

I didn't realise that a thread of one process could access memory outside that process (except using the debugging APIs, that is) - I guess that does broaden the playing field a bit!

I've actually tried repeating the experiment with a different Flash applet and found that it *does* store a simple integer in the memory space assigned to Flash8.ocx - so I'm beginning to wonder if perhaps the first one is doing something odd like storing the score in BCD format. I shall no doubt get to the bottom of it one day

My advice is take a course on Windows Internals or consult a book such as Windows Internals from Solomon and Russinovich or Windows System Programming (3rdEd) by Johnson M. Hart to learn more about Windows memory management. And, by all means, do keep your curiosity alive!

I shall look up that book - thanks for such a detailed answer, Tom

--
Ben

[lotuseclat79]

Originally Posted by aeotaph

I didn't realise that a thread of one process could access memory outside that process (except using the debugging APIs, that is) - I guess that does broaden the playing field a bit!

I've actually tried repeating the experiment with a different Flash applet and found that it *does* store a simple integer in the memory space assigned to Flash8.ocx - so I'm beginning to wonder if perhaps the first one is doing something odd like storing the score in BCD format. I shall no doubt get to the bottom of it one day

I shall look up that book - thanks for such a detailed answer, Tom
--
Ben

Hi Ben,

Debuggers can 'attach' to another process, and in my previous post, since you had stated you were using a debugger to investigate, my assumption was that the applet was being run by a thread which is a light-weight process under the aegis of the process running the browser in which the applet is running - i.e. threads are subsumed under a process to which they belong.

The format the integer is stored depends on the data type coded in the program language (C/C++/Java?) in which the applet is written vs the integer format of the machine on which the applet is running. If the machine is an Intel compatible, it is probably stored in little-endian format which is the format of integer representation in the machine.

Modern debuggers take advantage of /proc approaches to reading/writing the memory of a process without having to go through kernel accesses as in older approaches like ptrace calls on the kernel. Although these terms are Unix in heritage, its likely that MS uses something akin to the /proc approach to debugging these days??? A multiprocessor debugger can use one processor to watch the goings on in another processor running the code to be debugged - and with a /proc approach in a large shared memory - how cool is that, near real-time, and it would not be so with a ptrace approach!

Windows memory management is a topic best digested by understanding Windows Internals because it is the responsibility of the OS to keep memory for different processes separate.

-- Tom

P.S. There are a lot of debugging articles at codeproject.com and you can learn a lot about how debugging works from them - also, related topics like memory management - and some free code for various kinds of software.
They sell at retail MS product (Developer price), but they do host a lot of good articles.