What does HRESULT 0x80270220 (FA_E_MAX_PERSISTED_ITEMS_REACHED) mean?

 
Previous Next
NAP_E_SHV_TIMEOUT FA_E_HOMEGROUP_NOT_AVAILABLE

FA_E_MAX_PERSISTED_ITEMS_REACHED

The persisted file-access list has reached its capacity

FA_E_MAX_PERSISTED_ITEMS_REACHED is HRESULT 0x80270220 (signed decimal -2144927200, unsigned decimal 2150040096). AllStat, using winerror.h, describes it as “The maximum number of items for the access list has been reached. An item must be removed before another item is added.” The value has failure severity, facility 0x27, and code field 0x0220.

What limit was reached

This result is associated with a persisted storage-item access list, most commonly the Windows.Storage.AccessCache.StorageApplicationPermissions.FutureAccessList used by packaged Windows applications. A picker, activation, or drag-and-drop operation can grant temporary access to a file or folder; adding the returned StorageFile or StorageFolder to the future-access list preserves that permission for a later app session. The list is finite and is maintained by the application, not as an unlimited document history.

Current Microsoft documentation states that the future-access list can hold up to 1000 items and that the platform does not evict entries automatically. Code should still query MaximumItemsAllowed instead of assuming a constant, because the relevant list and platform contract should be visible in telemetry. Reaching this HRESULT means the attempted persistence failed; it does not mean the user-selected file is corrupt or that the current picker grant has necessarily vanished immediately.

Typical causes

  • The app adds every selected file with a new token but never removes entries for documents the user no longer needs.
  • A multi-select picker or import workflow tries to persist hundreds of individual files in one operation and crosses the remaining capacity.
  • The same file is added repeatedly under different tokens instead of replacing the existing logical entry.
  • The app uses FutureAccessList as a general recent-files database even though most entries do not require retained brokered access.
  • A folder could have represented the required access scope, but the implementation stores a separate entry for every child file.
  • Upgrade or migration logic reimports tokens without reconciling them with the entries already stored for the package identity.

Evidence to collect

  • Record whether the failing object is FutureAccessList, an MRU list, or a framework abstraction that uses one of them internally.
  • Log Entries.Size, MaximumItemsAllowed, the number of items requested by the current operation, and whether each item is a file or folder.
  • Capture the logical-document identifier and token-management action—add, replace, remove, or retrieve—without writing sensitive full paths to ordinary telemetry.
  • Note the package identity, application version, picker or activation path, and whether the failure appeared after an upgrade or a large batch selection.
  • Measure how many entries can no longer be resolved, how many refer to duplicate logical items, and how many have not been used within the product’s retention window.

Diagnostic sequence

  • Inspect the access list before calling Add; compare its current count with the runtime-reported maximum and the size of the pending batch.
  • Enumerate tokens and app metadata to identify stale records, duplicates, abandoned imports, and entries whose corresponding feature was removed.
  • Verify that a stable logical item uses a stable token with AddOrReplace when replacement semantics are intended.
  • Remove only entries the application can prove are no longer needed. Do not clear the entire list as a routine response, because that revokes retained access for unrelated user documents.
  • For large folder-oriented workflows, determine whether retaining the selected folder is sufficient instead of persisting each descendant separately.
  • For desktop applications with ordinary file-system access, verify whether the framework is adding items to the list unnecessarily; do not remove access-list use from sandboxed paths that still depend on the picker grant.

What this HRESULT does not establish

The code does not say that disk space is exhausted, that the target file is too large, or that the user denied access. It also does not identify which entry should be removed. The limit concerns records in the brokered access list, not the number of files in the selected folder and not the capacity of the storage device.

Retry and recovery

Repeating the same Add while the list remains full will fail again. A safe retry requires freeing a slot, replacing an existing token rather than creating another, reducing the batch, or choosing a broader folder entry that accurately represents the required permission. The application should make pruning deterministic: define retention rules, protect pinned entries, remove obsolete tokens during normal maintenance, and leave enough headroom for atomic user operations.

If a batch partly succeeded before the HRESULT was returned, preserve the tokens already created and report the exact subset that was not persisted. Blindly replaying the whole batch can generate more duplicates. Retrieval of an existing token should be tested separately from adding a new one; a full list does not by itself invalidate existing entries.

Practical scenario

A photo application adds every image selected over several years to FutureAccessList. A user later chooses a folder containing 200 more images, and the picker wrapper persists each file separately until the list reaches its maximum. The next addition returns FA_E_MAX_PERSISTED_ITEMS_REACHED. The durable fix is to retain the folder when that permission model is appropriate and prune obsolete per-file tokens, not to retry the import or delete arbitrary recent documents.

References

Looking for a different code? Search another status or error code.