ArcGIS Portal 11.5 crashes when requiring an ArcGIS Pro Licence

[SimonReman2010]

Hello everyone,

We recently upgraded ArcGIS Enterprise to version 11.5.
As expected, ArcGIS Pro licenses are now managed directly through the portal (no more License Manager).

However, we are facing a recurring issue: when an ArcGIS Pro 3.5 client tries to obtain a license from the portal, the portal sometimes crashes and restarts 
The portal log shows:

The web server was found to be stopped. Re-starting it.

Has anyone experienced this issue or found a solution?

Best regards,

Simon

[SimonReman2010]

Hello,

Update of 10/07/2025

When I enable the log level to debug, I get the following error during this incident.

java.lang.RuntimeException: java.util.concurrent.TimeoutException at com.esri.arcgis.portal.util.CallableUtil.execute(CallableUtil.java:31) at com.esri.arcgis.portal.util.TomcatUtil.startServer(TomcatUtil.java:109) at com.esri.arcgis.portal.plugins.ProcessMonitor.c(ProcessMonitor.java:281) at com.esri.arcgis.portal.plugins.ProcessMonitor$d.run(ProcessMonitor$d.java:538) Caused by: java.util.concurrent.TimeoutException at java.base/java.util.concurrent.FutureTask.get(Unknown Source) at com.esri.arcgis.portal.util.CallableUtil.execute(CallableUtil.java:29) ... 3 more

This error also appears in https://support.esri.com/en-us/knowledge-base/error-could-not-start-the-web-server-java-util-concurr...

I'm in touch with Esri Belux Support.

I'll provide another update when I get more information.

Best,

Simon

[SimonReman2010]

Hello,

It seems that it is not related to ArcGIS Pro. We can reproduce the problem through the Portal Admin interface. From time to time the portaladmin/license/populateLicense crashes the portal.

We tried to regenerate a new licence file but it doesn't help

Best regards,

Simon

[SimonReman2010]

Hello,

Here’s an update after two weeks.

Esri Belux support and consultants still have no idea about the origin of the problem.

I tried uninstalling and reinstalling the portal, but the issue persists.

I was also able to reproduce the problem in a completely different environment in the Azure Cloud.

Requesting the populateLicense operation several times causes the portal to reboot without any error message.

I’ll keep investigating.

Best regards,
Simon

Simon

[SimonReman2010]

Hello,

Some updates:

It turns out that the crash is caused more specifically by the call
sharing/rest/content/listings/d4a332a0be784dd2be53cec0a35e0859/userLicenses
that ArcGIS Pro makes to the portal in order to retrieve the license information of the authenticating user.

There is a similar call to retrieve Navigator licenses, but that one does not cause the crash.

Randomly, the javaw process crashes and restarts.

It appears that when the process tries to read from or write to the internal PostgreSQL database of the portal, the connection is interrupted and the javaw process restarts.

We were able to reproduce the issue in versions 11.4, 11.5, and 12.

As of today, Esri Belux has not been able to provide us with a solution or an investigation path pointing to an infrastructure issue.
I will share updates once we have found a solution.

Best regards,

Simon

[SimonReman2010 · Accepted solution]

Hello,

We finally found the reason of our problem.

Here is the summary of our case.

The Problem

Users were experiencing immediate crashes of ArcGIS Portal during the ArcGIS Pro license acquisition phase with portal 11.4, 11.5 and 12.

• No errors were logged in the portal application logs or the Windows Event Viewer.

• We noticed a correlation between the ArcGIS Pro license complexity and the crash. Users with higher-level licenses and more extensions (resulting in a larger JSON payload) were more likely to trigger the crash.

Technical Investigation

After diving in with WinDBG, we found that the javaw.exe process (responsible for handling the license JSON) was being terminated abruptly.

It appears that when the license JSON reaches a certain size, javaw.exe utilizes advanced memory allocation/compilation functions. In highly secured environments, these specific memory actions can be flagged as "suspicious behavior" by OS-level security tools.

The Root Cause

The culprit was Windows Exploit Protection. In our infrastructure, specific security rules had been applied globally to javaw.exe. These rules were intercepting the process's memory management, causing it to crash before it could even report an error.

The Solution

1. Locate Exploit Protection: Go to Windows Security > App & browser control > Exploit protection settings.

2. Check Program Settings: Look for javaw.exe in the list.

3. Test: We disabled the specific rules for javaw.exe in our environment, and the crashes stopped immediately.

We are currently in contact with Esri Belux to understand why this specific license acquisition process is being flagged as malicious by Windows Exploit Protection.

Given the nature of the conflict, we have requested that this issue be escalated to the Esri Inc. development team. Our goal is to determine if the memory handling within the licensing component can be optimized to avoid triggering these security heuristics, or if official exclusion guidelines need to be established for hardened environments.

I will update this thread as soon as we have more feedback from their technical team.

Best regards,

Simon

[SimonReman2010]

Hello, 

One more small information.

Only the "Import address filtering (IAF)" rule in Exploit Protection is causing the crash.

It has to be disabled for the moment

Best,

Simon

[SimonReman2010]

Hello,

Last comment to end this post.

Esri Belux considers that it is not a bug and told us that the ArcGIS Enterprise documentation must be updated to warn users of potential incompatibilities between Exploit and ArcGIS Enterprise.

Best regards,

Simon

[SimonReman2010]

Hello,

Esri documented this issue here :

[#BUG-000183052 The Import Address Filtering "program setting" mitigation in Microsoft Windows Defender for Exploit causes the ArcGIS Enterprise portal's web server to intermittently crash when handling certain licensing requests.]

Best regards,

Simon