| Previous | Next |
| APPX_E_FILE_COMPRESSION_MISMATCH | NTE_BAD_UID |
BT_E_SPURIOUS_ACTIVATION
Treat spurious background-task activation as a contract result, not as justification for resetting unrelated state. Windows delivered a background activation that the task host could not correlate with a valid current registration, trigger, or pending work item. The useful boundary is the activation instance and registration generation, not the foreground application process.
The contract boundary
The declared return type and source header determine the relevant status namespace.
A task that starts and then fails is not spurious: it has a valid activation and a later execution failure. Likewise, a canceled task can still have a legitimate activation instance. Keep the numeric value, declared return type, and first returning operation together with BT_E_SPURIOUS_ACTIVATION; the same integer can belong to a different status namespace in another API.
Capture before changing state
| Capture | Diagnostic value |
|---|---|
| Task registration name and entry point, trigger type, task instance ID, and app package version. | Identifies the concrete object and operation associated with spurious background-task activation. |
| Registration creation/removal time and whether an update replaced the package between trigger and activation. | Separates argument or lifecycle state from a lower-layer provider failure. |
| Cancellation reason, trigger details, and the first event emitted by the background-task host. | Creates a stable before-and-after comparison. |
| Whether the handler called the deferral API and completed the same activation instance exactly once. | Shows whether this condition is the first result or a translated summary. |
Preserve task registration name and entry point, trigger type, task instance ID, and app package version before reinstalling, rebooting, clearing state, or substituting another device or provider. A success observed only after such a change is useful comparison data, but it does not identify the original cause.
Focused experiments
- Register one disposable task with a single trigger and record its instance ID through completion. Keep unrelated inputs fixed so the changed result remains attributable to the tested variable.
- Unregister and reregister the task while holding all trigger inputs constant, then compare the activation generation. Record the first returned status and any state transition observed.
- Disable duplicate scheduling in the caller and verify that only one host activation is observed. Treat a changed result as a new boundary rather than automatic resolution.
Adjacent outcomes
| Observed comparison | Next conclusion to test |
|---|---|
| The first control changes the result | Concentrate on the variable isolated by this check: Register one disposable task with a single trigger and record its instance ID through completion. |
| The second comparison reproduces the same first status | Preserve lower-layer provider, driver, service, or runtime evidence before editing application data. The second controlled check was: Unregister and reregister the task while holding all trigger inputs constant, then compare the activation generation. |
| A different status appears after the bounded change | The operation moved to another boundary after the third controlled check. That check was: Disable duplicate scheduling in the caller and verify that only one host activation is observed. Retain both results and interpret the replacement through its own API contract. |
A defensible resolution
Targeted correction. Reconcile registration lifetime with trigger lifetime, remove stale registrations during package update, and make the handler idempotent for duplicate delivery without silently accepting an uncorrelated activation. Modify only the object, argument, policy, provider, or lifecycle state identified by the collected evidence.
Acceptance criterion. The original trigger produces one traceable activation, the registration ID is current, and repeated package update or suspend/resume cycles do not create unowned task instances. Re-run the original operation that produced this condition under its original identity and supported configuration, then keep one negative control that still produces the expected neighboring outcome.
Technical references
References for BT_E_SPURIOUS_ACTIVATION on the deployed platform version.
- Microsoft Open Specifications: HRESULT values — defines the status namespace used.
- Microsoft: HRESULT facility extraction — documents the API or lifecycle boundary behind this condition.
- Microsoft: support your app with background tasks — provides ABI, implementation, or protocol context.
- Microsoft: IBackgroundTaskInstance — supports the portability and verification limits.
Looking for a different code? Search another status or error code.