Блог

Это приводит AccessViolationException к выбросу:

 using System;

namespace TestApplication
{
    internal static class Program
    {
        private static unsafe void Main()
        {
            ulong* addr = (ulong*)Int64.MaxValue;
            ulong val = *addr;
        }
    }
}
 

Это приводит NullReferenceException к выбросу a:

 using System;

namespace TestApplication
{
    internal static class Program
    {
        private static unsafe void Main()
        {
            ulong* addr = (ulong*)0x000000000000FF;
            ulong val = *addr;
        }
    }
}
 

Оба они являются недопустимыми указателями и оба нарушают правила доступа к памяти.
Почему NullReferenceException?

Это вызвано дизайнерским решением Windows, принятым много лет назад. Нижние 64 килобайта адресного пространства зарезервированы. Доступ к любому адресу в этом диапазоне сообщается с исключением ссылки null вместо основного нарушения доступа. Это был мудрый выбор, нулевой указатель может производить чтение или запись по адресам, которые на самом деле не равны нулю. Например, при чтении поля объекта класса C оно имеет смещение от начала объекта. Если указатель на объект равен null, то код будет заблокирован при чтении по адресу, который больше 0.

У C # нет такой же проблемы, язык гарантирует, что нулевая ссылка будет перехвачена до того, как вы сможете вызвать метод экземпляра класса. Однако это зависит от языка, это не функция CLR. Вы можете написать управляемый код на C / CLI и генерировать ненулевые разыменования нулевого указателя. Вызов метода для объекта nullptr работает. Этот метод будет успешно выполнен. И вызовите другие методы экземпляра. Пока он не попытается получить доступ к переменной экземпляра или вызвать виртуальный метод, который требует разыменования этого, тогда бабах.

Гарантия C # очень хороша, она значительно упрощает диагностику проблем с нулевыми ссылками, поскольку они генерируются на сайте вызова и не взрываются где-то внутри вложенного метода. И это принципиально безопаснее, переменная экземпляра может не вызывать исключение для очень больших объектов, когда ее смещение больше 64 КБ. Довольно сложно сделать в управляемом коде, в отличие от C . Но не предоставляется бесплатно, объясняется в этом сообщении в блоге .

Исключение нулевой ссылки и исключение нарушения доступа вызываются процессором как нарушение доступа. Затем среда CLR должна угадать, следует ли специализировать нарушение доступа к исключению с нулевой ссылкой или оставить как более общее нарушение доступа.

Из ваших результатов видно, что среда CLR делает вывод, что нарушения доступа по адресам, очень близким к 0, вызваны нулевой ссылкой. Потому что они почти наверняка были сгенерированы нулевой ссылкой плюс смещение поля. Ваше использование небезопасного кода обманывает эту эвристику.

Это может быть проблемой семантики.

Ваш первый пример пытается разыменовать указатель, содержимым которого является адрес Int64.MaxValue, а не указатель на переменную, имеющую значение Int64.MaxValue .

Похоже, вы пытаетесь прочитать значение, хранящееся по адресу Int64.MaxValue , которое, по-видимому, не входит в диапазон, принадлежащий вашему процессу.

Вы имеете в виду что-то вроде этого?

         static unsafe void Main(string[] args)
        {
            ulong val = 1;// some variable space to store an integer
            ulong* addr = amp;val;
            ulong read = *addr;

            Console.WriteLine("Val at {0} = {1}", (ulong)addr, read);

#if DEBUG 
            Console.WriteLine("Press enter to continue");
            Console.ReadLine();
#endif
        }
 

из http://msdn.microsoft.com/en-us/library/system.accessviolationexception.aspx

Информация о версии

Это исключение является новым в .NET Framework версии 2.0. В более ранних версиях .NET Framework нарушение доступа в неуправляемом коде или небезопасном управляемом коде представлено исключением NullReferenceException в управляемом коде. Исключение NullReferenceException также возникает, когда разыменовывается ссылка на null в проверяемом управляемом коде, что не связано с повреждением данных, и нет способа отличить две ситуации в версиях 1.0 или 1.1.

Администраторы могут разрешить выбранным приложениям вернуться к поведению .NET Framework версии 1.1. Поместите следующую строку в раздел Element файла конфигурации для приложения:

Другое <legacyNullReferenceExceptionPolicy enabled = "1"/>