Hello everyone,

The other day, I had a customer who implemented a decoupled WMI provider in her application. She was running two instances simultaneously and when calling a function of the WMI provider, one of the two instances would crash with the following error message:

Non-static method requires a target.

The process that crashed would always be the one that was started first.

 

What happened?

The error we were seeing originated from a System.Reflection.TargetException, which was thrown because a call to

mscorlib_ni!System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo, Boolean)

 

was made, providing null as the first parameter. This value was returned when looking up the value id=a5f6c650-836b-4597-8831-11b8a80c310e in a hashtable that is unique to each instance.

I checked the customer’s code and saw that she registered a ManagementKey "id" and assigned a Guid to it. The values that assigned during this particular run were:

  • b3d731d4-a5c4-4184-87b4-e2ac35ee1c54 for the instance that was launched first
  • a5f6c650-836b-4597-8831-11b8a80c310e for the second one

WMI was trying to look up the WMI provider in the first instance, using the management key registered by the second instance.

 

Why it happened

Long story short: The behavior of having two decoupled providers of the same class running simultaneously is not well defined in .NET and therefore this scenario is not supported.

The WMI core tries to aggregate the instances coming from the same class. The WMI Provider Subsystem will forward the request to the both instances, which results in one instance returning successfully while the other one will fail.

 

Conclusion

WMI was not designed to implement distributed, per-instance "health check"-like mechanisms. Rather, there should be one single provider which is responsible for probing each instance.

 

I hope this proved helpful to you.

Cheers,

Helge Mahrt