GP Service Fails with "Instance of Service Crashed.... Containing Process has Crashed"

1612
3
05-06-2021 03:02 PM
Arne_Gelfert
Occasional Contributor III

Migrating GP services from 10.6 to 10,8.1. Here is a case of a GP service being called from JSAPI that worked fine in 10.6 and now in 10.8.1 after migration fails with an error I haven't seen before:

"Instance of Service Crashed.... Containing Process has Crashed"

Full error message below although not much more helpful.  There are no separate error logs as referenced in the message below.

 

<Msg time="2021-05-06T14:50:09,366" type="SEVERE" code="7551" source="Server" process="9192" thread="26" methodName="" machine="< my server ...>" user="" elapsed="" requestID="4bdbfe27-59ad-4488-b2c2-57c776e75d0b">Instance of the service 'myservice.GPServer' crashed. Please see if an error report was generated in 'E:\arcgisserver\logs\........\errorreports'. To send an error report to Esri, compose an e-mail to ArcGISErrorReport@esri.com and attach the error report file.</Msg>
<Msg time="2021-05-06T14:50:15,950" type="SEVERE" code="7553" source="Server" process="9192" thread="26" methodName="" machine="< my server ...>" user="" elapsed="" requestID="4bdbfe27-59ad-4488-b2c2-57c776e75d0b">The containing process for 'myservice.GPServer' job 'jf94974a2dd8444cc8bb537d376dafcc9' has crashed.</Msg>

 

I know that my Python code on server starts executing and reports status of "Executing" back to webpage. It also does some logging for me. But it doesn't finish. No amount of exception handling I have tried tells me where it fails and the usually helpful AGS output in 

/jobs/...../scratch/messages.xml 

isn't helping. It looks like this:

<?xml version="1.0"?>
-<GPMessages xmlns:typens="http://www.esri.com/schemas/ArcGIS/2.6.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="typens:GPMessages">
-<GPMessages xsi:type="typens:ArrayOfGPMessage">
-<GPMessage xsi:type="typens:GPMessage">
<MessageType>0</MessageType>
<MessageCode>0</MessageCode>
</GPMessage>
-<GPMessage xsi:type="typens:GPMessage">
<MessageType>0</MessageType>
<MessageCode>0</MessageCode>
</GPMessage>
-<GPMessage xsi:type="typens:GPMessage">
<MessageType>0</MessageType>
<MessageCode>0</MessageCode>
</GPMessage>
<GPMessage xsi:type="typens:GPMessage">
<MessageType>0</MessageType>
<MessageCode>0</MessageCode>
</GPMessage>
-<GPMessage xsi:type="typens:GPMessages">
-<GPMessages xsi:type="typens:ArrayOfGPMessage">
-<GPMessage xsi:type="typens:GPMessage">
<MessageType>0</MessageType>
<MessageCode>0</MessageCode>
</GPMessage>
-<GPMessage xsi:type="typens:GPMessage">
<MessageType>0</MessageType>
<MessageCode>0</MessageCode>
</GPMessage>
-<GPMessage xsi:type="typens:GPMessage">
<MessageType>0</MessageType>
<MessageCode>0</MessageCode>
</GPMessage>
-<GPMessage xsi:type="typens:GPMessage">
<MessageType>0</MessageType>
<MessageCode>0</MessageCode>
</GPMessage>
</GPMessages>
</GPMessage>
</GPMessages>
</GPMessages>

 which I've also not seen before. Usually there are some familiar Python errors in there to launch you into debugging.

Last week, I patched this for some other print service related issues, as mentioned in this thread. I found a technical article suggesting this may be caused if Python in (un)installed separately from ArcGIS. I installed Python along with ArcGIS Server but not in the default path. Before I start messing with registry, would this be expected behavior when having Python on D:\ or E:\? Also wouldn't I be seeing issues with other features of ArcGIS Server leveraging Python? Also the wrong path would keep Python from starting to run.

Any feedback or insights into what my cause this error is appreciated

0 Kudos
3 Replies
Arne_Gelfert
Occasional Contributor III

I've verified that registry has the right paths set for Python 2.7.

Arne_Gelfert_0-1620339061423.png

E:\Python27\ArcGISx6410.8\Lib;E:\Python27\ArcGISx6410.8\DLLs;E:\Python27\ArcGISx6410.8\Lib\lib-tk

0 Kudos
Arne_Gelfert
Occasional Contributor III

Beginning to think this is a matter of Python 2.7/3.x. I may need to go back and review if I made any special accommodations in 10.6 to use 3.x. I see there are more options in 10.8.1 to select a Python version at the services level.

0 Kudos
AdamMiller4
New Contributor III

Just wanted to check if you ever found a workaround for this error.  We are experiencing something very similar attempting to upgrade a GP tool from 10.6.

0 Kudos