| Previous | Next |
| SL_E_SFS_BAD_TOKEN_EXT | SL_E_SFS_TOKEN_SIZE_MISMATCH |
SL_E_SFS_DUPLICATE_TOKEN_NAME
Why this is more specific than an activation failure
The useful meaning of SL_E_SFS_DUPLICATE_TOKEN_NAME, value 0x8004E106, 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 two descriptor entries resolve to the same token name where the store requires uniqueness.
the first result diagnostic fork is precise: the conflict is duplicate identity, not merely two licenses for related products. That is why this result can require a different correction from the same visible activation banner.
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 identify both descriptor indexes, offsets, package origins and modification timestamps.
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.
Evidence worth preserving
| Item | Why it matters here |
|---|---|
| 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. |
| 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. |
Code-specific check: identify both descriptor indexes, offsets, package origins and modification timestamps.
A practical way to isolate the cause
- Start with the earliest event carrying this result; later status queries may only report the resulting unlicensed or notification state.
- tie the event to one Application ID/Activation ID, handle, namespace, token or crypto object rather than to the computer in general.
- use read-only inspection first: identify both descriptor indexes, offsets, package origins and modification timestamps.
- check whether the issue reproduces after normal service restart without altering signed store or policy data.
- After a supported repair for this HRESULT, query the same object and confirm that the original boundary no longer fails.
Comparison with neighboring results
| Result | Different condition |
|---|---|
SL_E_SFS_BAD_TOKEN_EXT | Compared with this result, a token record carries an unsupported or malformed extension/type suffix. |
SL_E_SFS_TOKEN_SIZE_MISMATCH | Compared with this result, the token’s declared length disagrees with the bytes available in its serialized extent. |
SL_E_SFS_BAD_TOKEN_NAME | Compared with it, a serialized token name violates the naming rules expected by the store index. |
A narrow remediation path
Remove the duplicate through supported package management or rebuild from the authoritative installed licenses. 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 failed upgrade migration imports the same token twice under one identifier.
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 “two descriptor entries resolve to the same token name where the store requires uniqueness” 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.