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?
Solved! Go to 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
Follow up. I just noticed ExcelToSQLite64 stills activates itself. All that is required is for Pro to have been opened some time since the last restart.
We resolved a variety of the ExceltoSQL64 gremlins today by applying the AccessDB update referenced in this permalink: Solved: Re: DO NOT update to 3.0, Update to ArcPro 3.0 is ... - Esri Community
I don't consider this a solution as you don't seem to have tested for the zombie process case (of this thread). You don't mention it, anyway. It seems to be, "we made a change and we hope it will fix your problem. Good luck with that."
Further, when I look at the "solutions" found at the link you post, I see a lot of "if you have this" and "if you do that". We are not computer scientists, and it should not be the user's responsibility to update a Microsoft app because an ESRI app is misbehaving.
In the mean time, I have written my own C# program which checks for ExcelToSQLite every so often, and if the process is running but ArcGIS Pro is not running, the program kills the process. This is not the solution either, but it keeps my fan from running just because I have opened ArcGIS Pro 3.0 at some time in the past.
You are correct I havent tested the zombie-thread condition. I dont have that gremlin, so I cant. Best I can do is offer you a driver update that has resolved a number of other reported problems with ExceltoSQL64. Its a logical jump that it appears to improve outcomes in the use of ExceltoSQL64. You can install it, or not.
"I dont have that gremlin, so I cant."
You never asked me for steps to reproduce, so maybe you have it and don't realize it.
1. Open ArcGIS Pro.
2. Close it. Wait five minutes (to make sure every process that is going to close closes).
3. Open Windows Task Manager (Processes Tab). Look for ExcelToSQLite64. The problem is noticed here. If you see it is a running task, this is the zombie process. Kill it.
4. An hour and a half after you kill the zombie, check Task Manager again. If you have the same problem I am having, another ExcelToSQLite64 process has been spawned by some other process.
Note about step 4. I don't know how to figure out which process is spawning ExcelToSQLite64 every hour. But whichever process is doing that, that is where the bug actually is.
Note about Step 3. I understand it is inconvenient to wait an hour for a bug to manifest. So perhaps you have access to another computer with AP 3 on it that you can leave to the side while you work on other things.
My apologies for taking a "mansplaining" tone. I am a man, and when I splain things, unfortunately that's how it comes out. I would fix it if I knew how.
We have not been able to reproduce the behavior in steps 3 or 4 above. Our machines, unpatched with the AccessDB update, hang in step 1 if ExceltoSQL64 is invoked and the entire ArcPro process has to be terminated from taskmanager.
Thank you for your reply.
I am abandoning this issue because I have gone back to ArcGIS Pro 2.9. I have confirmed that my issue does not happen with 2.9.
I am supposing that for some reason I already had the AccessDB patch, which would explain why I was able to use ArcGIS Pro 3.0 to begin with though you could not. In your response, you did not mention whether or not you attempted to to exit Pro and look at Task Manager after it closed, so it sounds like you never executed my steps to reproduce.
You should mark this issue as "Abandoned by User" if you have that category as it is a moot point for me now that I am on 2.9. In no case should you mark it as Resolved, Fixed, or Answered. It is none of those, and getting credit for a resolved issue is not indicated for this case.
When I upgrade to 3.x (x >=1), I will check for this again and hopefully it will be fixed by then.
Please close any issue you have opened on my behalf.
"We have not been able to reproduce the behavior in steps 3 or 4 above."
My testing indicates that ExcelToSQLite is loaded during adding a layer from our server to a local ArcGIS project. I used ArcGIS 3.0.0 locally without ExcelToSQLite being loaded. Then after connecting to our server and adding a layer to a project on my PC, ExcelToSQLite reared its ugly head. To be honest, I also exported a layer to a local shape file but forgot to check in-between adding a layer from the server and exporting to local shape file to see which one invoked the program.
@T_Remmert for other reasons, I had to uninstall 3.0 and reinstall 2.9. (The other reason was the .Net runtime change.) After doing that I noticed that the zombie process does not get restarted, not even after two hours. So this seems to have fixed the problem.