ExcelToSQLite64 won't die (it's back)

[PaulSchrum1]

I noticed my computer's fan is running nearly all the time after running ArcGIS Pro 3.0. After investigating, I found that ExcelToSQLite64 keeps running even after closing ArgGIS Pro. When it does, it uses one of my virtual processors at 100% utilization until I kill the process in Task Manager. This is what is making the fan turn on.

While trying to figure out what was going on, I found that this was also a problem with 2.6.

Since this has been a bug acknowledged by ESRI for over two years and three releases, I am wondering if staff know what I can do about it beyond just killing the process whenever I hear my fan turn on.

Also, is this something you guys might fix some day?

[ErikLash4]

I'm seeing it. Pro 3.0.1. Reboot but not start Pro. ExcelToSQLite64.exe consuming 30+% of CPU on zombie processes + add another 30% of CPU for endpoint virus scanning of whatever IO activity it's creating. Manually killing ExcelToSQLite64.exe also ends the virus scan activity.  CPU drops back to normal.  Win 10 Dell Latitude 7212 Rugged Tablet.  Random trigger is best guess on this workstation - ArcGISIndexing service?

[LyleMariam]

I agree that it appears ArcGISIndexingService may be the process that triggers the issue. I'm doing further testing but preliminary results seem to point to killing ArcGISIndexingService FIRST and then killing the ExcelToSQLite process last. While I haven't done exhaustive testing, it seems as if the order in which you kill the processes is important to stop ExcelToSQLite from rising from the grave automatically. PaulSchrum1 created a command line process to kill them but it is inconvenient to use. When I get some spare time, I'm going to take his command line VS program and turn it into a Windows based program to make it easer to run without having to create a batch file to initiate it.

[LyleMariam]

I started ArcGIS Pro this morning and ExcelSQLite is sucking up 12% of my CPU, when I haven't done anything but load the program. At least I'm not on battery!

[PaulSchrum1 · Accepted solution]

I see a lot of people are having trouble with this. The problem is compounded that ESRI support can't reproduce it, and some people do not have the liberty to roll back to 2.9.

With that in mind I developed for myself* a C# console app which kills the process IF AND ONLY IF Arcgis Pro is not running. It checks every 30 seconds, though this timespan is customizable. This console app takes no CPU time except when it wakes up and checks whether the process is running. The repo may be downloaded from

https://github.com/PaulSchrum/TaskGuardian

The license is Apache 2.0. (Everyone can use it for free.) Please read the Readme file at that repo for more information, including usage instructions.

You must have VisualStudio in order to build the code from source. Also, I am regrettably unavailable to provide any support for this app. 

* I developed it for myself months ago, but I am sharing it with the community now because there seems to be a need for this.

- Paul

[LyleMariam]

I'll give it a try. In my case if I use TaskManager to kill it, the program restarts almost immediately. Are you doing anything beyond killing the process?

[PaulSchrum1]

Yes. It also kills "arcgisindexingserver", which I believe is the real culprit (the one that restarts "exceltosqlite64" so as to help you.) Also, notice line 11 of KillProblemTasks.cs.

private static int timespan = 30 * 1000;

That sets it up with wake up and check the processes every 30 seconds. If you need to do it more often, you can change 30 to whatever time increment you like.

[LyleMariam]

I've built your solution, thank you, and it's currently running. I had ArcGIS running and so will watch for it to time out and see if it does the trick. ArcGisIndexingServer is currently running also and will see what happens when your program fires. I never noticed ArcGisIndexingServer before as it doesn't use any resources to speak of.

You might want to add a WriteLine to send a comment to the terminal that everything is ok since it doesn't appear to tell you that both processes are not running.

If this works, I'll try killing the two from TaskManager which should do the same thing.

Thanks a lot for pointing out ArcGisIndexingServer as I would have never found it before.

[LyleMariam]

Just realized you had already included a statement to tell you it was running and not finding anything. I've uncommented the statement and recompiled the program.

Thank you again 🙂

[LyleMariam]

Paul,

I've downloaded TaskGuardian and have a couple of questions:

1 ) The statements to kill ArcGISIndexingServer are commented out? Did you forget to uncomment them?

2 ) The code only searches for 64bit versions. You need to search for 32bit also.

3 ) From my minimal testing it appears that you should kill the indexing server first as it is the one which spawns the ExcelToSQLite process.

When I get a chance, I'm going to see about translating your code into a Windows version to make it easier to use, especially for those who did not grow up with DOS. 🙂

[PaulSchrum1]

Hi Lyle,

Thank you for your comment.

I did not "forget" so much as I left the code there for you (or anyone else) to uncomment if you so choose.

I am not able to provide support for TaskGuardian as I am a full time student. I wrote it for myself, then when I saw a lot of people were having this problem and ESRI support staff were unable to reproduce the problem, I decided to share it "as-is". I have reverted my machine to 2.9 for other reasons for the next few months, so I don't actually need TaskGuardian any more.

But it is licensed as Apache 2.0, which means you or anyone can make whatever modifications you like to your own version. The idea of killing the Indexing Server first is a good idea, but it would be yours to implement.

Regarding the creation of an exe, I chose not to do that as exe's posted in public can have malware inserted into them. By posting just the code and the solution, I make it so you can see that there is no malicious code, and so you can create your own exe, which you then have responsibility for. So I recommend you build from Visual Studio, which creates the exe under 

%yourDirectory%TaskGuardian\bin\Release\netcoreapp3.1 as TaskGuardian.exe.

You can take that exe and move it wherever you like, and you can even make it be a Windows startup task. That is all as-you-like and as you have permission from your employer. But I can not accept any liability for what others do with this as-is code, and I can't take my student time to support others. It is really ESRI's responsibility to deal with the underlying problem, and I have made TaskGuardian public for other's convenience.

Thank you for understanding my situation.

- Paul