| Previous | Next |
| ERROR_HANDLES_CLOSED | ERROR_RXACT_COMMIT_NECESSARY |
ERROR_EXTRANEOUS_INFORMATION
What ERROR_EXTRANEOUS_INFORMATION means
The security descriptor was understandable, but included ACL content that could not be represented or consumed exactly in the target context. Treat this as a warning about fidelity, not as permission to discard unknown access-control entries.
Where it appears
- security descriptor conversion or canonicalization
- copying ACLs between file systems or object types
- directory, registry, and management tools that simplify permissions
Likely causes
- object-specific or inherited ACE data unsupported by the destination
- ACL fields beyond what a legacy interface exposes
- conversion between security models with different capabilities
Evidence to collect
- original SDDL and binary security descriptor
- destination object type and file-system format
- ACE order, inheritance flags, object GUIDs, and trustee SIDs
- the exact transformed descriptor actually applied
How to respond
Compare the source and resulting ACL before accepting the operation. Preserve unsupported entries through a richer API where possible. Administrators should confirm effective access, especially when the transformed ACL may be more restrictive than intended.
Diagnostic interpretation
For this particular status, the decisive evidence is original SDDL and binary security descriptor, destination object type and file-system format. Those details separate the documented condition from unrelated failures that happen to occur nearby.
Record the numeric code together with the symbolic name ERROR_EXTRANEOUS_INFORMATION, the API or subsystem that produced it, and the first preceding failure. A later cleanup occurrence may describe a consequence instead of the initiating defect.
Example
A diagnostic trace records this result after an operation changes subsystem state. The result investigation should follow the first state-changing call, validate its resulting state, and classify later cleanup messages as secondary evidence.
Implementation guidance
Code handling this result should distinguish a terminal failure from a warning, progress indication, or request to repeat after a defined state change. When handling it, preserve handles and output fields only where the originating API explicitly keeps them valid. The path needs bounded retries and cleanup that tolerates partial initialization.
Validation after remediation
Repeat one controlled operation that previously produced this result. Verify both disappearance of the status and completion of the specific state transition described above. Adjacent messages around it must also be reviewed so a fallback is not mistaken for a complete repair.
References
Looking for a different code? Search another status or error code.