The exception that is thrown when there is an attempt to read or write protected memory.
Assembly: mscorlib (in mscorlib.dll)
Initializes a new instance of theclass with a system-supplied message that describes the error.
Initializes a new instance of theclass with serialized data.
Initializes a new instance of theclass with a specified message that describes the error.
Initializes a new instance of theclass with a specified error message and a reference to the inner exception that is the cause of this exception.
Gets a collection of key/value pairs that provide additional user-defined information about the exception.(Inherited from Exception.)
Gets or sets a link to the help file associated with this exception.(Inherited from Exception.)
Gets or sets HRESULT, a coded numerical value that is assigned to a specific exception.(Inherited from Exception.)
Gets a message that describes the current exception.(Inherited from Exception.)
Gets or sets the name of the application or the object that causes the error.(Inherited from Exception.)
Gets a string representation of the immediate frames on the call stack.(Inherited from Exception.)
Gets the method that throws the current exception.(Inherited from Exception.)
Determines whether the specified object is equal to the current object.(Inherited from Object.)
Allows an object to try to free resources and perform other cleanup operations before it is reclaimed by garbage collection.(Inherited from Object.)
Serves as the default hash function. (Inherited from Object.)
Gets the runtime type of the current instance.(Inherited from Exception.)
Creates and returns a string representation of the current exception.(Inherited from Exception.)
An access violation occurs in unmanaged or unsafe code when the code attempts to read or write to memory that has not been allocated, or to which it does not have access. This usually occurs because a pointer has a bad value. Not all reads or writes through bad pointers lead to access violations, so an access violation usually indicates that several reads or writes have occurred through bad pointers, and that memory might be corrupted. Thus, access violations almost always indicate serious programming errors. Anclearly identifies these serious errors.
In programs consisting entirely of verifiable managed code, all references are either valid or null, and access violations are impossible. Any operation that attempts to reference a null reference in verifiable code throws a NullReferenceException exception. An occurs only when verifiable managed code interacts with unmanaged code or with unsafe managed code.
Anexception can occur only in unsafe managed code or when verifiable managed code interacts with unmanaged code:
An access violation that occurs in unsafe managed code can be expressed as either a NullReferenceException exception or an exception, depending on the platform.
An access violation in unmanaged code that bubbles up to managed code is always wrapped in anexception.
In either case, you can identify and correct the cause of theexception as follows:
- Make sure that the memory that you are attempting to access has been allocated.
Anexception is always thrown by an attempt to access protected memory -- that is, to access memory that is not allocated or that is not owned by a process.
Automatic memory management is one of the services that the common language runtime provides. If managed code provides the same functionality as your unmanagede code, you may wish to move to managed code to take advantage of this functionality. For more information, see Automatic Memory Management.
- Make sure that the memory that you are attempting to access has not been corrupted.
If several read or write operations have occurred through bad pointers, memory may be corrupted. This typically occurs when reading or writing to addresses outside of a predefined buffer.
Starting with the .NET Framework 4, HandleProcessCorruptedStateExceptionsAttribute attribute to the method in which the exception is thrown. This change does not affect exceptions thrown by user code, which can continue to be caught by a catch statement. For code written for previous versions of the .NET Framework that you want to recompile and run without modification on the .NET Framework 4, you can add the <legacyCorruptedStateExceptionsPolicy> element to your app's configuration file. Note that you can also receive notification of the exceptions if you have defined a handler for the AppDomain.FirstChanceException or AppDomain.UnhandledException event.exceptions thrown by the common language runtime are not handled by the catch statement in a structured exception handler if the exception occurs outside of the memory reserved by the common language runtime. To handle such an exception, you should apply the
This exception is thrown in the .NET Framework 2.0 and later versions. In earlier versions of the .NET Framework, an access violation in unmanaged code or unsafe managed code is represented by a NullReferenceException in managed code. A NullReferenceException is also thrown when a null reference is dereferenced in verifiable managed code, an occurrence that does not involve data corruption, and there is no way to distinguish between the two situations in versions 1.0 or 1.1.
Administrators can allow selected applications to revert to the behavior of the .NET Framework version 1.1. Place the following line in the <runtime> Element section of the configuration file for the application:
<legacyNullReferenceExceptionPolicy enabled = "1"/>
Available since 2.0
Available since 2.0
Windows Phone Silverlight
Available since 7.0
Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.