PRB: WBEM Class Operations Return WBEM_S_DUPLICATE_OBJECTS (189450)
The information in this article applies to:
- Microsoft Windows Management Instrumentation 1.0
This article was previously published under Q189450 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
| Modification Type: | Major | Last Reviewed: | 1/15/2000 |
|---|
| Keywords: | kbprb kbWBEM KB189450 |
|---|
|