Resolving “500 Internal Server Error” with ColdFusion 10 Update 14

We have seen that some of you have not been able to get the web server
connector working after applying update 14.

We did our investigation and following is our finding.

The connector binaries of ColdFusion 10 update 14 are built on top of  VC++
runtime 2012 update 4.

Installation of VC++ runtime requires admin privileges. If the ColdFusion
service runs as administrator or system account, the update itself install the
VC++ runtime as this account would have installation privileges.

If your ColdFusion service account is not running as administrator or system
account, applying the hotfix from administrator can’t install VC++ runtime and
you will get “500 internal server error” after configuring the

In this case, you need to manually install VC++ runtime 2012 32-bit and/or
64 bit depending on whether Web server is 32-bit or 64-bit.

You can download VC++ runtime here at:

When you install hotfix manually, administrator privileges are enforced and
so the installation of VC++ runtime is automatically taken care by the updater.








32 Responses

  1. yet another great update from adobe with numerous issues associated with deploying an update.
    surely you should be aware if the connector is ‘built on top of’ another platform version and should make this clear in your deployment notes

  2. Yikes. Are you telling me the whole QA team at Adobe are running their ColdFusion servers *as administrator” ?!?
    In direct conflict with their own guide ?

  3. Yikes, truly.

    In all seriousness though and as sad as it is, it would probably reflect what the 99.99% of ACF users out there are doing 🙁

    I assume the connector update essentially makes it on par with the CF11 update 1/2 connector. Wasn’t there a connector update on CF11 update 1? I might be wrong – bit if it was, would this problem apply as well then?

  4. I already had the VC++ runtime. While running the install of it again, it shows repair or remove options. With repair option, my server is still giving 500 internal server error. BTW, my CF11 install is locked down per the guide.

  5. There’s a couple hours lost.

    All started with the POS “updater” in CF Admin. Said (2) available updates found, but only option to install CF11 Update 2 (I hadn’t installed Update 1). That hung during the installation process “Checking” something. Reloaded CF Admin, logged back in and tried “Re-install” option. That also hung at “Checking”. Then internal error 500.

    Found this thread, tried reinstallation of VC++ without any change to error 500.

    Tried reconfiguring the WC, no success. Found the following to manually install updates:

    Downloaded CF11 HF1 and ran the following under admin cmd prompt:

    [cfpath]jrebinjava -jar hotfix_001.jar

    Server still trashed with error 500.

    Ran [cfpath]jrebinjava -jar hotfix_002.jar

    using the hotfix_002.jar file found in

    Initial test, server appears to be functioning again, but needs further testing. At this rate, it might be years before it’s considered stable enough to replace productions’ CF9. We cannot have these types of issues applying updates. Why aren’t the recommendations in the lockdown guide implemented during the install?

  6. So every time I have to reconfigure WSconfig, I have to remember to replace the isapi_redirect.dll with the patched version in all the [magic number] sites… where is the latest version of this available for download? I figured it would be included in the updates. Com’on Adobe…

  7. All of them 🙂

    Obviously that can’t happen, but why not script in the request filtering, handler mappings, and custom configuration for whom the CF service runs as? The Secure Profile is a step in the right direction, but so much more could be added to the installation process to implement a large majority of the lock down guidelines.

    As it is now, even the updates (manual method since the CF Admin method doesn’t work) doesn’t take the initiative to lookup the current CF root (which can be found in the registry) and requires me to type it in.

  8. This also demonstrates a gap in your approach to QA. QA of things like installers & updaters should not be done on the person’s own machine! They should be done on dedicated test machines with known states. One of those “known states” should be a bare bones install with no presuppositions about what’s on it.


  9. Rupesh wrote:
    > we definitely have a very extensive QA lab setup

    No, you clearly don’t!

    An unmodified OS and base install is the simplest setup to test against – arguably the most obvious too – and would definitely be part of any “extensive” QA testing.

    If CF/Adobe wants to be taken seriously, you need to hire someone independent to audit your entire QA and release process, implement their advice, and then have them review it again afterwards.

  10. “bare bones install”

    Yes, that’s what I use when testing new CF builds =P I just reformat, disconnect from network so OS can’t download updates, install an OS, set a restore point, then run a CF installer.


  11. Another thing we have noticed with this update. The Log File location has reverted to the default C drive. A *weird* coincidence it happened exactly at the time the update was applied.

    We had the log file location changed to the d:drive for any of our servers that are running ColdFusion. It has now gone back and this can only be changed back by restarting the CF service gain. Not Happy.

  12. Big thanks to Chris – I found this thread after having a CF10 machine hosed by letting the CF admin do the Update 14 installation. I was missing the VC++ redistributable, and we follow the lockdown guide by having CF service run as a non-administrator.

    At this point I’ve lost all faith in the automatic update process, and have little faith in the Adobe CF QA team in general (witness all the problems with CF10 initial release, and then again with CF11). Adobe needs to provide direct download links to the hotfix jars and provide manual installation instructions for the hotfix.

  13. Totally agree with Adam. Thank you for clarification blog, but where is the note about this on the actual technote? Technote is the first place I would go to find information on the update and since technote deosn’t have that info, how are we supposed to know that there could be those issues? It’s been months since the update came up and still no mention of this on the technote.

  14. Pawel, I believe there should be a technote for CF10/CF11 with regards to this. The automatic updater still doesn’t work with my locked down installation (CF11) so until Adobe fixes this, they need to include details on how to manually install the updates for those that don’t know about this issue and forgetful people like me.

  15. FYI, a user posted a question on StackOverflow as to why he could not update his ColdFusion installation after performing the lock down steps. He found out that the ColdFusion administrator’s update page relies on the /CFIDE/scripts directory to function (a-la the cfform tag). Since the lock down guide suggests denying any requests to that URI the update page was failing. He had to allow access in order to use the update feature. Here is a link to the post:

    This is not good! The update feature should not require exposing that URI. This should be changed. The user was on ColdFusion 11.

Leave a reply