| Previous | Next |
| TYPE_E_INCONSISTENTPROPFUNCS | STG_E_INVALIDFUNCTION |
TYPE_E_CIRCULARTYPE
Circular dependency between type-library definitions
TYPE_E_CIRCULARTYPE is HRESULT 2147654788 (0x80029C84) from winerror.h. The documented description is “Circular dependency between types/modules.” The result belongs to resolution of aliases, records, interfaces, and imported type references. The important boundary is not merely failure but which object and state transition established: following the metadata references returns to a type that is still being defined without a permitted indirection boundary.
TYPE_E_CIRCULARTYPE means that following the metadata references returns to a type that is still being defined without a permitted indirection boundary.
Where the result appears
- This result can surface in a type-library compiler, importer, registration step, proxy generator, or Automation metadata consumer.
- Map the failure to one concrete operation among LoadTypeLib, RegisterTypeLib, ITypeInfo, ICreateTypeInfo, FUNCDESC, TYPEDESC, and imported LIBID versions.
- Preserve LIBID, type-library version, LCID, SYSKIND, TYPEKIND, GUID, MEMBERID, HREFTYPE, and the producer toolchain before releasing or replacing the object that returned this result.
An incident record must distinguish caller, runtime, provider, and backing resource while testing whether following the metadata references returns to a type that is still being defined without a permitted indirection boundary.
Typical causes and interpretation
The immediate contract boundary is specific: following the metadata references returns to a type that is still being defined without a permitted indirection boundary. Common cause branches include the following:
- Two aliases expand directly into one another.
- Records embed each other by value rather than through interfaces or pointers.
- Imported libraries form a version-dependent cycle.
Confirm the cause branch that explains why following the metadata references returns to a type that is still being defined without a permitted indirection boundary by using call arguments, object state, metadata, device information, or provider traces.
Correct handling and recovery
The primary recovery is to break the by-value cycle with a supported indirection or redesign the dependency graph, then rebuild every affected library. The failure report should capture the relevant state during resolution of aliases, records, interfaces, and imported type references so it is clear why following the metadata references returns to a type that is still being defined without a permitted indirection boundary.
Retry this result only when evidence shows the state behind “following the metadata references returns to a type that is still being defined without a permitted indirection boundary” can change and the operation is repeatable.
Practical scenario
Two records generated from a schema each embed the other as a field; replacing one field with an interface reference removes the impossible layout cycle.
Difference from related HRESULTs
It detects a reference cycle; TYPE_E_BADMODULEKIND instead rejects a module whose kind is unsuitable for the requested operation
Developer and administrator guidance
Use a minimal IDL or metadata fixture that reproduces the exact graph, then validate both 32-bit and 64-bit generated artifacts.
Administrators should repair the component owning resolution of aliases, records, interfaces, and imported type references as a versioned unit instead of copying arbitrary DLLs.
References
Looking for a different code? Search another status or error code.