There’s a subtle but important difference between protected access in unmanaged C++ and protected access (i.e. family) in the CLR. The difference is due to the CLR’s ability to build security guarantees on top of type safety.
Post by this author
One way you get this exception is if unmanaged code does an OS RaiseException() or causes a fault. If that exception is propagated up the stack to managed code, we will try to map it to a managed exception. For example,
We don’t expose the managed size of objects because we want to reserve the ability to change the way we lay these things out. For example, on some systems we might align and pack differently. For this to happen, you need to specify tdAutoLayout for the layout mask of your ValueType or Class.
People often ask how they can expose traditional DLL exports from managed assemblies. Managed C++ makes it very easy to export functions. And you could use tricks like ILDASM / ILASM to inject DLL exports into managed assemblies built with other languages like C#.
If the operating system schedules multiple threads against a hyper-threaded CPU, the CLR automatically takes advantage of this. This is certainly the case for new versions of the OS like Windows Server 2003. Also, the CLR did work to properly spin on a hyper threaded system.
#define BOOTUP_EXCEPTION_COMPLUS 0xC0020001
You may see an exception with this code, or an HRESULT of this value, when trying to call into managed code. This can happen if you call in before the runtime has finished initializing, or after the runtime has started shutting down.
By default, static fields are scoped to AppDomains. In other words, each AppDomain gets its own copy of all the static fields for the types that are loaded into that AppDomain. This is independent of whether the code was loaded as domain-neutral or not.