[Looking for Charlie's main web site?]

CF911: 'Help! I've updated the JVM which ColdFusion uses, and now it won't start!'

Note: This blog post is from 2014. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Has this happened to you? You wanted to update the JVM which CF uses to use a new version...
  • so you found some resource on the web showing how to update, and it seemed simple enough
  • and then you tried restarting CF and wham, it won't start, or the admin won't open, or code starts failing
  • and maybe it's that things didn't fail immediately, but within hours or days folks report things breaking since you made the change
  • and now you're stuck wondering, "what happened? and how am I supposed to fix this?"

It's a tough position to be in, and tragic of course if CF won't start. But no, you do NOT need to reinstall CF!

Often it's just one thing you did by mistake, though there are indeed several possible reasons why your attempt to update CF's JVM can fail or lead to unexpected problems. And as you google about, you may find all kinds of helpful but often misinformed or spartan suggestions that may or may not help much.

So I offer here over a dozen of things you can and should consider/look at, some of which you may quickly recover from or be able to undo (depends on what you did). And all this applies to Lucee, Railo, and BlueDragon as well, though folder locations will differ.

If you're facing this bind right now, you can skip over the following to the the section, "So what went wrong?", where I present each likely problem and solution.

[....Continue Reading....]

Nice article Charlie. You covered, almost all possible scenarios.
# Posted By Anit Kumar Panda | 12/11/14 9:25 AM
Though a bit tangential, what about ODBC datasources in Java 8? I heard that the JDBC-ODBC bridge is no longer supported in Java 8, so will we lose access to legacy dsn's with a Java 8 upgrade?
# Posted By Andy K | 12/11/14 10:45 AM
Excellent write up Charlie! I've learned most of this through trial and error over the years and not much of it is "obvious" or "intuitive" to the typical CF dev. It's important to note that you won't get anything in most of your CF logs because without a JVM, the logging libraries can't even load! The "out" log may be the only one I've seen messages actually in for JVM load failures. Otherwise, you've got to start CF from the console which is also outside of most people's usual debugging toolset.

I think everyone should have to pay you just to read this article. Who says you're taking them for a ride when you put this much info out there for free? :)
# Posted By Brad Wood | 12/12/14 1:28 PM
Superb post as always Charile.

Just to add a further scenario I encountered the other day on my 64bit dev machine on which I use the 32-bit version of CF9 (due to installer issues).

I'd updated the 32-bit JDK and all was fine. Then I installed a 64-bit public JRE for another app, and again all seemed fine. The next time I restarted CF9 though, it failed.

I knew it was JDK related because my CF Solr service uses the same JDK as CF (good tip btw - do it in the solr.lax file) and that wouldn't start either. Uninstalling the new JRE and RE-installing the 32-bit JDK solved the issue. Some sort of corruption going I guess.
# Posted By Julian Halliwell | 12/13/14 4:06 AM
Julian, thanks for the kind regards and sorry that I missed this when you posted in December.

You do bring up a good point about JVM updates for CF and for other things, including Solr which runs inside CF. First, you mention the solr.lax file and that was indeed its name (in Windows) for CF9, but for CF10 and up, it's the jetty.lax file (in the [cf10]\cfusion\jetty folder (or instancename\jetty if using multiple instances).

Second, most will find that it has a line/argument (lax.nl.current.vm) which points to the JVM within CF (C:\\ColdFusion10\\jre\\bin\\javaw.exe, in the case of CF10 on Windows).

(In Linux, instead, you would edit the \opt\coldfusion10\cfusion\jetty\cfjetty file, and find the line, "SOLR_JVM="/opt/coldfusion10/jre", again as of CF10.)

Just as has been related in the blog entry above, about how if you change the JVM which CF uses you need to also consider related changes to the keystore, there is a similar connection between the JVM which CF uses and the one that Solr uses (assuming you're using the Solr installed with CF).

If (as it does by default) the Solr configuration points to the JVM *within* CF, then if you change CF to point to another JVM, then they (CF and Solr) will be out of sync with respect to JVM versions, which has caused some folks problems.

And then you are pointing out yet another problem: you refer to a "public JRE" that you installed. For those familiar, this is the terminology used by the Java installer as an option you can enable or disable at installation, and it's enabled by default, whereby the java command can run from anywhere on the machine (in any path) because the java.exe (in Windows) has been added to the path environment variable. That doesn't affect CF, since it points to the JVM it wants to use (in the jvm.config's java.home line). Even so, I tell folks not to implement the public JRE for the very reason you mentioned, where one thing depending on it didn't like the new version you installed.

As for Solr, though, as was just stated above it uses the JVM as indicated in the .lax file and lax.nl.current.vm line (for WIndows, or the cfjetty file's SOLR_JVM line in Linux).

So as for things breaking when you DID install a new JRE, I wonder: did you perhaps put it in the same location that CF (and Solr) were looking at? If you point the installer to a given dir, like \java\jdk_xyz, that wouldn't distinguish if it was a 64- or 32-bit jvm, and so if CF running as 32-bit had been pointing to that for a 32-bit jvm and you updated that location to have a 64-bit one, that could have explained your problems.

Hope that's helpful.

At least, though, I do hope that readers of this blog post will take to heart the realization that if you tweak the JVM for CF to point to some newly installed one in a new location (as recommended above), do beware that by default the Solr config within CF will point to the JVM that CF *came with*, and YOU need to change it to point to the new location, just like you told CF to do.

(And all this is because the Solr configuration within CF really runs its own JVM, its own process: jetty. BTW, this same Jetty process runs not only Solr but also in CF11 the new PDFG feature, for "pixel-perfect PDF generation" by way of the new CFHTMLtoPDF tag. If folks start hitting memory, heap, or other problems, this could be the root cause of those problems, too.)
# Posted By Charlie Arehart | 3/21/15 11:21 PM
Fantastic blog post, thanks! Solved all my problems - had been struggling to update my JVM for hours, but your note about the MSVCR100.dll solved everything! Thanks.
# Posted By James | 8/21/15 8:36 AM
Very good to hear. Thanks for the kind regards, James.
# Posted By charlie arehart | 8/21/15 9:26 AM
I have updated per your instructions and all works well. I am trying to follow the CF11 lockdown guide and when I check the J2EE session variables box located in the Memory Variables page, CF11 will not start. I am using Windows Server 2008R2 64-bit with ColdFusion 11 64-bit with Update 7 applied. Any suggestions would be appreciated.
# Posted By Susan Hurst | 12/10/15 7:18 AM
Fixed the issue after three days of searching. You need to uncomment out the following tag in runtime\conf\context.xml = <manager pathname=""/>
# Posted By Susan Hurst | 12/10/15 7:41 AM
@Susan, thanks for sharing your observation. I'm glad that you found your solution 23 mins after posting the problem here, though I am sorry if this was the 3rd day of searching.

I would have pointed out the same xml entry as a possible thing to consider, since you said the problem started when you enabled J2EE sessions.

As for why it was commented in the first place, I would suspect it means that you had a CF11 installer which had been released in early Dec 2014 and obtained before mid-Jan 2015 when they created a new one that fixed the issue. This was blogged then:


It also mentioned the option of just changing that xml line yourself. There were other blog posts on it at the time:


It also led to another problem, about securerandom, outlined here:


which also pointed to either changing that XML or getting the updated installer.

Of course, I realize that before you found the solution, you may not have thought to use words to search that would have led to these. I'm pointing this out as much for others who may see this.

But also, finally, you may want to go get an updated CF11 installer, so that you don't cause the problem again if you ever need to reinstall, or use it to install on another server.

Does this seem on the right track?

For instance, do you know when you downloaded the installer? If it was more recently, that would beg a new question of why that xml setting was commented out for you.

I'll add that you or someone there could have done it, in considering the idea of using session persistence in Tomcat. That's what commenting it does. And if it had been changed in the past, perhaps as part of some testing, it would not have taken effect until you DID turn on J2EE sessions.

And that's what caused your problem when you restarted, if it found many sessions to be persisted (perhaps thousands or more). And those may have been persisted either when you shut down (after changing to use J2EE sessions), or the persisted sessions may have been left over from when that was last done (commenting that out and having J2EE sessions on) some very long time ago.

Let me know if this is helpful.
# Posted By Charlie Arehart | 12/10/15 3:42 PM
Charlie - thank you for getting back to me so quickly. I checked my download that I was using and it is from December 2014. I have gotten a new download from Adobe Website so hopefully I will not have this issue in the future. The websites you provided were also very helpful and informative. Again, that you.
# Posted By Susan Hurst | 12/11/15 11:22 AM
Ghaaa - this helped completely for addressing the "you need TLS 1.2" - easy update following your approach to explaining installing updated Java. Knowing you had outlined all the exits from it going bad, I had full confidence running the update.

Thank you!
# Posted By Stephen Cassady | 8/25/16 2:45 AM
In the style of Charlie Arehart, here is a SHORT ANSWER I want to warn any Mac users out there about (the long answer will come when I get some more time).

If you are on a Mac, CF9 is HARD-CODED to use the last "Apple-Blessed" version of Java, which is Java 1.6. You can install 1.7 or later, and even follow these instructions to point the CF JVM to the new version in the Admin. But if Apple-supplied 1.6 is not there, you will get a "missing software" error on CF start-up.

More details can be posted if anyone wants them.
# Posted By Troy Allen | 8/15/17 11:50 AM
One more heads up for mac users... you might need to:
SUDO ./coldfusion start
# Posted By Jonathan Hayes | 2/1/18 2:25 PM
Thanks, Troy and Jonathan, for the additional notes for Mac users.
# Posted By Charlie Arehart | 2/5/18 1:29 PM
Copyright ©2020 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting