Bug Report: Acrobat Reader installer disables inheritance and overwrites ACL on .pdf\PersistentHandler, removing required Windows capability SID → Windows 11 PDF full-text indexing breaks
Product / Component

Adobe Acrobat Reader (latest version as of Jan 2026)
Installer / Update / Repair actions affecting Windows Search integration and registry ACLs

OS / Environment

Windows 11 Pro (x64)

Windows Search indexing enabled and functioning correctly for other formats (e.g., .docx)

PDFs are text/OCR-enabled (text can be selected and copied)

Issue is reproducible on system A; system B (Windows 11, no prior Adobe install) indexes the same PDFs correctly

Summary

Installing (or repairing/updating) Adobe Acrobat Reader on Windows 11 Pro breaks Windows Explorer / Windows Search full-text indexing of PDF contents.

The failure is caused not only by registry value mappings, but by Acrobat modifying registry key permissions (security descriptor):

Acrobat disables permission inheritance on:

HKLM\SOFTWARE\Classes.pdf\PersistentHandler

Acrobat overwrites the ACL (DACL) to include only classic principals like:

SYSTEM, Administrators, Everyone

This process removes Windows default capability SID ACEs (notably a capability SID in the form S-1-15-3-…)

Windows Search’s SearchFilterHost.exe runs with that capability SID in its token (verified in Process Explorer as Group with flag “Capability”).

Once that SID is no longer granted ReadKey on the PersistentHandler registry key, SearchFilterHost.exe receives ACCESS DENIED and the PDF IFilter chain cannot be resolved/loaded.

Result: PDFs appear in the index (metadata indexed), but System.Search.Contents remains empty, and Explorer cannot find text inside PDFs.

Re-enabling inheritance (or restoring default ACL) immediately restores PDF full-text indexing.

Impact / Severity

High. Acrobat Reader installation can silently disable OS functionality:

Explorer / Start Menu search cannot find PDF content

Windows Search indexes PDF metadata only, not contents

Users may incorrectly assume PDF content indexing is broken or unreliable in Windows 11

Affects enterprise setups and forensic/search workflows heavily

Expected Behavior

After installing Acrobat Reader:

Windows Search / Explorer should continue to index PDF contents using the Windows built-in PDF filter (Windows.Data.Pdf.dll) or a compatible handler chain.

Acrobat should not modify registry key ACLs in a way that removes Windows-required capability SIDs.

PDF full-text search should continue working the same way as before installation.

Actual Behavior

After Acrobat Reader installation:

PDF contents are no longer searchable (while .docx continues working)

In the Windows Search index:

PDF file entries exist

System.Search.Contents is empty (no extracted text)

Process Monitor shows registry access failures:

SearchFilterHost.exe → RegOpenKey / RegQueryValue on .pdf\PersistentHandler results in ACCESS DENIED

Windows.Data.Pdf.dll is not loaded during PDF indexing attempts until permissions are fixed

Reproduction Steps (100% reproducible)
Baseline (works)

Ensure Windows Search is enabled, and the folder containing PDFs is indexed.

Confirm that a given PDF has selectable/copyable text (OCR or embedded).

Confirm PDF full-text search works:

Explorer search finds terms inside PDF content

In Windows Search index, System.Search.Contents contains extracted text (or at least non-empty)

Confirm handler chain is present:

HKCR.pdf\PersistentHandler default value is {1AA9BF05-9A97-48C1-BA28-D9DCE795E93C}

HKLM\SOFTWARE\Classes\CLSID{1AA9BF05-…}\PersistentAddinsRegistered{89BCB740-6119-101A-BCB7-00DD010655AF} points to:
{6C337B26-3E38-4F98-813B-FBA18BAB64F5}

{6C337B26-…}\InprocServer32 points to %SystemRoot%\System32\Windows.Data.Pdf.dll

Trigger (break indexing)

Install Adobe Acrobat Reader (latest version).

After install, check registry ACL of:

HKLM\SOFTWARE\Classes.pdf\PersistentHandler

Observe:

Inheritance disabled

DACL replaced/flattened with entries like:

SYSTEM

Administrators

Everyone

Missing capability SID entries (notably S-1-15-3-1024-… capability SID)

Observe failure

Copy a PDF into an indexed folder (or modify a PDF to trigger indexing).

Confirm:

Indexing occurs for metadata (System.ItemPathDisplay present in index)

But System.Search.Contents empty

Explorer cannot find content terms in the PDF

Evidence / Diagnostics
1) Registry key ACL change causes failure

User experiment:

When permissions on .pdf\PersistentHandler are set to inherit from parent .pdf, PDF content indexing works.

When inheritance is disabled and the capability SID ACE is removed, PDF indexing fails.

Adding back the capability SID (explicit allow ReadKey) or re-enabling inheritance restores indexing.

Minimal permission requirements observed:

SYSTEM + capability SID (S-1-15-3-…) required

Removing Users/Admins/CreatorOwner does not break indexing

Removing SYSTEM or the capability SID breaks indexing

2) Process token includes the capability SID (confirmed)

Using Process Explorer:

SearchFilterHost.exe → Properties → Security → Groups

The capability SID appears in Groups with Flag = “Capability”.

This demonstrates that Windows Search components rely on capability SIDs in access checks.

3) ProcMon shows access denied

In Process Monitor during PDF indexing attempt after Acrobat installation:

SearchFilterHost.exe

Registry open/query on .pdf\PersistentHandler yields ACCESS DENIED

Stack shows impersonation-related frames (e.g., kernel path mentions dereferencing impersonation token)

After fixing ACL inheritance, access succeeds and:

Windows.Data.Pdf.dll becomes visible/loaded in the indexing chain

PDF full-text indexing works again

4) Why SYSTEM alone is insufficient

Even when DACL includes SYSTEM FullControl, access can still fail due to Windows token restrictions / capability gating:

Access may require both:

standard SID authorization AND

capability / restricted SID set authorization

This matches observed behavior: SYSTEM alone does not restore indexing if capability SID ACE is missing.

Root Cause

The Acrobat Reader installer (or update/repair routine):

modifies security descriptors (ACLs) of the registry key HKLM\SOFTWARE\Classes.pdf\PersistentHandler

disables inheritance

rewrites DACL to contain only classic principals (SYSTEM/Admin/Everyone)

thereby removing default Windows capability SIDs such as S-1-15-3-1024-…

Windows Search indexing host (SearchFilterHost.exe) includes that SID with flag “Capability” and requires ReadKey

result: SearchFilterHost cannot read PersistentHandler → cannot resolve filter chain → cannot extract contents

This is a permissions regression introduced by Acrobat install behavior.

Workaround / Fix
Immediate workaround (manual)

Restore default Windows ACL by re-enabling inheritance:

regedit

Navigate to: HKLM\SOFTWARE\Classes.pdf\PersistentHandler

Permissions → Advanced

Enable inheritance

Apply

PDF full-text indexing resumes immediately after next indexing cycle.

Alternative workaround

If inheritance must remain disabled:

Add explicit allow ReadKey ACE for:

Capability SID: S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681

Ensure SYSTEM also retains ReadKey

Recommendation to Adobe Engineering

Do not modify security descriptors for .pdf\PersistentHandler unless absolutely necessary.

If ACL changes must be made:

preserve inherited ACEs (do not disable inheritance)

do not remove “unknown” SIDs (capability SIDs)

If Acrobat registers its own handler chain, it should do so by updating values, not rewriting registry permissions.

Add a regression test:

install Acrobat on clean Windows 11

ensure PDF System.Search.Contents extraction still works under Windows Search

verify capability SIDs remain present in ACLs

Additional Notes

On a second Windows 11 system (no prior Adobe install), PDF full-text indexing works correctly with the same PDF files.

The issue is independent of PDF content (OCR/text selection works; document is new and created from Word).

Microsoft documentation indicates capability SIDs are legitimate and commonly used; they should not be removed from ACLs.