PRB: WBEM Class Operations Return WBEM_S_DUPLICATE_OBJECTS

ID: Q189450

The information in this article applies to:

SYMPTOMS

During WBEM class operations (including, but not limited to, IWbemServices::CreateClassEnum and IWbemServices::GetObject) you might get a return code of WBEM_S_DUPLICATE_OBJECTS. The class object returned from these methods might or might not match the class definition you expect.

CAUSE

The nature of WBEM includes the possibility that two class definitions might exist at the same time and might conflict with each other (for example, two class providers providing conflicting subclass definitions). The WBEM engine, CIMOM, cannot determine which class definition is "correct." As a result, CIMOM returns the first class definition it encounters along with the return code WBEM_S_DUPLICATE_OBJECTS.

NOTE: When you receive an HRESULT from a WBEM interface (or any COM interface) you should use the SUCCEEDED or FAILED macros to determine whether the call was successful. If you check the returned HRESULT against WBEM_NO_ERROR (or S_OK, or 0) the comparison might fail even though the call was ultimately successful. The SUCCEEDED macro will return TRUE for the error code WBEM_S_DUPLICATE_OBJECTS.

RESOLUTION

CIMOM logs an event to the Windows NT Event Log (or the CIMOM.log file under Windows 9x platforms). The event has a form similar to the following, where %1 is a class name: 

   Several providers and/or the static database returned definitions for
   class "%1". Only one definition was reported. Until this
   misconfiguration is corrected, clients may receive incorrect class
   definition for "%1".
The resolution depends completely upon the call that returns the WBEM_S_DUPLICATE_OBJECTS code and the class named in the event log. To find the source of the conflict, you should check the inheritance tree of the problem class. You can also look for class definitions that derive from the same superclass, but attempt to define the same objects. Lastly, you can try removing any extraneous class providers from the namespace that is the source of the error.

STATUS

This behavior is by design.

MORE INFORMATION

You will rarely encounter this problem during development and testing because this problem depends largely upon the configuration of a particular WBEM machine (that is, which schema and providers are installed, and so forth).

To avoid this problem when designing your schema or providers, you should give serious consideration to placing your schema in its own namespace, so other schema and providers will not conflict with your work.

REFERENCES

Architectural Overview: WBEM SDK Documentation

Additional query words: zodiac CIMOM 

Keywords          : kbWBEM 
Issue type        : kbprb

Last Reviewed: July 15, 1998