| Previous | Next |
| SL_E_SFS_INVALID_FILE_POSITION | SL_E_SFS_INVALID_FS_HEADER |
SL_E_SFS_NO_ACTIVE_TRANSACTION
Where the failure occurs in Software Protection Platform
The useful meaning of SL_E_SFS_NO_ACTIVE_TRANSACTION, value 0x8004E10C, is not simply “activation failed.” It comes from the serialized Token Store file format, where the low-level reader/writer that validates the Token Store container, descriptor table, token records and transaction state before licenses can be evaluated. The condition to investigate is a commit, rollback or mutation was requested without an active store transaction.
For triage, treat this result as a the serialized Token Store file format result. the file can be healthy; the error is about transaction lifetime. Product-key changes or network tests are useful only when it evidence points back to those layers.
A reproducible troubleshooting path
- Record this result,
0x8004E10C, the exact API or service operation, and the affected product or protected object. - capture the five state items above before restarting the service, rebuilding the store, repairing files or retrying activation.
- prove the specific condition: record the exact API sequence, transaction identifier, prior failure and whether service restart invalidated the context.
- compare the neighboring results below and identify which boundary is actually present.
- change one decisive precondition, repeat the original operation, and verify both the immediate HRESULT and durable license state.
Where it sits in the licensing pipeline
A structural Token Store error occurs before an individual product key can be accepted or rejected. The decisive proof for this HRESULT is to record the exact API sequence, transaction identifier, prior failure and whether service restart invalidated the context.
The documented Tokens.dat rebuild procedure is a recovery action, not the first evidence-gathering step; preserve the original error and licensing inventory first. Keep that product/object identity because the same service can expose several independent licensing instances.
Minimum data for a reliable diagnosis
| Item | Why it matters here |
|---|---|
| descriptor table and token offsets | Shows the state transition immediately before the HRESULT. |
| token name, extension, declared size and hash | Correlates service-level evidence with storage, crypto or policy evidence. |
| file-system result and Software Protection event | Reveals whether servicing, migration, restore, cloning or concurrent work changed the precondition. |
| Tokens.dat or the applicable licensing-store file | Identifies the protected object or product instance that returned the code. |
| store header and format version | Separates format/version failure from damage, absence or access failure. |
Code-specific check: record the exact API sequence, transaction identifier, prior failure and whether service restart invalidated the context.
A narrow remediation path
Restart the operation from transaction begin and ensure the same live context performs mutation and commit. Preserve the original store, event export, hashes and licensing inventory until the operation succeeds and the expected state survives any required restart.
Representative case: A retry path calls commit after an earlier exception already rolled the transaction back.
Adjacent states in the same subsystem
| Result | Different condition |
|---|---|
SL_E_SFS_INVALID_FILE_POSITION | Compared with this result, a store operation attempted to seek or access a position outside the valid container layout. |
SL_E_SFS_INVALID_FS_HEADER | Compared with this result, the Token Store container header fails structural validation. |
SL_E_SFS_FILE_WRITE_ERROR | Compared with it, the store writer could not persist a token or metadata update. |
Actions that usually destroy useful evidence
- do not editing or copying individual records inside the signed store.
- do not assuming a product-key change can repair a malformed container.
- While resolving it, do not use unofficial activation tools, patched binaries, copied stores, disabled integrity checks or hand-edited signed data; they can create a second tamper condition.
Verification after correction
Repeat the operation that originally produced it, not merely a UI refresh. Confirm the exact product/object completes, review LicenseStatus and LicenseStatusReason when applicable, and check that no related boundary replaces it.
Regression testing, retain one failing fixture that reproduces “a commit, rollback or mutation was requested without an active store transaction” and one passing fixture that changes only the decisive precondition; this avoids mistaking a broad reset for verification.
Technical references
- Rebuild the Tokens.dat file — official platform context used to interpret it.
- Software Licensing provider — supported state, API or recovery information relevant to it.
- SoftwareLicensingService WMI class — reference for this HRESULT evidence collection and post-repair verification.
- Slmgr.vbs options — technical contract for the subsystem producing it.
Looking for a different code? Search another status or error code.