Access Violations and Memory

Started by
25 comments, last by SiCrane 18 years, 5 months ago
I'm really confused and I hope one you more experienced programmers can sort me out. I have the follow c++ source ->

void main()
{
	unsigned int *ptr_to_mem = (unsigned int *)0x00000000; // could be anything for all I care, 0xXXXXXXXX
	*ptr_to_mem = 0xFFFFFFFF;
}

As you can see I'm trying to change the value of the memory at this location. I'm doing this to teach me more about the OS, winDBg(visual studio's debugger) and how memory works in windows, all for my future mastery of assembly programming. I keep getting access violations 0xC0000005 which is perplexing because I thought each program was given its own 4 GB address space, because windows runs in protected mode. When I debug the program I see at the address 0x0000000 there is just uninitialized data, so I don't know why I would be getting the access violation, because from my perspective it's just free memory! This makes me wonder how the compiler sets up memory to be used when I dynamically allocate it. This is what I get for learning assembly, a lot of questions.
Advertisement
On windows the memory addresses from the range 0x0000 0000 to 0x0000 ffff are a protected range that your program cannot write to without generating an access violation. Even if you had a pointer to another location, a program can only legitimately write to a memory location that has been committed, which may not be true of a given random memory address.
Just because your program is given a 4GB address space, it doesn't mean it is free to use whichever parts of that it chooses. The top 2GB are reserved for the OS, and the lower 2GB are only made usable when you request memory from the OS. Moreover, the bottom 64(?)KB will never be allocated to you, in order that writes to NULL pointers are caught.
thanks sicrane and bakery, that explains why I was getting the access violations.
This code

unsigned int *ptr_to_mem = (unsigned int *)0x00000000;
*ptr_to_mem = 0xFFFFFFFF;

is akin to

unsigned int *ptr_to_mem = NULL;
*ptr_to_mem = 0xFFFFFFFF;

that means that ptr_to_mem doesn't point to valid memory, so attempting to dereference the pointer in order to write a value to the space it points to, throws an access violation exception.
"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man
And theres a ton of good information here: http://www.mega-tokyo.com/osfaq2/ regarding how OS's implement this kind of stuff, amongst other things.
nice observation there LessBread, didn't even realize. I get get an access violation at pretty much any memory address I try to write and read from, even if the memory address > 0x0000FFFF, I guess I have to go through the operating system to get access to my program's memory, i.e. by using functions defined in kernal32.lib
Quote:Original post by RDragon1
And theres a ton of good information here: http://www.mega-tokyo.com/osfaq2/ regarding how OS's implement this kind of stuff, amongst other things.



Thank you RDragon, i've been googling since I posted this thread for information about that stuff.
Quote:Original post by ordered_disorder
nice observation there LessBread, didn't even realize. I get get an access violation at pretty much any memory address I try to write and read from, even if the memory address > 0x0000FFFF, I guess I have to go through the operating system to get access to my program's memory, i.e. by using functions defined in kernal32.lib


Basically, just stick to the memory you've new'ed or malloc'ed. Everything else can give you an access violation (Occasionally it won't, but only because you accidentally hit somewhere within a page that's already been allocated to you)
Different parts of memory have different permissions. Some you can't touch at all, some you can only read from. Some parts you can run code in and some parts you can't, etc, etc. An access violation means that you've tried to do something that is not allowed for that particular piece of memory.

You can have the OS allocate memory for you and once that's done you can usually request that it change the permissions around.

(and windbg is not Visual Studio's debugger. The debugger built into VS and windbg are two unrelated debuggers).
-Mike

This topic is closed to new replies.

Advertisement