Pyjong
Pyjong

Reputation: 3197

windows process memory layout

So I was playing with Olly debugger, sniffing around what I can yet find out about windows and I pressed that M button and it popped up that memory map window. So I googled up some articles on the subject and I found out I can actually write to addresses above 64K which I tried and well.. why would it not work. About those lower 2GB of space:

Thank you for reading this question.

EDIT

Ah here we go with what's at 0x10000 and that's also probably why that page is let writable.

Upvotes: 5

Views: 1931

Answers (2)

wallyk
wallyk

Reputation: 57784

You don't seem to have a focused question, so it is hard to provide a valuable answer. However, you seem to imply the question How does Windows map user space memory?

First off, the low virtual memory space—from zero to 64K or more—is left unassigned to catch NULL-based pointer dereferencing. These are common programming errors which we want to know about immediately. The program almost certainly should terminate if one occurs. By leaving this space unmapped, Windows' equivalent of SEGFAULT occurs. Very useful.

Typically, code and constant space is allocated next. Once a program has begun running, there is usually no need for this space to change, so it is set to readonly, and parts of it are marked executable—usually the first portion, which can be 99% of the space. If there are shared code libraries, those are mapped in after the primary code (usually), often with small gaps so that the library code segment is page aligned (perhaps 4K, perhaps 64K or larger) for efficient memory management register usage. There is rarely a need to conserve virtual memory space.

After those is data space. That can be initialized memory, or uninitialized. It all has to be read-write. And it needs to have space reserved above it so it can grow for heap space growth.

Way above data space is stack space. It has to be read-write and have room below it so it can grow. All modern CPU stacks grow toward low memory.

And above the stack is system space.

If the process requests access to shared memory (with other processes), the size of the mapped window dictates where in the memory map it can fit. Mapped too close to where the heap grows is a problem, and too close to potential stack growth is also a problem. Fortunately, fairly simple placement algorithms solve this for the vast majority of programs. Just think about the various needs and you can probably figure out why the operating system does what it does.

Upvotes: 4

adelphus
adelphus

Reputation: 10326

Not all memory is available for use by applications. For example, some types of hardware require memory so the system (BIOS or OS) will allocate a block of physical memory and leave it for the hardware to manage itself. That memory may not be directly readable (or writable) because performing such operations would affect the hardware. The hardware itself may have its own restrictions about what memory ranges it can use.

If you're in Windows, you can't go writing to arbitrary memory locations - the OS won't let you (in usermode at least) and will have paged the memory anyway, so the address you think you're looking at (the virtual address) won't match the actual physical memory address.

In general, you should only read and write to memory that has been requested and allocated to you by the OS.

Upvotes: 1

Related Questions