OK, I have an update. All's working for him now. There were a few issues, and they may interest some.
The TLDR is that first, a valuable JVM error message that would normally be shown via the command line was NOT being shown to him via powershell. And that JVM error (once we could see it) required copying a needed jvm DLL from his jdk into CF. Once fixed, since CF had been changed (for security) to run as a limited function user, it still would not run from the command line (unless that was launched "as admin"), but then things DID run as a service. Yay. And then there was a root cause reason for why CF was initially failing that led him down the rabbit hole of updating the JVM that CF uses.
For those interested, read on.
First, while some of the things he encountered were indeed covered in my blog post on troubleshooting errors when changing the JVM that CF uses, one was new to me--and I have updated the post (and in thanks for that as a lesson learned, I did not charge him for my time). And we did initially make sure the problem was not about the bit-level of CF vs that of the jvm (see more in my blog post), etc. There were basically 3 things wrong.
About the "discovery" for me, Carl had above recommended here (as I do in my post) that for the sake of diagnosing the problem he should run cfstart from the command line, to see what it may report. That so often WILL give the answer of what's amiss. And he HAD done that. But note above in his his screenshot that he opted to do that via powershell rather than the windows command prompt.
Well, as I always do in cases like this, I had him run the cfstart via the command prompt instead, and sure enough we got a popup error that he was NOT seeing when he had run it from powershell (that was new info for me).
And the error was about a missing vcruntime140.dll. That IS something I cover in my post. His new jvm was very new (1.8.0_281) compared to the original jvm that his CF 11 originally came with (1.8.0_25). We copied that dll from his jdk/'s bin folder and placed it in his cf11 cfusion/bin folder (more details in my post).
And now CF did start (from the command line). Touchdown...but wait, "there was a flag on the play". š
I noticed there were errors showing in the console. And those turned out to be permissions errors. FWIW, in our attempt to just run the cfstart from the command line, we had not thought to run the command line "as admin" (I do suggest that in my blog post, but I just hadn't thought of it when I had him open it this time. I suspected we'd get some more clear error related to the JVM, as we did, and that would indeed happen even if not run "as admin".)
As soon as I saw the permissions errors I had him look at the Windows Services and the CF service. Sure enough, someone in the past he (or some vagrant config script he thinks) had changed the CF service to run as a new cfuser. That's a good thing for security reasons, of course, and the CF Lockdown guide recommneds it.
The problem is that while that cfuser had permissions to the CF folders, his user that he was logged in as (vagrant) did not have those permissions. (Again, I discuss this matter a bit more in my blog post, also.) And that then is why we were "close, but no cigar".
The simple solution to that was that we now tried to start CF as a service, and with the JVM and DLL issue resolved, ta-da: now CF worked!
Finally, as for what caused his initial problem (that led to all this), it was a classic one, which many can learn from, and again which I cover in my post. In brief, it was this.
As he said at the outset above, in recent weeks he had gotten the java popup (in the Windows status tray) offering to update the JVM, and he took it. And that had offered to remove any old JVMs. Again, that's a good thing. The problem is that unbeknownst to him, one of those was the one that CF had been pointing to. (Someone or again some script had previously updated CF to point to a newer jvm than had come with CF itself.) And in that situation, that JVM removal process would try to remove JVM that CF was pointing to, but since CF was running, that removal would only be able to delete most but not ALL of the JVM's files. That's bad enough.
But sadly, one only notices that this has happened when they later restart CF (which may be hours, days, or weeks later), when you find that, crap, CF won't start.
As for that java prompt offering to update itself, it's worth noting that it only enables itself if you either install a JRE or install a JDK (in version 8 or earlier) that offers to implement a "pubic jre". This is in fact why I recommend NOT using a JRE (or NOT letting a JDK installer implement its offered option to implement a "public jre"). I mention this in my post also, but I then did (and point there to) a more specific post on this: Why you should think twice about leaving on the "public JRE" option of the Java JDK installer .
As I told him, it's not that everyone hits such problems when they update the JVM CF uses. It's just that in SOME situations they may well hit these various problems. Again that's why I have that encyclopedic blog post, CF911: 'Help! I've updated the JVM which ColdFusion uses, and now it won't start!'. Not everyone needs it, and not everyone will read it all, but it's there in the hopes of helping people who have been hitting problems like this for about a decade. š
Glad we were able to get him going, and hope his lessons learned may benefit others here
/Charlie (troubleshooter, carehart.org)
17
Replies
AdChoices