SNAP 7.0 crashing on Windows 10

I’m having some issues with SNAP crashing unexpectedly. I was trying to install and update SNAP to the latest version (7.0.4). I first uninstalled SNAP, with no issues, and then I installed SNAP again, using an executable from the Download page. Following the installation, SNAP Desktop opened and asked if I wanted to install updates. When I clicked “Yes” the application unexpectedly closed. I tried a few more times to restart SNAP Desktop and update, but it keeps crashing. I decided to try to install SNAP again, but this time it crashed during one of the last steps of the installation process. Once again, I tried starting SNAP Desktop but it continues to crash shortly after opening the program. Now I am trying to uninstall SNAP again, but I’m getting an error when running the uninstall which says “No JVM could be found on your system. Please define EXE4J_JAVA_HOME to point to an installed 64-bit JDK or JRE or download a JRE from www.java.com”. I suspect this is because the previous installation was unable to complete successfully. the “Program Files\snap” folder was still on the computer, but the Roaming\SNAP folder is now gone. I then tried deleting the “Program Files\snap” folder and installing SNAP again. This time it got through the entire installation again, and SNAP Desktop started automatically, but it crashed about 15 seconds later (no action on my part). I found a messages.log file in “Roaming\SNAP\var\log” which shows some Warnings, but none seem particularly urgent (I can share it if it is helpful). The last line of logging states “Showing SNAP Desktop”.

I restarted again (and it crashed) and now the last line of logging says: “INFO [org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO]: Initializing external tool adapters
console: Failed to install ‘’: java.nio.charset.UnsupportedCharsetException: cp0.”

I restarted again (and it crashed) and this time the logging got further than before and reached “Showing SNAP Desktop”. Each time the logging is a bit different, but none of the warnings seem to be related to the crashing.

How can I solve this? SNAP Desktop continues to crash shortly after opening. SNAP has worked fine on this machine in the past. Is there somewhere else I should look for logging information? Any advice would be appreciated!

Oh, you have quite a journey behind you. I’m sorry to hear that.

I found this thread and the problem described sounds like yours.

The solution was to update the driver for the graphics card. maybe this is also the case for you.
Another suggestion, when you uninstall or install SNAP. Chose the option to remove all data.
image

I would build on top of what @marpet said and recommend that you also manually search your computer for files created by snap. I believe that on windows 10, you should look for a %userprofile%/.snap and %appdata%/snap

You could also use windows search (or a faster search like everything) to try to find any residual files.

Thanks - the IT department said they updated the driver from a VMware Driver to a Microsoft driver, but it was still crashing, so I again tried uninstalling (selecting the recommended option), followed by a search on the entire C:drive for “snap” and deleting a couple empty folders that seems related to SNAP. Still no luck. I’ve asked the IT department to wipe/reset the computer (it’s only used for SNAP testing). Will report whether or not that works.

@nena.v Something else I can think if is to look into whether your are using Oracle Java or openJDK, and which version you are running. I have heard that some programs are affected by that.

@BarrowWight you are right. But SNAP brings it’s own JRE. So as long the default configuration wasn’t changed this shouldn’t be an issue.

I installed SNAP on a new Windows node and the installation went fine, and I was able to update to 7.0.4. It’s not a satisfying solution, since I still don’t know what was causing the problem, or what changed… Thanks for the quick responses!

1 Like

Yes, strange problem. I agree would be good to know what the reason was. But good that it is now solved.