I am trying to debug a very simple python script:
import arcpy
print('OK')
I am using Visual Studio Code (Windows 10 x64) which has been executed from a BAT file which activates C:\Program Files\ArcGIS\Pro\bin\Python\Scripts\proenv.bat before hand to ensure that the python environment is setup for ArcGIS Pro usage.
When I try to debug the script sometimes the script prints OK and sometimes is just crashes python on the first line. A try/except doesn't work here since the first line is causing python to completely crash and it will never reach the except part. I can repeat running the script in debug mode and to me it seems very random if it completes or crashes.
So far I haven't found any log entries anywhere which describes what is happening. It could be that the import part is checking for a valid license (I am using concurrent licensing) and that something in that check is faulting but it is very difficult to tell since I get no clues at all from the crash.
Can anyone give me a hint to where I can find more details or what could be the reason for these crashes?
For what it's worth, you can try/except an import statement. That would at least rule out the issue being something to do with importing the module, itself. You'd be checking for an ImportError exception.
The fact that it sounds transient makes me wonder if there's some sort of race condition or permissions lock in your setup that's causing this. Can you share start-to-finish your procedure with scripts and error messages?
Incidentally, what you're describing sounds like a rather odd way to go about this in the first place, but I'm assuming it's a test/proof-of-concept for something else?
I'm having this problem as well. Sometimes importing arcpy would exit the entire runtime (with an exit status indicating non-successful exit). No amount of try-except recovery works except to re-run it. So "you can try/except an import statement" didn't work.
Can you share start-to-finish your procedure with scripts and error messages?
The OP literally gave the script and command (C:\Program Files\ArcGIS\Pro\bin\Python\Scripts\proenv.bat) above. He couldn't find any error messages or logs.
Incidentally, what you're describing sounds like a rather odd way to go about this in the first place, but I'm assuming it's a test/proof-of-concept for something else?
I don't understand what you mean here. Is running a standalone script using arcpy supposed to be "odd"? Is arcpy supposed to be only ran in ArcGIS Pro? The only odd thing I find is how importing arcpy is non-deterministic and would sometimes kill the Python runtime. FYI this also happens in the Python REPL, not just running a script:
(base) PS C:\Users\user> C:\Program` Files\ArcGIS\Pro\bin\Python\Scripts\propy.bat
Python 3.9.16 [MSC v.1931 64 bit (AMD64)] :: Anaconda, Inc. on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import arcpy
(base) PS C:\Users\user>
Sometimes, after typing import arcpy, it just exits the REPL.
The following is what I've tried. I was able to find the offending file that was causing this, as well as a stack trace. I hope this will be useful for you.
This is the command I'm running in powershell (the ` is intentional to escape the space in powershell). Some runs exits the script with a failing error code, but the last one has no problems.
(base) PS C:\Users\user> C:\Program` Files\ArcGIS\Pro\bin\Python\Scripts\propy.bat .\test.py
(base) PS C:\Users\user> $?
False
(base) PS C:\Users\user> C:\Program` Files\ArcGIS\Pro\bin\Python\Scripts\propy.bat .\test.py
(base) PS C:\Users\user> $?
False
(base) PS C:\Users\user> C:\Program` Files\ArcGIS\Pro\bin\Python\Scripts\propy.bat .\test.py
imported
(base) PS C:\Users\user> $?
True
test.py has the following code (the first line is commented out when I wanted to run it multiple times). I repeatedly stepped into the import statement using the debugger
breakpoint()
import arcpy
print('imported')
I got to the file
c:\program files\arcgis\pro\bin\python\envs\arcgispro-py3\lib\site-packages\arcgisscripting\__init__.py
At line 131, there is an import:
from ._arcgisscripting import *
The arcgisscripting folder has files __init__.py, __pycache__, and _arcgisscripting.pyd. so this must be importing from the .pyd file. Unfortunately .pyd is an opaque DLL so I can't investigate any further.
You can get to this part this by running the test.py code above. When in the debugger, (Pdb) will be visible on the left. Type the commands on the right as shown below:
(base) PS C:\Users\user> C:\Program` Files\ArcGIS\Pro\bin\Python\Scripts\propy.bat .\test.py
> c:\users\user\test.py(2)<module>()
-> import arcpy
(Pdb) b c:\program files\arcgis\pro\bin\python\envs\arcgispro-py3\lib\site-packages\arcgisscripting\__init__.py:
131
Breakpoint 1 at c:\program files\arcgis\pro\bin\python\envs\arcgispro-py3\lib\site-packages\arcgisscripting\__in
it__.py:131
(Pdb) c
> c:\program files\arcgis\pro\bin\python\envs\arcgispro-py3\lib\site-packages\arcgisscripting\__init__.py(131)<m
odule>()
-> from ._arcgisscripting import *
(Pdb)
In the first (Pdb), we add a breakpoint directly to the file. In the second (Pdb), we continue execution of importing arcpy, until it hits the breakpoint. The third (Pdb)is when it hit the breakpoint and stops. You can type s here to jump into the import, but it was fruitless for me, because it seems to be importing from the .pyd file, which is an opaque DLL.
Continuing from the above Pdb session, I can obtain a stack trace:
> c:\program files\arcgis\pro\bin\python\envs\arcgispro-py3\lib\site-packages\arcgisscripting\__init__.py(131)<m
odule>()
-> from ._arcgisscripting import *
(Pdb) import traceback
(Pdb) traceback.print_stack()
File "C:\Users\user\test.py", line 2, in <module>
import arcpy
File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 850, in exec_module
File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
File "C:\Program Files\ArcGIS\Pro\Resources\ArcPy\arcpy\__init__.py", line 77, in <module>
from arcpy.geoprocessing import gp
File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 850, in exec_module
File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
File "C:\Program Files\ArcGIS\Pro\Resources\ArcPy\arcpy\geoprocessing\__init__.py", line 14, in <module>
from ._base import *
File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 850, in exec_module
File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
File "C:\Program Files\ArcGIS\Pro\Resources\ArcPy\arcpy\geoprocessing\_base.py", line 14, in <module>
import arcgisscripting
File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 850, in exec_module
File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
File "C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\site-packages\arcgisscripting\__init__.py"
, line 131, in <module>
from ._arcgisscripting import *
File "C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\bdb.py", line 88, in trace_dispatch
return self.dispatch_line(frame)
File "C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\bdb.py", line 112, in dispatch_line
self.user_line(frame)
File "C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\pdb.py", line 262, in user_line
self.interaction(frame, None)
File "C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\pdb.py", line 357, in interaction
self._cmdloop()
File "C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\pdb.py", line 322, in _cmdloop
self.cmdloop()
File "C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\cmd.py", line 138, in cmdloop
stop = self.onecmd(line)
File "C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\pdb.py", line 422, in onecmd
return cmd.Cmd.onecmd(self, line)
File "C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\cmd.py", line 216, in onecmd
return self.default(line)
File "C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\lib\pdb.py", line 381, in default
exec(code, globals, locals)
File "<stdin>", line 1, in <module>
(Pdb)
I think we are facing the same issue and I can see that you have investigated the problem a bit further than me. Now we just have to convince ESRI to pick up the issue.
I have made a bug report, but it was closed since they couldn't reproduce the error.
What kind of licensing are you using (checking for a valid license is the only reasonable communication I expect the import to perform)?
I also use ArcGIS Pro 3.1.1 but the issue has affected several previous versions, might be going back to 2.6 but I'm not sure.
Hi there, I'm not sure what you mean by "kind of licensing". I think I have an Advanced license. I also have a bunch of Esri Extensions like 3D Analyst and Spatial Analyst. Is there something you're looking for specifically? Thanks.
I'm more thinking in the line of how can I help ESRI dig into this issue. Since the issue is somewhat random I would expect the issue to be related to something which can change between each time we execute the scripts. We cannot look into the source code of the ESRI binaries (at least I'm not capable of reverse engineering the code), but we can tell them a bit about how we have setup ArcGIS Pro. Checking for a valid license is still my best guess to what could cause the issue. I am using a concurrent license and in my organisation we have a license server. So my question to you is how is your ArcGIS Pro configured related to licensing?
Licensing as the problem makes sense to me. I'm also using a Concurrent Use License. I'm not quite sure how my organisation set up licensing. All I did was to follow their instructions and installed ArcGIS Pro from the company's internal store. I'm more of a programmer myself. I think we have a license server as well but I'll have to confirm.
My script is actually supposed to run on a client's ArcGIS Pro, and their licensing situation might be different and they might not have such a problem. I'll have to test in their offices.
What version of ArcGIS Pro?
Not OP but I have the same problem. ArcGIS Pro version is 3.1.1. As for Python:
> C:\Program` Files\ArcGIS\Pro\bin\Python\Scripts\propy.bat --version
Python 3.9.16
I am using Visual Studio Code (Windows 10 x64) which has been executed from a BAT file which activates C:\Program Files\ArcGIS\Pro\bin\Python\Scripts\proenv.bat before hand to ensure that the python environment is setup for ArcGIS Pro usage.
Hi @CasperBørgesen, could you elaborate on this bit, what is the contents of the .bat file you are using to launch VSC?
You can use the VSC user settings to specify the default interpreter and command prompt profile. Something like this:
"terminal.external.windowsExec": "C:\\Users\\<<your user name>>\\AppData\\Local\\Microsoft\\WindowsApps\\wt.exe",
"terminal.integrated.defaultProfile.windows": "Command Prompt",
"terminal.integrated.profiles.windows": {
"Command Prompt": {
"path": [
"${env:windir}\\System32\\cmd.exe"
],
"args": [
"/k", "C:/Program Files/ArcGIS/Pro/bin/Python/Scripts/proenv.bat"
],
"icon": "terminal-cmd",
},
// "Git Bash": {
// "source": "Git Bash"
// }
},
"python.defaultInterpreterPath": "C:\\Program Files\\ArcGIS\\Pro\\bin\\Python\\envs\\arcgispro-py3\\python.exe",
Could you try this rather than using the batch script to specify the launch environment for VSC?
Also, have you submitted a crash dump report for this?