Skip to main content
Solved

Arcpro 3.1 to ArcPro 3.3 breaks python: import fmeobjects


jamesadams
Contributor
Forum|alt.badge.img+3

Using FME 2025 and ArcPro 3.1.7 and the python environment located in C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3, (3.9.16) the python code below works.

Using FM 2025, and ArcPro 3.3.5 and the python environment C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3 (3.11.8), it fails to load the necessary DLLs when importing fmeobjects and crashes.

Switching back to ArcPro 3.1.7 it works again. Can anyone help me import fmeobjects using ArcPro 3.3.5? What am I missing?

 

import os
import sys

os.environ['PATH'] = r'C:\Program Files\FME' + os.pathsep + os.environ['PATH'] 
sys.path.append(r'C:\Program Files\FME\python')

try:
    import fmeobjects
    print(dir(fmeobjects))

    runner = fmeobjects.FMEWorkspaceRunner()
except ImportError as e:
    print(f"Error: {e}")

 

Best answer by jamesadams

For others having this same problem: it’s a dll mismatch between ArcPro 3.3.5 python environment’s msvcp140* dlls and new versions required for fmeobjects (in my case, I am using FME 2025.0 right now but it applies to many other versions).

To fix this (at your own risk), rename msvcp140*.dll files in C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\ to msvcp140*.dllignore. If you have a customized environment elsewhere, you will need to do it there as well. It’s usually something along the lines of C:\Users\<user>\AppData\Local\ESRI\conda\envs\<env_name>.

View original
Did this help you find an answer to your question?

10 replies

jamesadams
Contributor
Forum|alt.badge.img+3
  • Author
  • Contributor
  • March 11, 2025

“DLL load failed while importing fmeobjects: A dynamic link library (DLL) initialization routine failed.”


birgit
Influencer
Forum|alt.badge.img+16
  • Influencer
  • March 11, 2025

I can't really check this myself because I can't install the ArcGIS Pro version but are you willing to try installing FME 2024.2? If it does work with that version of FME it might be a bug in the 2025 version.


jamesadams
Contributor
Forum|alt.badge.img+3
  • Author
  • Contributor
  • March 11, 2025

I just tried it with 2024.2, it still doesn’t work. The only way that I can get it to work is to use ArcPro 3.1.7 or earlier. 


birgit
Influencer
Forum|alt.badge.img+16
  • Influencer
  • March 11, 2025

Do you have two ArcGIS Pro versions installed? FME can't deal with that, ESRI also indicates that having two versions of Pro on your pc can cause issues.


jamesadams
Contributor
Forum|alt.badge.img+3
  • Author
  • Contributor
  • March 11, 2025

No, only one version installed.


birgit
Influencer
Forum|alt.badge.img+16
  • Influencer
  • March 11, 2025

Hmmm, I have only one idea left to be honest. Can you post your ArcGIS Pro version?


jamesadams
Contributor
Forum|alt.badge.img+3
  • Author
  • Contributor
  • March 11, 2025

It is: 3.3.5 

It also doesn’t work for 3.4.x or any 3.3.x

It does work for 3.1.7.


birgit
Influencer
Forum|alt.badge.img+16
  • Influencer
  • March 11, 2025

Unfortunately I don't know what else it can be. Maybe someone will come by here who has a better idea or maybe contact Safe. Is there a specific reason you want to use the 3.3.5 version?(I am just curious) 


boydfme
Contributor
Forum|alt.badge.img+6
  • Contributor
  • March 16, 2025

Potential workaround if all you need to do is run your FME workbench from a python script is to remove the python FME objects from the equation and run it through command line (in python, it would be through the standard subprocess module).

I would first manually verify your workbench works on a regular command line but if it does…...

You could do something like this (just change or remove the user parameters as needed etc):

import subprocess
import os
import sys

def fmeworker(workbench, f, logpath):
    '''fmeworkber function automates the execution of a workbench through the python
    subprocess method. The subprocess.Popen() executes the command and retrieves the process outputs to stdout and stderr.
    workbench = the fme .fmw workbench to run; full path str
    f = example user parameter 1 of the workbench; feature class str
    logpath = example user parameter 2 of the workbench; path to log.txt output str
    '''
    #
    text = ''
    try:
        fme_ = r"C:\Program Files\FME\fme.exe" ##fme.exe; change this based on your installation
        command = f'"{fme_}" "{workbench}" --FEATURE_TYPES "{f}" --LogFile "{logpath}"'
        starter = subprocess.STARTUPINFO()
        starter.dwFlags |= subprocess.STARTF_USESHOWWINDOW

        process = subprocess.Popen(command,startupinfo=starter, stdout=subprocess.PIPE,stderr=subprocess.PIPE)
        stdout,stderr = process.communicate()
        if stderr:
            stderr_de = str(stderr.decode("utf-8")) # Need to remove byte object
            msg = stderr_de.split("\r\n")[0]
            text += f +'  '+ msg
        else:
            stdout_de = str(stdout.decode("utf-8")) # Need to remve byte object
            msg = stdout_de.split("\r\n")[0]
            text += msg+'ERROR#####'
    except:
        #if the workbench function fails add error tag
        text += f +'ERROR#####'
    return text


Which can give you a return output from your workbench if it was successful or not:
 

example output of running a workbench on a list of feature classes. The stderr return will let us know if the translation was successful or not.

 

 


jamesadams
Contributor
Forum|alt.badge.img+3
  • Author
  • Contributor
  • Best Answer
  • March 17, 2025

For others having this same problem: it’s a dll mismatch between ArcPro 3.3.5 python environment’s msvcp140* dlls and new versions required for fmeobjects (in my case, I am using FME 2025.0 right now but it applies to many other versions).

To fix this (at your own risk), rename msvcp140*.dll files in C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\ to msvcp140*.dllignore. If you have a customized environment elsewhere, you will need to do it there as well. It’s usually something along the lines of C:\Users\<user>\AppData\Local\ESRI\conda\envs\<env_name>.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings