CLR SPY and Customer Debug Probes: The Invalid IUnknown and Invalid VARIANT Probes

Whereas probes like Collected Delegate or Object Not Kept Alive catch coding mistakes in managed code, the Invalid IUnknown and Invalid VARIANT probes typically inform you when you're attempting to interoperate with a broken COM component.  Either that, or the metadata you've got for the unmanaged API doesn't match reality.

Whenever wrapping a COM interface pointer in a Runtime-Callable Wrapper (RCW), the Invalid IUnknown probe (if enabled) makes the CLR check that the input pointer points to a valid COM interface.  To determine that an interface pointer is valid, the CLR ensures that IUnknown::QueryInterface (the first slot in the vtable) returns S_OK when asked for IID_IUnknown.  Otherwise, it reports the following:

  Invalid IUnknown pointer detected.

If the pointer in question isn't even close to being a COM interface pointer, chances are that the CLR would terminate with an ExecutionEngineException before this error message would get a chance to be displayed.

Similar to the Invalid IUnknown probe, the Invalid VARIANT probe raises an error when attempting to marshal a VARIANT to a System.Object, but the input VARIANT is invalid.  To determine if a VARIANT is valid, the CLR calls the OLE Automation VariantCopy API, passing the VARIANT in question as the source to be copied.  If the function returns S_OK, then the CLR assumes it is valid.  Otherwise, it assumes that it's invalid and produces the following message:

  Invalid VARIANT detected.


So these probes aren't nearly as interesting as the others, but if you run into these situations with these probes enabled, they should help you pinpoint the problem.  Both of these probes are "error probes," so they can provoke a debug break when their messages are emitted.

Comments (6)
  1. Stephane Rodriguez says:

    I’d like to know what’s your take on security access regarding that use DllImport attributes. Since managed code does not know the actual purpose of the unmanaged library it loads and calls a exposed function from, how can one stop somebody from DllImporting a virus ware. In other terms, isn’t there any threat when the application is hosted inside a web browser ?

  2. Adam Nathan says:

    Using DllImport requires that the code has been granted unmanaged code permission, and untrusted code running in the Internet (or Intranet) zone does not have this permission by default. This is for exactly the reason you state – unmanaged code cannot be tracked by the CLR’s security system.

  3. Introduction When it comes interop, .NET has solved most of the hard problems. However, if you’ve worked

  4. Introduction When it comes interop, .NET has solved most of the hard problems. However, if you’ve worked

Comments are closed.

Skip to main content