Skip to main content
Solved

FME Flow 2025.2.1 – job stops unexpectedly without error

  • April 8, 2026
  • 3 replies
  • 47 views
peterhavik
Contributor
Forum|alt.badge.img+4

Hello everyone,

We are encountering an issue with FME Flow 2025.2.1 where jobs stop unexpectedly without any error message.

Scope / Versions

  • ✅ Issue occurs in: FME Flow 2025.2.1
  • ❌ Issue does NOT occur in:
    • FME Flow 2024.1.2.1
    • FME Form 2025.2.1

This suggests the problem is specific to FME Flow 2025.2.1 and not related to the workspace or FME Form itself.

Observed behavior

  • The job stops abruptly without any error reported in the FME Flow UI or job log.
  • Enabling Debug logging in FME does not provide any additional insights.
  • The same workspace runs successfully in:
    • FME Form 2025.2.1
    • FME Flow 2024.1.2.1

FME Flow logging

We reviewed additional server-side logs.
In fmeprocessmonitorengine.log, we consistently see that the engine ends unexpectedly.

Relevant log snippet:

Tue-07-Apr-2026 04:31:29.648 PM   INFORM   requesthandler   401831 : Accepted new client connection from /127.0.0.1 on port 7500
Tue-07-Apr-2026 04:32:14.937 PM   INFORM   Thread-46   localhost_Engine1   WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Tue-07-Apr-2026 04:32:18.523 PM   WARN     localhost_Engine1   393562 : Process "localhost_Engine1" ended unexpectedly. Being restarted on attempt 1...

We investigated the warning related to sun.reflect.Reflection.getCallerClass, but based on our research this warning appears to be performance-related only and not directly linked to the engine crash.

We tried running the job with another engine, results are the same.

Windows Event Viewer

We also checked the Windows Event Viewer on the FME Flow server.
Around the same timestamp as the failed job, we see events including:

  • Faulting application: FMEEngine.exe
  • Exception code: 0xc00000005 (access violation)

This suggests the engine may be crashing at OS level, rather than failing gracefully within FME.

Questions

  • Has anyone seen similar behavior in FME Flow 2025.2.1?
  • Are there known regressions, engine-related issues, or Java/engine changes in this version?
  • Any recommendations for:
    • Additional diagnostics
    • Crash dumps
    • JVM or engine-level logging
    • Known fixes or patches?

If helpful, we attached the full log file of the job (job_174.log) and a part of the fmeprocessmonitorengine.log

Thanks in advance for your help!

Best answer by peterhavik

Hi,

First of the problem seems to be found. It is the preferred python version selected in FME Form an Flow

As for a few questions in the last posts: We installed FME Flow 2025 on a parallel machine so a clean install.

FME Form, used for testing is running on AVD's with ArcGIS Pro 3.5.5. With a changed host file to connect to the new VM.

Back to the solution:

For our FME service accounts to be able to use ArcGIS Enterprise licence we installed ArcGIS Server 11.5 and set the ArcGIS Server python version as the default python interpreter, which is 3.11.11 (same as ArcGIS Pro 3.5.5). This is part of our standard installation steps.

In FME Form the preferred Python Interpreter was set to Python 3.12+ in the FME option/Translation. But even when this is set to Ersi ArcGIS Python 3.11+ in the options, it could be the workspace Parameter Python Compatibility setting is different. In our workspace it was set to Python 3.12+.

When this was changed to Ersi ArcGIS Python 3.11+ and published to Flow the workspace worked on flow succesfully.

    3 replies

    itsmatt
    Celebrity
    Forum|alt.badge.img+47
    • itsmattCelebrity
    • Celebrity
    • April 8, 2026

    When you say it works in FME Form 2025 are you running it on  the same machine as the flow machine?

    From the looks of it you’re running flow on an azure machine, it’s hard to say exactly what it is but the timing looks to be related the end of the read with JDBC and the beginning of the write. 

    My first suspicion would be some kind of version conflict with a dependency on the azure machine. Are the ESRI versions the same on the machine running form and the machine running flow?

    Seems like this is a question you might want to ask safe support directly.

     

      redgeographics
      Celebrity
      Forum|alt.badge.img+62

      As an addition to what ​@itsmatt said, when you upgraded FME Flow from 2024 to 2025, did you do that on a fresh machine or the existing one? (that may be a cause of a dependency conflict)

      Do all jobs stop in the same way? Are there jobs that do complete succesfully? Can you spot a pattern?

      FME rocks! \m/
      peterhavik
      Contributor
      Forum|alt.badge.img+4
      • peterhavikContributor
      • Author
      • Contributor
      • Best Answer
      • April 10, 2026

      Hi,

      First of the problem seems to be found. It is the preferred python version selected in FME Form an Flow

      As for a few questions in the last posts: We installed FME Flow 2025 on a parallel machine so a clean install.

      FME Form, used for testing is running on AVD's with ArcGIS Pro 3.5.5. With a changed host file to connect to the new VM.

      Back to the solution:

      For our FME service accounts to be able to use ArcGIS Enterprise licence we installed ArcGIS Server 11.5 and set the ArcGIS Server python version as the default python interpreter, which is 3.11.11 (same as ArcGIS Pro 3.5.5). This is part of our standard installation steps.

      In FME Form the preferred Python Interpreter was set to Python 3.12+ in the FME option/Translation. But even when this is set to Ersi ArcGIS Python 3.11+ in the options, it could be the workspace Parameter Python Compatibility setting is different. In our workspace it was set to Python 3.12+.

      When this was changed to Ersi ArcGIS Python 3.11+ and published to Flow the workspace worked on flow succesfully.

        Community Stats

        32,446
        Posts
        123,297
        Replies
        40,600
        Members
        Terms & ConditionsCookie settingsAccessibility statement
        A product of
        Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.