CF 11 Update 15 - CF ODBC server no more starts

[brahms_x01]

After installing the latest update hotfix 15 (see ColdFusion 11 Update 15 ) on our coldfusion 11 server (Win 2008 R2 with latest patches and latest java jdk) the CF server restarts (access to CF admin is working) but the CF ODBC service does no more start. After un-installing the update it works again. Any idea how to fix this? Is this a known issue?

[brahms_x01]

Dear Dave,

we are working mostly with MariaDB but also have some MS access databases in use due to customer restrictions. We have bought the license of a product supporting ODBC connections. Now it is no more working, but I do not assume that we will get our money back...

Manuela

[Dave Watts]

I would look for the native JDBC-JET driver that's around somewhere. It used to be included in earlier versions of CF, and I suspect it's still around somewhere. Also, you might look at the msvcr71.dll mention above - that might fix your problem directly.

I'm not saying that this isn't Adobe's fault, of course, but I am saying you might be able to find a workaround before they provide a solution.

Dave Watts, Eidolon LLC

[brahms_x01]

Dear Dave,

sure, we have used the workaround with backing up msvcr71.dll and copying it back after the update and restarting all CF services. Doing the update 16 the same issue came up (besides the problem that the installer also deletes all scheduled tasks). I can't understand, why such easy to discover issues are not found during internal tests before officically publishing the update. Looks for me like there are no tests implemented in the development process.. If customers complain about such an important issue I expect a reaction after several months (and multiple times triggering Adobe). But nothing happens. If we would act like Adobe in this case we would loose customers I am sure. We loved the product in the past (since mid of 90ies) but now we are very unhappy with it.

Rgds

Manuela

[CFDKrunyan]

Saw the post about it removing the neo-cron.xml file so I made a copy to put back after the update 16 install.  stopped CF after the updates was installed, copied the saved neo-cron file back where it belongs, started CF back up and it rewrites the file back to a 1K file.  All tasks deleted.

[Dave Watts]

That should really be in one of the scheduled task threads, not here, I think. There was a suggested edit to make to neo-cron.xml before copying it over, if I recall correctly. Did you do that?

Dave Watts, Eidolon LLC

[CFDKrunyan]

Yes I did copy the neo-cron.xml file.  Was just letting everybody that saving and restoring the file after the update does not fix the issue as CF rewrites the restored file to basically a blank file after starting CF.

[tbarroqueiro]

I have also confirmed that on CF 11 this also resolved my issue(moving msvcr71.dll file)

One other quirk I came across in this update, also related to an issue I saw on a previous update(I believe from April).  At that time a couple of our application start seeing odd behavior, I don't recall exactly what the symptoms were, but through troubleshooting we found out it was an issue with AJP connector settings.  We had to add packetSize="65535" to that connector setting in server.xml.  With this update, it added that setting, so we had a double [acketsize in the ajp connector and was causing a service is unavailable.  I removed the double setting and everything is fine.  this may be something specific to our setup, but thought I would share, in case anyone else has the same issue.

[Charlie Arehart]

tbarroqueiro, that's curious to hear. First of all, it's rare that a CF update would change any current wsconfig entries, though it's possible.  That said, I don't see that the update changed MY  wsconfig entries for CF11. Are you sure it's the update that added that duplicate entry? I suppose you can't look at the file now to see when it was updated (because you updated it in removing the duplicate). but at least this stands for others to watch out for.

And if somehow the CF update DID add that entry, then we could CERTAINLY argue that it should never just add it, but make sure it's not already there.

[tbarroqueiro]

Charlie, I should have been more specific, it updated the following file: c:\Coldfusion11\cfusion\runtime\conf\server.xml

[Charlie Arehart]

Ah, ok. Thanks, tbarroqueiro . Sorry I didn't think of that myself.

So first, I can confirm that I do also see the server.xml having been changed to add that packetsize argument for both the ajp connector and for the tomcat (built-in) web server connector.

And again, I would argue strongly that if the updater just plunked that in without checking first that it was already there, that is definitely wrong. Hope Adobe will fix that.

Worse, I see that they did this not just with the CF11 update but also the CF2016 and CF2018 updates that came out last week. So this issue will affect anyone who has put that packetsize attribute on their connectors in server.xml, before running the update. (I have not yet myself confirmed that it makes a duplicate but am going based on your confirming it.)

Finally, I don't see any mention at all of that in the update notes (or release notes for them) for the 3 releases updated last week. Adobe folks need to attend to these issues.

[Guest]

We're having the same issue on two different servers.  Both Windows 2008 R2 running CF11 HF14 updated to HF15.  I followed the same process I've always followed.  Stopped all services, used a copy of the installer downloaded from the Adobe Support page, java -jar installer.jar, and installed into our CF folder.  Afterwards the ColdFusion 11 ODBC Server service fails to start.  The log output of what was going on was absolutely useless.  Nothing in the normal cfusion\logs about the service failing and also nothing in the cfusion\db\slserver54\logging folder either.  The Windows Event Logs about this were also useless stating it exceeded the 30000 millisecond start time when it fails immediately.

A timeout was reached (30000 milliseconds) while waiting for the ColdFusion 11 ODBC Server service to connect.

The ColdFusion 11 ODBC Server service failed to start due to the following error:

The service did not respond to the start or control request in a timely fashion.

I had tried running it from the command line and found the same MSVCR71.dll is missing error as well and was coming here to post about it but luckily found this thread.  I also used a merge/compare tool against this folder and the backup and I see several other exe/dll files were updated the only file removed was the MSVCR71.dll but there's a new vcruntime140.dll in the folder too.  So I fired up Process Monitor and watched that folder and that does expose the calls to MSVCR71.dll failing.  I copied the DLL back over from a backup and as others have found it now starts.  However during the startup sequence nothing at all calls vcruntime140.dll though.  Maybe something else was compiled against it in this folder but it clearly wasn't swsoc.exe.  This feels like a "it worked on my development machine, ship it" issue and it wasn't tested on other platforms.

I also just did a SHA1 hash against what I had downloaded them versus downloading the update again right now and they're identical.

[Charlie Arehart]

Brentil, thanks for your confirmation of things.

BTW, the discussion of the checksums was more about the CF11 installer (not the updates being applied), in case there may be a difference to explain who does and does not have the problems that some are seeing, even on Windows Server editions.

And FWIW, I offered the MD5 hash rather than a SHA-1 hash simply because on some Adobe pages, that's what they have used, such as Adobe - ColdFusion Support Center : More Downloads . But those are not for CF installers, per se, but "related installers". Again, Adobe no longer offers the CF11 or 2016 installers publicly. I'm also not aware of any public listing that remains with the checksums of the various CF installers that have existed.

Again, I shared the md5 hash of the CF11 Windows 64-bit installer I used (and how to obtain that hash), just so others with the problem could do the same, as we might find that people with the problem used some particular installer (of the variants that existed over the years). I discuss this more in a follow-up blog post I did yesterday based on all this:

https://www.carehart.org/blog/client/index.cfm/2018/9/20/how_to_get_checksum_on_windows 

[Guest]

If you have PowerShell v4 or newer you can also use this method to get MD5 hashes.  I ran it against the installer I had from when we had installed CF11 years ago.  I also ran the SHA1 of it to compare against what brahms_x01 had done above and our hashes match theirs for that version.

Get-FileHash -Algorithm MD5 .\ColdFusion_11_WWEJ_win64_20150721.exe

Algorithm       Hash                                                                   Path

---------       ----                                                                   ----

MD5             5187DB89496BE4CD97B4503E31D6487E

Get-FileHash .\ColdFusion_11_WWEJ_win64_20150721.exe

Algorithm       Hash                                                                   Path

---------       ----                                                                   ----

SHA1            B76771D30DF094EEF5E16AE17B8621FF8D65DB92

I was running the SHA1 against the jar file because that's the default Get-FileHash does unless specified and as validation I didn't have a corrupt patch I had previously downloaded.

[Charlie Arehart]

OK. And I can confirm that was the same md5 hash I shared above for my version of the CF11 installer. Again, perhaps this info may help Adobe as they try to recreate the problem, to resolve it. But as you said, it could have nothing to do with the installer version and is instead just a mistake in the updater. Time will tell.

[woddel]

hia all.  just as a quick throw between: i had the same issue on coldfusion 2016 also.

i updated 5 servers (four on windows server 2012 r2, one on windows server 2016) and it failed to start odbc server on two of the windows 2012 machines.  the other three where fine...  reverted back to update 6 and all was fine.  i will look into this later in detail (and read in detail through this thread).  but i wanted to mention that coldfusion 2016 is also affected.

ah, and yes.  one coldfusion 11 on windows server 2012 r2 also failed (only cf11 we still have).

[Guest]

FYI this issue happens with the new CF11 HF16 update again.  I had to copy msvcr71.dll back over again from another backup.  The HF16 installer does not backup this file before removing it so it will not be in the hf-11-00016 folder.  So you will need to back it up before updating, get it from another backup, or get it from another server not updated yet.

[bw_bloodletter]

This is also happening on CF 2016 Update 8, FYI.

(I've had other issues installing CF2016 Update 8 as well. Going through CF Admin looks like it works, but ALL data sources ended up broken.  Doing it manually as a member of the administrators group via CMD throws an error about not having write permissions or the ability to start/stop services.  I've verified I explicitly have the proper permissions, of course. And I've tried a regular CMD prompt and an elevated one. The only thing that go it to work was running it via the local administrator account directly, which is against our normal practice.)

[marcusl31502287]

This is also happening for ColdFusion11 update 17.  Copying the file ' msvcr71.dll '  into location mentioned above resolved issue. This is with Windows 2012 R2 Server.

Restarted Server and ColdFusion ODBC service restarted too.

ColdFusion installer hashfile same as above - see Brentil

Had none of the above issue in Windows 10, btw

[Charlie Arehart]

Marcus, the new updates (like cf11 u17) did NOT indicate having fixed the odbc issue. (You seem to have assumed they did.)

The odbc issue is STILL listed in the known issues for the update, including a suggestion of how to manually resolve it.

https://helpx.adobe.com/coldfusion/kb/bugs-fixed-in-coldfusion-11-update-17.html#knownissues

[Guest]

However at least now it is in the Known Issues area, the backup of the install backs up the DLL, and Adobe has stated they're in conversation with the vendor to discuss what's going on.  So progress!

[topshotrhit]

Why is this STILL an issue in Update 18?!?!?