Cortex XDR cyjagent.dll injection causes JVM startup crash (EXCEPTION_ACCESS_VIOLATION in ntdll.dll)

[aravindhanr68]

We run an enterprise Java server application (Zulu OpenJDK 11, Windows Server) and are seeing consistent JVM crashes at startup on hosts protected by Cortex XDR. The agent injects cyjagent.dll (Java Deserialization Protection module) into the Java process, and the JVM crashes in native code:

# EXCEPTION_ACCESS_VIOLATION (0xc0000005)

# Problematic frame: C [ntdll.dll+0x17f35]

# JRE: Zulu OpenJDK 11.0.25+9-LTS, 64-bit Server VM, windows-amd64

Command line includes: -agentpath:C:\Program Files\Palo Alto Networks\Traps\cyjagent.dll

The crash reproduces on every service start while the injection is active, and disappears when the Java process is excluded from the XDR policy. We've confirmed the same pattern on multiple independent hosts — the only common factor is the cyjagent injection. Process exclusion isn't an acceptable long-term state for this server, so we're looking for a proper resolution.

Questions:

Is this a known issue with cyjagent in any specific Cortex XDR agent version? Is there a version where it's fixed?
Is there recommended configuration for the Java Deserialization Protection module (other than full process exclusion) to avoid the crash?
What information would help PA investigate? We can provide full hs_err_pid logs and minidumps via a TAC case.

[susekar · Accepted solution]

Hello @aravindhanr68 ,

Greetings for the day.

This is a known issue that can occur due to a conflict between the Cortex XDR Java Deserialization Protection (JDP) module and certain JVM initialization or termination sequences.

Known fixes:

• CPATR-38467: Resolved in Cortex XDR Agent 9.2.1 and 9.1.101-CE.
• CPATR-18158: Resolved in Cortex XDR Agent 8.3.101.53522 CE and 8.6.1.

Recommended approach:

• Upgrade the Cortex XDR Agent to a fixed version, if possible.
• If an upgrade is not immediately possible, a targeted Support Exception (SUEX) can be used to disable only the affected Java hooks while keeping the remaining JDP protection enabled.
• As an alternative, protection can be disabled specifically for the affected Java process through an Operational Agent Exception.
  
  

The preferred approach is to upgrade to a fixed agent version or use a targeted exception rather than excluding the entire Java process.

If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution".

Thanks & Regards,
S. Subashkar Sekar

[aravindhanr68]

HI Susekar, Thanks for confirming the startup-crash issue. We've now observed a second symptom from the same module on a host running Cortex XDR agent 9.2.0.120 (Windows Server 2025) that we'd like confirmed.

For context — what we observed Cortex doing inside the JVM

Normal:
Poller.run()

Instrumented:
Poller.run()
-> PANW hook
-> Poller.run$PANW()
-> PANW hook

Cortex is not only scanning files. It is instrumenting selected Java methods and adding PANW hooks around the original execution:

The $PANW method appears to contain the original method logic, while the wrapper calls Cortex hooks before/after execution. Those hooks can add delay because execution goes from Java into Cortex's native code:
Application code
-> PanwHooks.MethodLeave1()
-> PanwHooks.NativeMethodLeave()
-> Cortex processing
-> back to Java

For a method that runs occasionally, this overhead may be negligible. But on the affected host, ~34 methods were instrumented — including hot paths such as the Tomcat NIO Poller, SocketProcessor, thread-pool execution, REST request processing, and java.io.FileOutputStream. NativeMethodLeave was visible in 9/9 consecutive thread dumps, suggesting threads spend noticeable time in/around the Cortex hook.

The measured impact was severe on connection-handling paths: NIO connection and WebSocket operations that normally complete in milliseconds were taking 8–9 seconds while instrumented, and overall per-request latency was roughly 9× higher than on an otherwise comparable host where only ~1 method was instrumented.

Questions:

i) Is runtime performance degradation from JDP method hooks a known issue, and is it covered by the CPATR-38467 fix in 9.2.1, or tracked separately?

ii)What determines the instrumentation scope per host? Two hosts running the same Java application showed ~34 vs ~1 instrumented methods — is this driven by policy, content-update version, or runtime heuristics?

iii) Is there a configuration or profile setting that causes the agent to perform deeper analysis/inspection inside these hooks (e.g., on socket or WebSocket paths)? A hook wrapper alone shouldn't turn a millisecond operation into 8–9 seconds, so we'd like to understand whether some Cortex-side investigation (payload analysis, cloud lookup, verdict wait) is being triggered by configuration — and if so, which setting to review.

iv)Can you confirm the expected behavior that stopping agent services does or does not detach already-injected hooks from a running JVM (i.e., a Java process restart is required for making the effect after disabling)?

v) Kindly share the best practices that should be followed to make our products compatible with Cortex agents.