0

I'm trying to get a python program to run on a windows box. I have it running on my development windows box but when I transfer it to another windows box I keep getting:

ImportError: DLL load failed: %1 is not a vaild Win32 aplication

The trace suggests it is having trouble with imports, it basically goes through several in-house python programs (that import each other) and then into the ArcPy realm. Ultimately the last one it seems to have tried is arcgisscripting.

When I am on that box if enter the interpreter and type "import arcgisscripting" I get no errors (just a new >>> cursor), so I started to think this error was a bit misleading. I'd read this error typically crops up if (for instance) the python code was compiled 64bit and you're trying to run on 32bit python.

A colleague suggested that the error sometimes happens if python can't find some of the necessary code. So I checked and did SET statements and now the PATH and PYTHONPATH variables seem to be equivalent. Still I get this error, not sure what to do. I'd prefer not to have to do things like uninstalling stuff on the problem box and reinstalling it. That box is a shared resource.

Dan S
  • 355
  • 2
  • 15
  • Is there only one Python version installed on target box? – Janne Karila Oct 08 '12 at 13:09
  • does this perhaps help : http://stackoverflow.com/questions/8597126/cx-freeze-ldap-importerror-dll-load-failed-1-is-not-a-valid-win32-application – zeffii Oct 08 '12 at 13:11
  • @Karila I believe there is only one python on the target box. On my box there are two pythons (2.6 and 2.7) and I run this with 2.7. On the target box I see 2.7. – Dan S Oct 08 '12 at 13:23
  • @zeffii if my ArcPy code was compiled 64 bit rather than 32, wouldn't I get an error in the interpreter when I typed "import arcgisscripting"? – Dan S Oct 08 '12 at 13:27
  • `importing without error` is a good start but i've come across situations where working with the imported module still wasn't possible. You might want to do more than import in the shell, see if you can inspect it. – zeffii Oct 08 '12 at 13:50
  • @zeffi not sure I know what you mean "see if you can inspect it" – Dan S Oct 08 '12 at 14:04
  • @zeffii I did (on the commandline) "import inspect" "inspect.getmembers(arcggisscripting)" and I see output for a large number of things inside that module. – Dan S Oct 08 '12 at 15:02
  • I found DependencyWalker at: http://www.dependencywalker.com/ it claims about my top level program "No DOS or PE signature found. This file is not a valid 32-bit or 64-bit Windows module". That would explain the DLL error but what I don't understand now is why this is the case. It works just fine on my box (though DepenencyWalker makes the exact same complaint there). The target box is windows 2008 server and my box is Windows 7 enterprise. – Dan S Oct 08 '12 at 15:49
  • Are you running from Python source code, or have you packaged your code with py2exe or similar? – Janne Karila Oct 08 '12 at 16:23
  • sorry @DanS that's probably beyond my level of comprehension - i'll bow out. – zeffii Oct 08 '12 at 16:25
  • @Karila I didn't do anything special to make .exe's so I was assuming I'm running source code. I do see .pyc files on the target machine and given the timestamp on them I think they came from the repository (could this be the problem?) – Dan S Oct 08 '12 at 17:01

2 Answers2

0

Finally found it. The .pyd file for arcgisscripting (basically a .dll specific to python) is at C:\Program Files (x86)\ArcGIS\Desktop10.1\bin\arcgisscripting.pyd

If I point DependencyWalker at that file it indicates that several dependencies for that are not found.

So it seems the solution is to: 1) find the last file the ImportError flagged 2) look for its .pyd file on the filesystem 3) run DependencyWalker on that .pyd to find out what is missing

Dan S
  • 355
  • 2
  • 15
  • Hmmm... when I was looking up some of the .dlls that DependencyWalker says are missing, it looks like other people who get them flagged also find they they are red herrings. Maybe DependencyWalker is not such a great diagnostic after all... – Dan S Oct 09 '12 at 18:18
  • Turned out to be a problem with the installation of ArcGIS software. When ArcGIS was reinstalled the problem went away. – Dan S Oct 11 '12 at 11:05
0

I have lately learned a few lessons from going through the same misery.

There are a couple checks to run first.

  1. Check that all of your components are running on the same OS base, 64 bit or 32 bit. If your machine is a 64 bit installation, make sure you have a 64 bit version of python. Same goes for the installation of Oracle Instant Client; it needs to be 64 bit also if that is what your machine is running.

  2. If you want to make the exe actually software independent, you are going to have to package up the oracle instant client and set the system path variables.

  3. The easiest run of it I have had is py_installer, it ran pretty well out of the box, but I am still working to include the instant client installer.

  4. before you import cx_oracle set these system paths

    # instantClientPath is the path to the instant client folder
os.environ["PATH"] = instantClientPath+";"+os.environ["PATH"] 
os.environ["ORACLE_HOME"] = instantClientPath 
os.environ["LD_LIBRARY_PATH"] = instantClientPath 
os.environ["TNS_ADMIN"] = instantClientPath 
os.environ["NLS_LANG"] = "american_america.WE8MSWIN1252"
Cœur
  • 37,241
  • 25
  • 195
  • 267
giveemheller
  • 106
  • 8