Method failed.HRESULT = 0x80070057 : The parameter is incorrect
Failed to rename cache folder
The solution was to check if the ArcGIS Server Account (which is running the Windows Service) has full control of the directory "arcgisserver", eg. C:\arcgisserver, D:\arcgisserver, E:\arcgisserver etc depending on your installation.
The spanish blog post can be found here:
https://uruleando.blogspot.com/2017/11/method-failedhresult-0x80070057.html
For us, the crash was repeatable by loading MXD and browsing to same coordinates, or using the actual REST service endpoint with the query? function like this to pass in geometry:
http://servername.domain.com/arcgis/rest/services/SOMEFOLDER/SERVICENAME/MapServer/9/query?where=&te...
Which would result in this:
and an HRESULT severe error would be logged by the ArcGIS server machinename\service logs.
Changing our coordinates would not cause the error.
Opening the mxd in arcmap and allowing the whole thing to draw would crash. stopping it early and zooming in to a good coordinate area would not crash, but panning over to the problem coordinates would always crash arcmap.exe (send report to esri dialog and all).
The problem was... a bad polygon in the sde layer, which was reloaded nightly by scripts that generate that feature class. Something corrupted the layer during that dataload, and our previously functional service would then crash because of bad polygon data.
Reloading the polygon layer with fresh uncorrupted data resolved the crashing of our server.
Hope this helps someone else.
-Josh Dalton
I have the same issue when publishing dynamic services to ArcGIS Server using ArcMap 10.5.1. I get the same errors in the ArcGIS Server logs.:
SEVERE | 31 jan. 2020 19:54:47 | Failed to rename cache folder. |
SEVERE | 31 jan. 2020 19:53:46 | Method failed.HRESULT = 0x80070057 : The parameter is incorrect. . |
SEVERE | 31 jan. 2020 19:53:46 | Method failed.HRESULT = 0x80070057 : The parameter is incorrect. . |
On the map (In Geocortex Essentials) the symology is not showed on others people's account but when clicking the pop-ups do show up, meaning that the data is loaded. The issue thus lies with the symbology. The symbology is shown through my account which indicates something is wrong with the sharing settings of the directory where the symbology is stored, as suggested above.
I have come to the observation that it happens when my symbology in the ArcMap document is not simple line/fill but complex symbology (such as cartographic line symbology). Replacing this to simple line/fill symbology resolves the issue. It's a workaround but not a solution to the problem.
Somehow this symbology definition is not written properly in the ArcGIS Server directories so that everyone has access. This while other dynamic layers are published successfully in the exact same directory but without complex symbology.
Anyone any idea or update what is going on and how this can be fixed?
Jelle Stuurman
I too am seeing these errors at 10.6, on both dynamic and cached services. The services themselves seem unaffected, but I see jobs stacking up in the arcgisserver/directories/arcgisjobs/system/publishingtools_gpserver and cachingtools_gpserver folders. These jobs are not being cleared after publication completes. For cached services, when checking the status, some crazy numbers are returned, for example "407% of the tiles are present". We ran into this initially several months ago with cached services and esri support walked us through stopping the cache gp services in server admin, clearing out the gpserver folders related to caching, then restarting the services which did resolve it until it cropped up again a couple days ago. I tried this same method today for both caching and publishing tools but am still seeing the same errors when I republish an existing dynamic service. We were advised at the time of the initial problem that we had "too many services published to our arcgis server". Basically, the number of services causes a large number of ArcSOC processes running at the same time which affects performance (Problem: The number of ArcSOC instances causes ArcGIS Server performance issues). We combined a number of services to reduce the count, but have since published some additional services so there may be some truth to a large number of services and therefore ArcSOC processes being one possible cause of these errors.