ENVIRONMENT
Adobe Acrobat (64-bit) 26.002.21900, running in Reader mode. Windows 11 Pro, build 10.0.26200. Same behaviour on 26.001.21789, so the September update did not change it.

STEPS TO REPRODUCE (100% reproducible)
1. Make sure no Acrobat process is running.
2. Start Acrobat.exe, with or without a document.
3. After about 9 seconds the child processes --type=compute-only-broker and --type=compute-only-renderer are spawned (--channeltype=7 /n /prefetch:7 /CR).
4. After about 19 seconds the renderer raises an unhandled exception and Windows shows a hard error dialog.
5. Acrobat spawns the worker a second time; in several runs the whole application then exited.

Opening a PDF into an already running instance does NOT trigger it, because the document is handed to the existing process. Users experience this as a crash when opening a PDF attachment from an email client, because each of those is a cold start.

EXPECTED RESULT
Acrobat starts without a crash dialog.

OBSERVED RESULT
Hard error dialog with exception 0xC06D007E (VcppException ERRORMODNOTFOUND, raised by the Visual C++ delay-load helper) in KERNELBASE!RaiseException. Hard error status 0xD0000144; the lower word is STATUSUNHANDLED_EXCEPTION. Because this is a csrss hard error it produces no Application event log entry and no Windows Error Reporting report, which makes it invisible to normal diagnostics.

DIAGNOSIS
The failing thread was inspected while still suspended in NtRaiseHardError. Its stack holds exactly one pointer to a DLL name string: AdobeXMP.dll, consistent with DelayLoadInfo.szDll passed to the delay-load failure hook. Non-system modules loaded in the failing process: Acrobat.dll, AGM.dll, BIB.dll, CoolType.dll, ACE.dll, thorvg-1.dll. AdobeXMP.dll is not among them, while the sibling --type=renderer process has it loaded from the Acrobat program directory at the same moment.

RULED OUT, WITH EVIDENCE
- File integrity: AdobeXMP.dll is 64-bit, file version 9.1.1.53142; LoadLibraryW with the full path succeeds from a normal process; all 14 imports resolve; the file has no delay imports of its own.
- DLL search path: the Acrobat program directory is the first PATH entry in the process environment, read directly from the running process PEB. Adding it a second time changed nothing.
- File permissions: AdobeXMP.dll carries the same ALL APPLICATION PACKAGES ACE as CoolType.dll, AGM.dll, BIB.dll, ACE.dll, Acrobat.dll and thorvg-1.dll, all of which the same process loads successfully.
- Generative AI settings: setting ConversationalAcrobat and KnowledgeWorkspace flags to 0 had no effect on the spawn or the crash.
- Repair installation: msiexec /fa completed with exit code 0 and rewrote the program files including AdobeXMP.dll. The next cold start produced the identical crash.

REMAINING HYPOTHESIS
The DLL search configuration of the sandboxed compute-only child itself, for example SetDefaultDllDirectories(LOADLIBRARYSEARCHSYSTEM32) or an equivalent lockdown that prevents a bare-name delay-load from resolving a DLL located in the application directory. A load by name reproduces ERRORMODNOTFOUND exactly under that condition, while a load by full path succeeds.

Minidumps of the failing process, taken while the thread was still suspended, are available on request.