What does HRESULT 0x80220018 (WCM_E_NOTIFICATIONNOTFOUND) mean?

WCM_E_NOTIFICATIONNOTFOUND

WCM_E_NOTIFICATIONNOTFOUND is the failure HRESULT 0x80220018 (signed decimal -2145255400, unsigned decimal 2149711896). Its severity bit is 1, facility is 34 (FACILITY_STATE_MANAGEMENT), and the facility-specific code field is 0x0018.

AllStat records the Windows SDK description as “No matching Notification found.”

Meaning in Settings Management Infrastructure

The requested notification registration does not exist. The operation reached lookup or removal of a notification subscription associated with settings changes. The first branch to test is whether the notification was never registered in this engine/context; keep that separate from the possibility that cleanup already removed it.

Point of failure

At this boundary, capture notification identifier and owning namespace, then correlate it with registration/removal timeline with thread IDs. Assign ownership only after checking engine/context lifetime and target changes.

Causes to test independently

• the notification was never registered in this engine/context
• cleanup already removed it
• the identifier belongs to another namespace or target
• a lifecycle reset invalidated caller-held notification state

Data to collect

• notification identifier and owning namespace
• registration/removal timeline with thread IDs
• engine/context lifetime and target changes
• whether duplicate cleanup paths run
• current notification inventory if exposed by the owning workflow

Step-by-step diagnosis

• make registration ownership explicit
• remove each notification exactly once
• invalidate caller-side handles when the engine or namespace is recreated
• serialize shutdown and callback cleanup
• treat absent notification as idempotent cleanup only when no active subscription is required

Recovery strategy

Retrying the same lookup cannot restore a deleted registration. Re-register when continued notification delivery is required.

What this value does not mean

WCM_E_STATENODENOTFOUND concerns a settings-tree item; NOTIFICATIONNOTFOUND concerns subscription state rather than configuration data.

Illustrative scenario

A shutdown path unregisters a notification, then a second object destructor repeats the cleanup using the stale identifier.

Implementation guidance

For operational telemetry, retain engine/context lifetime and target changes; also record whether duplicate cleanup paths run. Preserve a redacted summary of current notification inventory if exposed by the owning workflow; use a cryptographic hash when that evidence is a file, stream, or generated artifact.

Subscription ownership check

Keep the registration identifier with the object that created it and clear that identifier immediately after successful removal. This prevents two independent cleanup paths from claiming the same notification.

Official Microsoft references.

• Microsoft: SMI error and success constants.
• Microsoft: Settings Management Infrastructure API.
• Microsoft: SMI interfaces.
• Microsoft: ISettingsEngine::GetNamespace.
• Microsoft: ISettingsContext::Deserialize.

Looking for a different code? Search another status or error code.