Ignition Designer Launcher - Error launching application: NoSuchFileException

image
I am trying to open the designer launcher, brand new system build. Getting the error message: "Error launching application: NoSuchFileException: C:\Users\IgnitionUser.ignition\cache\resources\runtimes\17.0.10\bin\server\classes.jsa"

Windows Server 2019. Ignition Version 8.1.39.

This system is intended to be a single server installation of reporting functions. We had issues installing from the .msi and ended up doing a manual installation via the .zip and batch. But the Gateway appears to be running fine from the Web Browser. We've made some SQL connections and verified OPC comms to some devices out in the field.

Downloaded the designer launcher straight from the gateway, also tried downloading the 8.1.39 version from the IA website. Keep getting the error. I can successfully use the designer launcher to connect to other systems and open. Tempted to try an older version.

Try deleting this whole folder and relaunching.

1 Like

Same result. Looks like it copies "classes_nocoops.jsa", then fails after. I've also tried putting the "classes.jsa" file in there manually.

Hi Mike,

I'm facing the same issue, any update on this?

I grabbed Ignition v8.1.30 and it worked fine. There's some conflict between the newer version and our server build.

This is sounding a bit like an issue myself and some others had with an Ignition upgrade: https://forum.inductiveautomation.com/t/8-1-35-upgrade-unable-to-extract-ignition-runtime-files-classes-jsa
I think it started with the 8.1.33 bump of the Java Runtime to version 17.
I suspect that the same issue that affected our upgrade is also affecting the clients. What I think happens is that when a client is run it fetches the resources from the gateway and extracts them - and like with the upgrade for some reason the classes.jsa file is immediately deleted.
I've just checked and on the same server we had the upgrade issue on I can't launch the designer
image
I hadn't noticed since we run the designer on our personal computers (which connect to our server).

This isn’t something anyone should be waiting on us to “fix”, this is almost certainly a problem with whatever AV or security software your IT department has foisted upon you.

3 Likes

We're able to connect to 8.1.22 just fine but can no longer connect to one of the gateways after it was updated to 8.1.35. I tried placing the file manually in the folder location, but that location is purged and replaced upon launching a client. We cloned our VM and disabled all firewall activity and AV. We were still unable to connect to the gateway which was updated.

I'm in the same boat - even after disabling all antivirus software we were still having the NoSuchFileException error. That's why I replied earlier, to see if anyone had any insights as to what particular application might cause it or to see if there was anything common in the environments of the people who are having this issue since it looks like it has been a few people.
We use Dynatrace for monitoring in our environment which seems like it might be the culprit. A search for 'Dynatrace classes.jsa' returns a few results which seem to describe similar behaviour to what we've been seeing here. I haven't been able to confirm this yet (I need to check before disabling it) but it seems to be the culprit so far - we're only having this issue on a subset of our gateways and all the ones we're having the issue on run Dynatrace (and the ones that aren't having this issue don't run Dynatrace).
Quick update: It looks like Dynatrace forcibly disables class data sharing to work around an old JDK bug: Loading...

1 Like

It was Dynatrace in the end for us. We added a 'do not monitor' rule targeting processes where the 'Java main class' matches 'com.inductiveautomation.ignition' and the launcher opened without any issues. Monitoring of the gateway should still work because its main class is not in 'com.inductiveautomation.ignition'.
I don't know if this is relevant for anyone else here but I thought I'd mention it just in case. I think the key takeaway is that it isn't just antivirus but also (in theory) transparent monitoring that can cause this problem.
I suspect that anything that disables class data sharing will cause this problem.

4 Likes