Environment
- Illustrator 29.6.1 (x64), Windows Server (EC2), 11 machines in a print-automation pipeline
- Illustrator is driven via COM/ExtendScript (headless typesetting), hundreds of short sessions per day
- No local changes on any machine: last Windows update Dec 2025, no reboots since Jun 25, no font/plugin/preference changes, Illustrator binary unchanged since Jul 2025

Symptoms
- Starting the evening of Aug 17, 2026 (KST), Illustrator began crashing on all machines simultaneously. Daily crash counts across the fleet: ~0–5 (baseline) → 34 (Aug 17) → 90 (Aug 18) → 366 in half a day (Aug 19).
- Crashes occur regardless of document content (plain JPG/PNG/PDF inputs, different files every time), typically ~30 seconds after the Illustrator process starts (crsessionduration=30 in the Adobe crash report), i.e. right when telemetry upload kicks in — not tied to any specific operation.
- Two visible failure modes, both consistent with the process dying mid-flight:
- The remote procedure call failed returned to our COM automation while a script is running
- Server execution failed (0x80080005) when the process dies during startup, before COM registration completes
- Windows Event 1000 entries show faulting module ntdll.dll, exception 0xc0000374 (heap corruption).

Crash signature (from Adobe Crash Reporter XML)

RaiseException
 <- CxxThrowException (0xe06d7363, unhandled C++ exception)
 <- std::_Xbad_function_call
 <- dunamis_http_onResponseHeaders   (dunamis-ingest.dll 1.47.2.0)
 <- dunamis_http_onResponseHeaders
 <- wininet
 <- ntdll thread pool

An empty std::function is being invoked inside dunamis-ingest.dll's HTTP response-headers callback on a WinINet worker thread. The heap-corruption (0xc0000374) buckets appear to be the same defect surfacing differently (use of a freed callback object instead of an empty one).

Why we believe the trigger is server-side
- dunamis-ingest.dll 1.47.2.0 has been on these machines for a long time; the crashes started on all machines at the same time with zero local changes.
- The endpoint hard-coded in the DLL is cc-api-data.adobe.io (verified by string extraction from the binary).
- Workaround that stops the crashes: blocking cc-api-data.adobe.io (plus crs.cr.adobe.com / log.cr.adobe.com / crlog-crcn.adobe.com) via the hosts file → 127.0.0.1. With the connection refused immediately, the response callback never fires and the crashes stop on blocked machines while unblocked machines keep crashing.
- Account-level usage-data opt-out is only a partial mitigation (it appears to stop auth events but not anonymous events), consistent with what was reported for Lightroom (below).

Likely related report
The Lightroom thread "Lightroom Desktop on macOS freezes & crashes at launch and export" documents a defect in the same GrowthSDK/Dunamis ingest client (uncontrolled retry loop against cc-api-data.adobe.io/ingest, fixed or mitigated in Lightroom 9.5). This Illustrator crash looks like another defect in the same ingest client's response handling, triggered by whatever changed on the ingest service around Aug 17.

Ruled out
Windows updates, WebView2 runtime updates (module not even loaded in the 30-second sessions), CCXProcess version (machines on different versions crash identically), third-party plugins/DLLs (WER module list contains only standard modules), document content (inputs are ordinary files, never the same one twice).

Ask
1. Please check what changed on the cc-api-data.adobe.io ingest service around Aug 17, 2026 — response shape/headers appear to drive an empty-function-call in dunamis-ingest.dll 1.47.2.0's onResponseHeaders path.
2. Please fix the client to tolerate this (null-check the callback / handle error responses), as blocking a telemetry endpoint at the hosts level shouldn't be required to keep Illustrator alive.

I can provide the full Adobe Crash Reporter XML, WER reports, and Event Log extracts on request.