Share via

Why does Software Crash #1 – The Access Violation

  • Article

Pop quiz: what does this line of code do when executed?

           

            int foo = (*((int*)0));

If you’re an astute reader, you can solve the answer just by reading the title of the blog post. But, more interestingly, let’s forget about that buzzword and analyze exactly what’s happening. The access violation is probably the most common crash in unmanaged software, so let’s break it down piece by piece to discover what’s happening.

 

      int foo;

      int * ip = NULL;

      foo = *ip; //crash!

On the first line, we declare an integer variable named “foo”.

 

The second line declares a pointer to an integer named “ip”, and initializes this value to NULL (which is simply a fancy term for 0). Pointer variables “point” to a location in memory. In this case, we initialize it to point to the address NULL, or 0, of memory. Location “0” is in area of memory reserved by our operating system.

 

The third line attempts to grab the value of address 0, which is prohibited, and assign it to our variable “foo”. Our operating system smartly catches this and says “No way- you can’t see my reserved memory location!”. Our operating system shuts down this badly behaving application with an error like the following:

 

Unhandled exception at 0x004173c8 in cpractice.exe: 0xC0000005: Access violation reading location 0x00000000.

 

This error message is a bit cryptic, but it's understandable if broken down. 0xC0000005 is the error code designation for an Access Violation. 0x00000000 is the location that we tried to read (this is our NULL value!). And, 0x004173c8 is the arbitrary memory location where our application happened to be running at the time of the crash.

 

AV's can happen for both reading and writing, which is part of the reason that they are so common. Pointers in general are one of the most challenging topics in computer science, which is yet another reason this crash is so commonly seen.

 

-Greg

Comments

  • Anonymous
    January 12, 2005
    The comment has been removed
  • Anonymous
    January 13, 2005
    Correct about spotting some of my assumptions.
    An NT based operating system won't just throw an AV for OS reserved memory as well- if you try to access memory reserved by another application, the same error will apply. (Actually, as I think about this, this may only be true if you're not running as Administrator- I'd have to investigate that further).

    The Watson dialog is certainly a UI improvement over a "0xC0000005" error- I'd like to do a post on exactly what we do with said data when it's submitted. In the mean time, click "Send" and we'll keep busy fixing crashes. :-)
  • Anonymous
    January 13, 2005
    Chris Flaats blog gives a good exlpanation of the Watson and links out to the mini-dump information site on msdn. Just if anyone was confused what "Watson" is:

    http://weblogs.asp.net/cflaat/archive/2003/07/24/51598.aspx
  • Anonymous
    January 13, 2005
    The comment has been removed
  • Anonymous
    January 17, 2005
    More on the topic at the above link.
  • Anonymous
    November 27, 2007
    PingBack from http://feeds.maxblog.eu/item_114602.html
  • Anonymous
    April 28, 2009
    PingBack from http://bnetdev.net/technical-support/5862-crash.html#post53339