Acrobat Processes hanging in Task Manager

Additional technical findings from our investigation

I wanted to provide significantly more detail in case this reaches Adobe engineering. We were able to capture the affected workstation while the problem was actively occurring rather than after Acrobat had already been terminated.

ENVIRONMENT / SYMPTOMS

- Adobe Acrobat 64-bit
- Version at time of capture: 26.001.21789
- Windows 11 Enterprise, build 26100 family
- Issue is intermittent and has affected several users in our environment.
- Users open/close a large number of PDFs throughout the workday.
- In this case the PDFs involved were being opened from a mapped network drive (S:).
- This has not yet been proven to be network-share-specific, but both document launches captured during this occurrence were from S:.
- Eventually PDFs stop opening normally.
- Additional Acrobat.exe processes begin appearing.
- The user receives:

  "A running instance of Acrobat has caused an error."

- Killing all Acrobat.exe processes in Task Manager immediately restores functionality.
- The problem eventually returns.

DUMP COLLECTION

While the workstation was in the broken state, we used Sysinternals ProcDump to manually capture full-memory dumps of every Acrobat.exe process that was still present.

Example:

procdump64.exe -accepteula -ma <PID> <dumpfile>

This resulted in multiple dumps, including three Acrobat.exe parent/UI processes.

PROCESS TIMELINE

The most interesting process was:

PID 28924
Started: approximately 09:17:30
Dump captured: approximately 11:42:33
Process uptime at capture: 2h 25m 03s

Its original command line was essentially:

Acrobat.exe "S:\...\<PDF>.pdf"

This appears to be the long-lived Acrobat instance that existed before the failure condition became obvious.

Later, while Acrobat was already in the broken state:

PID 29864
Started: approximately 11:39:19
Uptime when captured: approximately 3m 18s
Command line:

Acrobat.exe "S:\...\<another PDF>.pdf"

PID 28928
Started: approximately 11:41:40
Uptime when captured: approximately 55 seconds
Command line:

Acrobat.exe

(no PDF argument)

I suspect the two newer processes may correspond to failed Acrobat launch / error-dialog instances rather than separate healthy Acrobat sessions.

When the "A running instance of Acrobat has caused an error" dialogs appeared, they themselves appeared in the Windows taskbar as Adobe Acrobat windows.

I cannot prove the dialog-to-PID relationship because I did not map the HWND back to a PID while the dialog was visible, so please treat that portion as an observation/hypothesis rather than a confirmed finding.

WINDBG RESULTS - LONG-LIVED PID 28924

This is the most significant finding.

WinDbg identified Acrobat.exe as an application hang.

The main process was not consuming excessive CPU. Its primary thread was waiting in:

win32u!NtUserMsgWaitForMultipleObjectsEx

More importantly, another Acrobat UI thread was caught blocked inside a synchronous Windows SendMessage call while processing DDE messages.

The relevant stack from the full dump is:

win32u!NtUserMessageCall+0x14
user32!SendMessageWorker+0x382
user32!SendMessageInternal+0x174
user32!SendMessageW+0xef
Acrobat!AcroRd32IsBrokerProcess+0xdff
Acrobat!AcroRd32IsBrokerProcess+0x1e15
Acrobat!GetWinstaDesktopInfo+0xdc6c
Acrobat!GetWinstaDesktopInfo+0xdb70
user32!DoCallback+0xc1
user32!SvSpontExecute+0x12e
user32!ProcessSyncDDEMessage+0xb8
user32!ProcessAsyncDDEMsg+0x67
user32!DDEMLServerWndProc+0x7f
user32!UserCallWinProcCheckWow+0x356
user32!DispatchMessageWorker+0x1dd
Acrobat!CreateCoreWebview2EnvironmentSandbox+0x71395
kernel32!BaseThreadInitThunk+0x17
ntdll!RtlUserThreadStart+0x2c

The synchronous SendMessage was targeting:

HWND 0x00220f2c

Register state at capture also showed RCX/RDI/R10/R11 referencing 0x220f2c while the thread was inside NtUserMessageCall.

WinDbg had previously identified this same thread as:

Is_UIThread
BlockedIn_SendMessage: HWND 0x220f2c

The thread's !gle output was:

LastErrorValue: 0
"The operation completed successfully."

LastStatusValue: 0xc0000034
"Object Name not found."

I do NOT know whether the 0xc0000034 status is directly responsible for the hang, so I am including it only as raw diagnostic information.

WHY THIS LOOKS LIKE AN EXISTING-INSTANCE / DDE PROBLEM

Our current working theory is:

1. A normal Acrobat instance launches and opens a PDF.
2. That Acrobat process remains alive in the background.
3. At some point its Windows message / DDE handling enters a bad state.
4. The user later double-clicks another PDF.
5. A new Acrobat process attempts to launch and/or hand the document to the existing Acrobat instance.
6. Communication with the existing instance does not complete normally.
7. Additional Acrobat.exe processes accumulate.
8. The user eventually receives:
   "A running instance of Acrobat has caused an error."
9. Killing all Acrobat.exe processes clears the condition because the stale/broken existing instance is removed.

The fact that the oldest lingering process was captured specifically inside:

SendMessageW
 -> ProcessSyncDDEMessage
 -> ProcessAsyncDDEMsg
 -> DDEMLServerWndProc

seems highly relevant to the exact end-user symptom.

OTHER MAIN PROCESSES

We also analyzed PID 29864 and PID 28928.

WinDbg also classified these as Acrobat application hangs and their primary UI threads were sitting in the same general Acrobat/Windows message-wait path:

win32u!NtUserMsgWaitForMultipleObjectsEx
 -> Acrobat.exe
 -> Acrobat.exe
 -> ...

However, neither of those newer dumps contained the same explicit:

SendMessageW
ProcessSyncDDEMessage
ProcessAsyncDDEMsg
DDEMLServerWndProc

stack that appeared in PID 28924.

That is another reason we currently believe PID 28924 is the important original/broken Acrobat instance, while the newer processes may simply be subsequent launch attempts encountering that bad instance.

CPU / MEMORY

Nothing currently suggests a traditional CPU or memory exhaustion problem.

The long-lived Acrobat process had a peak committed-memory value of approximately 273 MB.

The newer processes were also relatively small and largely idle.

Thread CPU usage was minimal.

This appears much more like a process waiting/deadlocking in IPC/message handling than Acrobat gradually consuming all system resources.

ENDPOINT SECURITY

For completeness, this environment uses Cortex XDR.

The following Cortex modules were injected into Acrobat:

cyinjct.dll
cyvera.dll
cyvrtrap.dll

Version observed: 9.2.0.120

However, we currently have no evidence implicating Cortex in this issue.

The Cortex-owned threads visible in the dump were simply waiting in WaitForSingleObject and were not present in the abnormal Acrobat DDE/SendMessage stack.

I am mentioning this only so Adobe engineering has the complete process environment.

WINDOWS INSTALLER / MSI

We also discovered a separate Acrobat installer issue on this workstation during investigation.

Windows event logs have shown repeated Acrobat MSI self-reconfiguration attempts resulting in Error 1730 / status 1603.

However, msi.dll was NOT loaded in any of the three main Acrobat processes captured during this broken state.

Therefore, while the installer issue is real, we currently do not have evidence that it caused this particular failure and are treating it separately.

NETWORK SHARE OBSERVATION

One item we are still investigating is whether mapped/network-drive access contributes to the problem.

The original long-lived process was launched to open a PDF from S:.

The subsequent PID 29864 was also launched to open a different PDF from S:.

We do not currently know whether the network location is causal, contributory, or simply reflects this user's normal workflow.

We are going to start documenting whether affected users were opening PDFs from local storage or network shares when the condition begins.

WORKAROUND

Current reliable workaround:

1. End all Acrobat.exe processes.
2. Re-open the PDF.
3. Acrobat immediately begins functioning again.

No reboot is required.

This strongly suggests that persistent process/session state is involved.

CURRENT CONCLUSION

Based on the dumps, my current working diagnosis is:

Acrobat 26.001.21789 intermittently leaves a long-lived Acrobat.exe instance in a nonfunctional state. In the affected instance we captured, an Acrobat UI thread was blocked in synchronous SendMessage/DDE processing. Subsequent attempts to open PDFs appear unable to communicate correctly with the existing Acrobat instance, causing additional Acrobat.exe processes to launch and ultimately resulting in "A running instance of Acrobat has caused an error."

This is still an investigation and I do not want to overstate causation. The DDE/SendMessage blockage is confirmed by the dump; exactly what causes Acrobat to enter that state is not yet known.

We have retained the full ProcDump .dmp files.

I do not want to publicly upload full process-memory dumps because they may contain document/user/environment data, but if an Adobe employee/engineer wants them, please provide an official/private secure upload method and I would be happy to provide the dumps.

We are also testing the Acrobat update released today and will report whether the issue recurs.

If anyone else experiencing this issue has captured dumps, I would be very interested to know whether you see threads involving:

user32!SendMessageW
user32!ProcessSyncDDEMessage
user32!ProcessAsyncDDEMsg
user32!DDEMLServerWndProc

That could tell us whether multiple organizations are hitting the same failure path.

Hi analytical_athlete675b,

We are sorry for the trouble this may have caused.

The team is aware of the issue and investigating this behavior on priority. However, it is taking time to resolve this. We will keep you updated on any progress and let you know when the fix is available.

We appreciate your patience so far.

Thanks,

Meenakshi

Hi ​@Optimistic_Genie9189 
Hope you are doing well and thanks for reaching out. 

This issue is already reported to our engineering team and they are actively working on it. We will keep this thread updated as soon as we  more information from the team. 

Thanks for your understanding

~Amal

Hi danw56321057,

Thank you for reaching out and reporting this.

We have informed the team about your concern. Since it occurs in the latest version, the team requires logs for further investigation. Please collect the process logs by following the steps outlined in the document linked here: Adobe Acrobat Diagnostics. Download the diagnostic tool from the bottom of the document shared. Once the logs are collected, please share the log ID.

Thanks,

Meenakshi