It is important when utilizing custom WMI components to thoroughly scope the issue to define the symptoms and pieces so that the appropriate support organization can be engaged and provided the relevant information to begin troubleshooting the issue.
If an issue is found to be with a Microsoft supplied WMI component then support for it will be provided by Microsoft. However, if an issue is found to be with a custom WMI component then support for it will ultimately be the responsibility of the vendor. Note that Microsoft does not support the writing or troubleshooting of scripts. Scripts found within Microsoft documentation are provided as-is.
Scoping the Issue:
As mentioned previously, it is important to identify the components involved in the WMI issue. With this in mind, an attempt should be made to determine whether an issue is due to a problem with the client application or script that is utilizing WMI, WMI itself, or the WMI provider and/or the object being managed by WMI. Of these general pieces, the client application/script and/or a provider could be a custom component created by an individual or vendor.
If a custom client application/script is involved, then it will be important to be somewhat familiar with how the application or script is utilizing WMI. This may require the engagement of the vendor or developer of the application or script. For example it would be important to know what namespaces, classes and providers are being used. Once these are known then a different application or script should be tested that utilizes the same namespaces, classes and/or providers in the same way to note whether the symptom continues. If it does then the issue is likely not unique to the application/script. If it does not, then the issue may be unique to the specific application/script. For scenarios where the symptom is unique to the custom client application/script component then the vendor/developer should be engaged for further support.
When performing the application/script comparison tests, the WMI testing utility that comes with Windows (Wbemtest.exe) can be implemented to perform various queries and actions. New .VBS scripts can be utilized as well. The SCRIPTOMATIC scripting tool is another resource that may help with writing test scripts/queries:
If a custom client application or script is not involved, then another possibility could be a custom provider. As with a custom client component, it is important to be somewhat familiar with a custom WMI provider. Beneficial things to know would be what class or classes it makes available and under what namespace(s) it resides. Additionally it would be beneficial to know what properties and methods it provides.
When suspecting that an issue with a custom WMI provider component is occurring it will be important to identify whether that is true for just that one provider or others as well. The more obvious types of issues are those that involve failures obtaining data via WMI for specific target applications or objects that have their own WMI providers. For example, data failing to be accessed from IIS by its provider while other data is attainable via other WMI providers indicates a problem with the IIS provider and not WMI as a whole. Refer to the following templates for suggestions on narrowing the scope for provider related issues: