Q:

Explicitly causing AccessViolationException in a .NET application

I'm debugging a pesky AccessViolationException in a rather large .NET application (one that takes down the entire process, leaving nothing but an Event Viewer entry). There's a lot of distracting things going on in that application, making root cause analysis quite hard. I would like to have a "toy problem" version, but being (at best) rusty at C++, I'm having a hard time creating a .NET application that dies with such an exception.
I've searched and found for example this somewhat old post that shows code that should throw the exception I want. But if I compile this:
static unsafe void Main(string[] args)
{
    Console.WriteLine("Doing stuff");

    try
    {
        int foo = (*((int*)0));
    }
    catch (AccessViolationException)
    {
        Console.WriteLine("Don't want to reach this.");
    }

    Console.WriteLine("Waiting");
    Console.ReadKey();
}

Or this:
static unsafe void Main(string[] args)
{
    Console.WriteLine("Doing stuff");

    try
    {

        int foo;
        int* ip = null;
        foo = *ip; //crash!
    }
    catch (AccessViolationException)
    {
        Console.WriteLine("Don't want to reach this.");
    }

    Console.WriteLine("Waiting");
    Console.ReadKey();
}

PS. The catch block is there because my actual scenario I'm trying to represent is one where I cannot catch the exception either (so I cannot just throw it myself).
with the "Allow unsafe code" option on, in a fresh .NET Console application, it crashes with a Null Reference Exception, not an AccessViolationException. Although I'm not all too surprised, and kind of understand why that is the case, I'm still left with the original problem.
Bottom line:: is there an easy way to create a .NET application that causes an AccessViolationException on demand, preferably in a way that the process completely dies without the option of exception handling, leaving only a trace in the Event Viewer?

A:

Replace 0 (or null) with -1 — it should trigger the desired behavior because −1, when implicitly casted to a pointer, results in 0xFFFFFFFF… which usually belongs to kernel-mode address space (both in Windows and *nix) that you are not allowed to read from user-mode programs.

