Are SafeHandle and derived types always safe?

[harborsiem]

I found an interesting expression in the book from Jeffrey Richter (CLR via CSharp, 4th edition, page 528).
See following code and text from the book:

using System;  
using System.Runtime.InteropServices;  
using Microsoft.Win32.SafeHandles;
  
internal static class SomeType {  
   [DllImport("Kernel32", CharSet=CharSet.Unicode, EntryPoint="CreateEvent")]  
   // This prototype is not robust  
   private static extern IntPtr CreateEventBad( 
      IntPtr pSecurityAttributes, Boolean manualReset, Boolean initialState, String name);  

   // This prototype is robust  
   [DllImport("Kernel32", CharSet=CharSet.Unicode, EntryPoint="CreateEvent")]  
   private static extern SafeWaitHandle CreateEventGood( 
      IntPtr pSecurityAttributes, Boolean manualReset, Boolean initialState, String name);  

   public static void SomeMethod() {  
      IntPtr   
      handle = CreateEventBad(IntPtr.Zero, false, false, null);  
      SafeWaitHandle swh  = CreateEventGood(IntPtr.Zero, false, false, null); 
   }  
} 

You’ll notice that the CreateEventBad method is prototyped as returning an IntPtr, which will
return the handle back to managed code; however, interoperating with native code this way is not
robust. You see, after CreateEventBad is called (which creates the native event resource), it is possible
that a ThreadAbortException could be thrown prior to the handle being assigned to the handle
variable. In the rare cases when this would happen, the managed code would leak the native resource.
The only way to get the event closed is to terminate the whole process.

The SafeHandle class fixes this potential resource leak. Notice that the CreateEventGood method
is prototyped as returning a SafeWaitHandle (instead of an IntPtr). When CreateEventGood is
called, the CLR calls the Win32 CreateEvent function. As the CreateEvent function returns to
managed code, the CLR knows that SafeWaitHandle is derived from SafeHandle, causing the CLR to
automatically construct an instance of the SafeWaitHandle class on the managed heap, passing in
the handle value returned from CreateEvent. The constructing of the SafeWaitHandle object and
the assignment of the handle happen in native code now, which cannot be interrupted by a
ThreadAbortException. Now, it is impossible for managed code to leak this native resource.
Eventually, the SafeWaitHandle object will be garbage collected and its Finalize method will be
called, ensuring that the resource is released.

My comment:
When I take a look to the construction what CsWin32 does, it looks more like a CreateEventBad (see code below).
So the user of these functions have to pay attention in multi threaded applications to have no leak in the native resource if there is a ThreadAbortException. (Calling the function with lock statement ?)

What can CsWin32 do better ? Can the fixed statement do the job that an other thread is blocked at this time ?

		[OverloadResolutionPriority(1)]
		internal static unsafe Microsoft.Win32.SafeHandles.SafeFileHandle CreateEvent(winmdroot.Security.SECURITY_ATTRIBUTES? lpEventAttributes, winmdroot.Foundation.BOOL bManualReset, winmdroot.Foundation.BOOL bInitialState, string lpName)
		{
			fixed (char* lpNameLocal = lpName)
			{
				winmdroot.Security.SECURITY_ATTRIBUTES lpEventAttributesLocal = lpEventAttributes ?? default(winmdroot.Security.SECURITY_ATTRIBUTES);
				winmdroot.Foundation.HANDLE __result = PInvoke.CreateEvent(lpEventAttributes.HasValue ? &lpEventAttributesLocal : null, bManualReset, bInitialState, lpNameLocal);
				return new Microsoft.Win32.SafeHandles.SafeFileHandle(__result, ownsHandle: true);
			}
		}

		[DllImport("KERNEL32.dll", ExactSpelling = true, EntryPoint = "CreateEventW", SetLastError = true),DefaultDllImportSearchPaths(DllImportSearchPath.System32)]
		[SupportedOSPlatform("windows5.1.2600")]
		internal static extern unsafe winmdroot.Foundation.HANDLE CreateEvent([Optional] winmdroot.Security.SECURITY_ATTRIBUTES* lpEventAttributes, winmdroot.Foundation.BOOL bManualReset, winmdroot.Foundation.BOOL bInitialState, winmdroot.Foundation.PCWSTR lpName);