Solving a new problem as of CF2023 update 25 that can cause CF to not start

Hi Charlie, thanks for this post. Your short-PATH workaround does fix the initial Java instrumentation startup error on my server.

I’m running ColdFusion 2023 Enterprise on Windows Server 2022, using an AWS Marketplace AMI supplied by Coalesce Solutions, with Oracle Java 17.0.14 and FusionReactor 2026.1.3.

Unfortunately, after getting past the JVM startup failure, Update 25 still fails to initialize ColdFusion’s license service. The first error is:

```text
Unable to install License package:
java.lang.NoClassDefFoundError: com/adobe/asneu/AsnException
```

The crypto and security services then fail because `LicenseService` is null, and the ColdFusion Administrator returns HTTP 500. This happens both through the Windows service and when starting directly with `cfstart.bat` in PowerShell using the short PATH.

Update 24 works correctly, and rolling back Update 25 restores normal operation. The update installer reported success, but reinstalling U25 reproduces the failure.

We searched the installed JARs and found `AsnException.class` inside:

```text
C:\ColdFusion2023\bundles\repo\flex-messaging-data-req-4.0.jar
```

So the class exists on disk, although it apparently isn’t accessible during license-service initialization. The installer log also mentions operations involving both `cfusion-req.jar` and `cfusion-req-cloud.jar`.

Given the Marketplace origin of this installation, I wonder whether this second failure could involve the cloud-specific licensing implementation or class loading in the Coalesce AMI. That’s still a hypothesis.

Have you seen this additional failure on AWS Marketplace installations, particularly those supplied by Coalesce Solutions?

Hey Charlie,

I ended up installing CFU25 the day it came out, and ran into this -- and implemented the temporary solution of adding the path to the windows environment vars PATH var and it worked. I also had to do a quick workaround in our powershell scripts that are executed via CF, because the full path was not available to them either.

I hate editing the registry, especially on servers, if I don't have to. And certainly not for something that is ultimately (IMNSHO) a bug that should be fixed ASAP. So... do you think Adobe will treat this as the bug it is, and issue a patch or update for it, so that we can revert our temporary workarounds eventually?

Charlie, thanks for this update! Not sure if I should be happy I found a bug or not, ha! We'll be looking into our options and deciding how we are going to proceed, and definitely look at your approach first.

@ctobey, to be clear: yes, the whole point of this Sep 29 post (that you're commenting on) and its offered workarounds was to ALLOW you to put FR (or any other monitor causing the problem) back into the CF jvm configuration (typically a javaagent, yes).

In fact I mention that at the end of each workaround. But in case someone else somehow could misconstrue things I have just added a few more words to the end of the opening paragraph. :-)

I see the challenge for you is that you have a DIFFERENT problem. You say that you put the FR javaagent "back into the jvm.config...and CF would then start fine. However, FusionReactor Instance still will not start."

So first, since your CF is now starting (with FR in place) but you don't say you applied either of the workarounds I propose in this post, I'm wondering: is your CF on something other than Windows? Perhaps Linux or Mac, or a container image, or in CommandBox? None of those had the problem I describe here, nor did they need the workaround I propose here.

In either case, since your CF is running but you say "FusionReactor Instance still will not start", do you mean the FR UI for the CF instance, like the default at port 8088? Or might you mean the FRAM instance, at port 8087? I just want to be clear.

Assuming you do mean the FR UI for the CF instance (like 8088), that can fail to work (even though CF starts, and when you have put the javaagent back in place) for any of a few unusual reasons, but they have nothing to do at all with what I describe in this post.

I would recommend you look at the startup logs for CF (coldfusion-out.log, coldfusion-error.log, or as shown on your terminal if started there) to see if during the startup you find it reporting a problem in its attempt to start FusionReactor. To be clear, FR runs INSIDE of the JVM alongside of CF. It's not a separate process. So if it fails to start then it's something you'll typically find logged in the CF startup logs.

And when you see the error, before you may share it to ask for help, just google it. You may well be shown a solution for that, which is documented by the FR folks. (There's one particular scenario I've seen where you're told to delete a folder deep inside the FusionReactor directory for the CF instance.)

Or another situation could be that the user running CF doesn't have permissions to modify that directory for the CF instance, within the FusionReactor folder. But since you imply things were working BEFORE the CF update, we should presume that is NOT your issue.

Finally, if all this is too much to try to connect dots/understand here in the blog comments, I'll repeat that this is the kind of thing I could likely help solve in less than 15 mins together in a consulting session. I realize some may feel they "can't get permission for such assistance", but honestly we can usually solve things SO much more easily in looking together rather than "playing battleship" in comments. :-)

But that's not directed to you specifically, presuming what you may feel. I say it for the sake of others reading along. Regardless, I'm here: ready to make the next move here in the comments. Hopefully we can "sink that battleship". (I'll take "dated 70's board games for $200, Alex". :-)

As someone who is running CF2023, on Windows as a service, with FusionReactor... it again pays to have put off an update from Adobe until after Charlie has issued his own Adobe-created-issue workarounds :D You likely have saved me a couple hours of headache when I get around to installing this update.

Going back to Paul's' kind comment of Friday, I should have added (in my reply of thanks) that I hope what he said was a BIT tongue-in-cheek ("it again pays to have put off an update from Adobe until after Charlie has issued his own Adobe-created-issue workarounds").

As I've discussed in the past security updates, it's important these days to not wait "too long", as there are bad guys who "take apart" each update to determine "what was changed"...so that they can attempt to exploit the vuln against those who have NOT yet applied the update.

And while some "good guy"/white hat hackers might do the same to try to warn folks of what to beware, that's not true for every update--and they are often not very detailed in their reporting of how to effect the exploit. It's always a balancing act for them.

And it's one for us, as well.

Marlon, that's not some problem unique to u25. There can be many reasons the add on service won't run, of course. But specific to updates, some folks have found that their cfusion/jetty folder can be missing a lib subfolder after cf updates. That shouldn't happen, but it has (though never to me).

While I've helped others recover, beware of simply restoring that folder from the "backup/jetty/lib" found the cfusion/hf-updates folderfor your u25.

That may seem to "work", but it's incomplete: there are still other jetty files that need to be restored. It also loses security improvements intended by updates to the folder (again,you're restoring from a backup cf took BEFORE that update).

The BEST thing would be to copy things from a working cf2023 u25 folder. That can be attempted on another machine.

I'll say I can help via a remote consulting session, likely in less than a half hour--though I can't commit to that. For more on my rates, approach, satisfaction guarantee, online calendar, email, phone, and more, see the consulting page at carehart.org.

Matt, thanks so much (and apologies everyone)!

Corrected--and noted also in the "updates" section of the post.

Salvatore's comment here refers back to the very first one offered above. And he's now confirming that the problem he faced (one not solved by but also not CAUSED BY my workaround) was indeed unique to his running the cf AWS AMI (as I had anticipated in my reply to him that day)

So first, thanks for sharing what you had to do, recovering a jar from the update's backup folder. Before asserting that everyone (on the AMI) would need to do that, I'd asked if there were any errors in the update logs. Assuming there were none, then yes we can let this stand as something others on the AMI may face in applying the update.

Only time will tell if it's something folks may need to repeat on subsequent updates, if Adobe doesn't solve the root cause problem for that. But to be clear, readers, this other issue seems ENTIRELY unrelated to the matter in this post.

Finally, as for his ALSO suffering the FR/instrument library problem, he shares that he opted instead to follow Adobe's suggestion to modify the system path, rather than the service definition tweak I propose here. He acknowledges that has the potential negatives as I'd outlined, but it's true that on an AWS AMI that's used for nothing BUT running CF, the risks to other apps of modifying the system path that way are less of a concern.

Even so, the other risk remains: if you later modify the cf Java home to point to a different Java version (such as for the Java update that Oracle will release the week after next), then you will HAVE to modify that system path to replace that Java home location if it changes. Otherwise cf startup will again fail, but now for that other error I noted in the post.

Forewarned is forearmed. Or, "don't say I didn't warn you", folks. :-)

Charlie, can confirm the latest update fixed the problem of CF no start on Windows. Thanks for confirming here!