Violation Exception Class
Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
The exception that is thrown when there is an attempt to read or write protected memory.
public ref class AccessViolationException : SystemException
public class AccessViolationException : SystemException
[System.Runtime.InteropServices.ComVisible(true)] [System.Serializable] public class AccessViolationException : SystemException
type AccessViolationException = class inherit SystemException
[<System.Runtime.InteropServices.ComVisible(true)>] [<System.Serializable>] type AccessViolationException = class inherit SystemException
Public Class AccessViolationException Inherits SystemException
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. An AccessViolationException clearly 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 AccessViolationException occurs only when verifiable managed code interacts with unmanaged code or with unsafe managed code.
Troubleshooting AccessViolationException exceptions
An AccessViolationException exception can occur only in unsafe managed code or when verifiable managed code interacts with unmanaged code:
An access violation in unmanaged code that bubbles up to managed code is always wrapped in an AccessViolationException exception.
In either case, you can identify and correct the cause of the AccessViolationException exception as follows:
Make sure that the memory that you are attempting to access has been allocated. An AccessViolationException exception 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 unmanaged 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.
AccessViolationException and try/catch blocks
Starting with .NET Framework 4, AccessViolationException 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 AccessViolationException exception, apply the HandleProcessCorruptedStateExceptionsAttribute attribute to the method in which the exception is thrown. This change does not affect AccessViolationException exceptions thrown by user code, which can continue to be caught by a
catch statement. For code written for previous versions of .NET Framework that you want to recompile and run without modification on .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.
This exception is thrown on .NET Framework 2.0 and later versions. In earlier versions of .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 .NET Framework version 1.1. Place the following line in the <runtime> Element section of the configuration file for the application:
<legacyNullReferenceExceptionPolicy enabled = "1"/>
Initializes a new instance of the AccessViolationException class with a system-supplied message that describes the error.
Initializes a new instance of the AccessViolationException class with serialized data.
Initializes a new instance of the AccessViolationException class with a specified message that describes the error.
Initializes a new instance of the AccessViolationException class 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 the Exception instance that caused the current 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)
When overridden in a derived class, returns the Exception that is the root cause of one or more subsequent exceptions.(Inherited from Exception)
Serves as the default hash function.(Inherited from Object)
When overridden in a derived class, sets the SerializationInfo with information about the exception.(Inherited from Exception)
Gets the runtime type of the current instance.(Inherited from Exception)
Creates a shallow copy of the current Object.(Inherited from Object)
Creates and returns a string representation of the current exception.(Inherited from Exception)
Occurs when an exception is serialized to create an exception state object that contains serialized data about the exception.(Inherited from Exception)