Java Crash Debug: EXCEPTION_ACCESS_VIOLATION in plcommpro.dll – JVM Flags, GC, JDK Downgrade
The author documents a step-by-step troubleshooting journey for a Java service crashing with EXCEPTION_ACCESS_VIOLATION (0xc0000005) in plcommpro.dll, trying minidump enablement, JDK downgrade from 8u241 to 8u191, JIT compilation exclusion for Hibernate, heap sizing, GC switch to ParallelOldGC, and DLL version checks, with each fix extending uptime but not fully resolving the native crash.
Error Overview
The Java service crashes with EXCEPTION_ACCESS_VIOLATION (0xc0000005) in native code, specifically at C [plcommpro.dll+0xc715]. The JVM is Java 8u241 (HotSpot 64-Bit Server VM 25.241-b07) on Windows. The crash report indicates minidumps are not enabled by default on client Windows versions.
Attempt 1: Enable Minidump on Crash
Added -XX:+CreateMinidumpOnCrash to idea64.exe.vmoptions to trigger Windows MiniDumpWriteDump(). After restart, the IDE crashed but no minidump appeared; however the project stopped crashing for ~10 minutes before failing again.
Attempt 2: Downgrade JDK
Suspected JDK 8u241 bug. Downloaded JDK 8u191 from Oracle official archive, updated environment and IDE project JDK. Service ran for ~30 minutes then crashed again.
Attempt 3: Exclude Problematic Hibernate Method from JIT Compilation
Mentor suggested JVM tweak. Added
-XX:CompileCommand=exclude,org/hibernate/cfg/annotations/SimpleValueBinder,setTypeto VM options. Extended uptime to ~1 hour but still crashed.
Attempt 4: JVM Heap Sizing
Set -Xms512m -Xmx1024m. Service survived overnight but crashed within 30 seconds after a code change and restart.
Attempt 5: Verify Tomcat and DLL Version Consistency
Checked Tomcat version via version command in bin directory. Versions matched, so no action needed.
Attempt 6: Switch Old Generation GC to ParallelOldGC
Default GC flags showed -XX:+UseParallelGC (Parallel GC for young gen, Serial Old for old gen). Added -XX:+UseParallelOldGC to use parallel collector for old generation. Crash persisted.
Attempt 7: Code Issue Consideration
Dismissed as the project is already in production and crashes occur at random intervals, not deterministically.
Attempt 8: Investigate plcommpro.dll
The problematic frame points to plcommpro.dll. Author hesitates to modify this third-party DLL but plans to investigate later.
None of the attempts fully resolved the crash, but each extended the mean time between failures. The root cause remains unidentified, likely related to the native library plcommpro.dll interaction with the JVM.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Java Captain
Focused on Java technologies: SSM, the Spring ecosystem, microservices, MySQL, MyCat, clustering, distributed systems, middleware, Linux, networking, multithreading; occasionally covers DevOps tools like Jenkins, Nexus, Docker, ELK; shares practical tech insights and is dedicated to full‑stack Java development.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
