| Previous | Next |
| STATUS_VERIFY_REQUIRED | STATUS_RXACT_COMMIT_NECESSARY |
STATUS_EXTRANEOUS_INFORMATION
Treat the ACL as a bounded binary structure, not a text permission list
STATUS_EXTRANEOUS_INFORMATION reports that an ACL carried more information than the consumer expected. An ACL starts with an ACL header containing AclSize and AceCount, followed by variable-size ACE records. Each ACE has its own ACE_HEADER and AceSize. A parser therefore has several independent boundaries to reconcile.
Microsoft documents ACLs as opaque structures that should normally be manipulated through access-control functions. IsValidAcl validates revision and checks that the ACE count fits within the ACL size, but a component can impose a narrower semantic layout for the operation it is performing. Extra bytes, an unexpected ACE layout, stale serialized data, or a version mismatch can all deserve investigation without assuming the ACL is globally invalid.
Preserve the exact byte buffer that triggered the status. Record AclRevision, AclSize, AceCount, and every AceType/AceSize while walking only within validated boundaries. Compare the producer and consumer structure definitions and serialization code. Do not trim trailing bytes until you know whether they are padding, a newer extension, or evidence that the producer calculated the ACL length incorrectly.
What to inspect
- Run
IsValidAcland then inspect operation-specific expectations separately. - Walk ACEs using their recorded sizes and stop at the declared ACL boundary.
- Compare the raw bytes across producer and consumer versions before normalizing or rebuilding the descriptor.
References
- Microsoft: ACL structure
- Microsoft: ACE_HEADER structure
- Microsoft: IsValidAcl
- Microsoft: Access control lists
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.