CA2006: Use SafeHandle to encapsulate native resources
Applies to: 
Visual Studio 
Visual Studio for Mac
Note
This article applies to Visual Studio 2017. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to the latest version of Visual Studio. Download it here
| Item | Value |
|---|---|
| RuleId | CA2006 |
| Category | Microsoft.Reliability |
| Breaking change | Non-breaking |
Cause
Managed code uses IntPtr to access native resources.
Rule description
Use of IntPtr in managed code might indicate a potential security and reliability problem. All uses of IntPtr must be reviewed to determine whether the use of a SafeHandle , or a similar technology, is required in its place. Problems will occur if the IntPtr represents some native resource, such as memory, a file handle, or a socket, that the managed code is considered to own. If the managed code owns the resource, it must also release the native resources associated with it, because a failure to do so would cause resource leakage.
In such scenarios, security or reliability problems will also exist if multithreaded access is allowed to the IntPtr and a way of releasing the resource that is represented by the IntPtr is provided. These problems involve recycling of the IntPtr value on resource release while simultaneous use of the resource is being made on another thread. This can cause race conditions where one thread can read or write data that is associated with the wrong resource. For example, if your type stores an OS handle as an IntPtr and allows users to call both Close and any other method that uses that handle simultaneously and without some kind of synchronization, your code has a handle recycling problem.
This handle recycling problem can cause data corruption and, frequently, a security vulnerability. SafeHandle and its sibling class CriticalHandle provide a mechanism to encapsulate a native handle to a resource so that such threading problems can be avoided. Additionally, you can use SafeHandle and its sibling class CriticalHandle for other threading issues, for example, to carefully control the lifetime of managed objects that contain a copy of the native handle over calls to native methods. In this situation, you can often remove calls to GC.KeepAlive. The performance overhead that you incur when you use SafeHandle and, to a lesser degree, CriticalHandle, can frequently be reduced through careful design.
How to fix violations
Convert IntPtr usage to SafeHandle to safely manage access to native resources. See the SafeHandle reference article for examples.
When to suppress warnings
Do not suppress this warning.