Cortex XDR JDP method instrumentation causing severe Java runtime slowness (agent 9.2.0.120) — follow-up to solved cyjagent crash thread

[aravindhanr68]

This is a follow-up to a previously solved thread: Cortex XDR cyjagent.dll injection causes JVM startup crash, where @susekar confirmed the known JDP/JVM conflict (CPATR-38467 / CPATR-18158). Thanks for that confirmation. Since the solution there is already accepted, raising this as a separate topic: we've now observed a second symptom from the same module — severe runtime slowness rather than a startup crash — on a host running Cortex XDR agent 9.2.0.120 (Windows Server 2025), and we'd like it confirmed.

For context — what we observed Cortex doing inside the JVM

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

Normal:
Poller.run()

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

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 whether stopping agent services does or does not detach already-injected hooks from a running JVM (i.e., is a Java process restart required for the disable to take effect)?

v) Kindly share the best practices we should follow to make our Java server application compatible with Cortex agents.