Any news, @matthewr4300865, as the week ends? Not pressing, just curious.  ... View more

@delroy_3222, did you get a chance to try the pathfilter.json with the clarifications I shared. Is it working now for you, even if just as a test?  ... View more

I am not sure. Perhaps someone else will chime in, or ask Adobe via that same cfsup address (and share the answer here). In the meantime, here are some ideas: It may well simply be that once you've run it on an instance (of a given version and update) you can't run it again. Anyone know? There are various prerequisites to be able to run it. Perhaps one of them have changed since you previously did. See the install doc page for the tool, and search for "pre-requisite" (note the dash). See the box following that also When you say you checked the logs, do you mean those in the special "lockdown" folder, created by the tool and discussed on that doc page?  ... View more

Sweet. Thanks, Roberto. If I can get it from them, I'll ask also for their ok to share it here and in the tracker ticket.   I realize some don't won't to risk doing that themselves--or maybe they or someone else will do it first. Just want to help folks needing it.  ... View more

For that matter, reinstalling 17.0.16 alone could prove if there was "something wrong with your Java 17.0.16 installation"--I mean if doing that somehow fixed things.    Note a key aspect of bkbk's suggestion: you do want to stop cf before installing the jvm, if the update would be placed into the same folder as the previous version, which is what the installer does by default. If you'd not been careful about that in this most recent install, Matthew, perhaps that's atma issue. It would seem curious if that would only affect cf startup after a reboot, as you've explained.    Anyway, let's see what you may find, whichever stepss you may follow: yours or either of ours.  ... View more

Any update on this, Adobe? (To save people time, Adobe had marked the bug report by @TwoEdge as a duplicate of the one shared by @fishburp  above, https://tracker.adobe.com/#/view/CF-4226870.)   Sadly, while Adobe has marked the original bug report as "to fix", there's no indication there of "when" it will be fixed, or if indeed there is currently any hotfix (awaiting release in a full update). To be clear, I've confirmed it's not working even on update 4, the current lastest CF2025 update.   Can either of you two above, or anyone else (or Adobe), clarify whether perhaps such a hotfix jar has been made available to you directly?   It's indeed pretty sad that folks using CF2025 can't send via sendgrid, still 8 months after CF2025 came out and 4 months after the bug report was filed. ... View more

Glad to have helped. As for your last point, had you been careful about the path separators? As shown in the file, they must be forward slashes even on Windows. And the drive letter and path are case-sensitive.  ... View more

Jorge, you're surely dealing with a lot. I don't know if anyone will be able to help purely via back and forth here. Great if they can.   But I'll say that if you want all those problems solved, I'm fairly confident that I'd be able to, in a shared desktop remote consulting session. I realize you may be in a position where you "can't pay for help". But if the problems remain unresolved, it would seem SOMEONE could be made to appreciate that paying for an hour or so of my help may be a pittance compared to continuing to suffer these problems. Your call, of course.   For more on my rates, approach, satisfaction guarantee, and online calendar, see carehart.org/consulting.   One way or another hope the problems get resolved for you.  ... View more

Glad you've solved it and thanks for that update. That said, I had started writing up this before seeing your reply :-), so I'll go ahead and share it in case it may help you, Adobe, or others.   1) First, can you confirm that this problem is happening when you RUN cfcompile? (I'm assuming that becasue your error refers to "CommandLineInvoker".)   1a) If so, it may interest you to hear that I am NOT experiencing the same inability to run cfcompile on CF2021 update 21. (FWIW, I had updated from update 20. How about you? It might make a difference if you jumped from some much older update.)   1b) As for it failing for you (and your need to copy that jar), I wonder if perhaps you may have had an error during the update (tracked in the install log for the update, within cfusion/hf-updates), or in downloading package updates (tracked at the bottom of that log), or upon updating the packages (tracked during CF startup in the coldfusion-out.log).   1c) One other thing I would have proposed was that you see if stopping CF and deleting the cfusion/bin/felix-cache folder (then restarting CF, which would recreate it) might have fixed your probem. But I get it that your copy step was sufficient for you. I share this as much for other readers.   2) All that said, for you I also want to clarify that you referred to the June 2024 CF update (in your case, CF2021 update 14) that "phased out encryption". But what you're referring to here is the use of the cfcompile tool, which technically has nothing to do with that encryption change. Still, there's ANOTHER recent change related to cfcompile that you SHOULD know about.   (For readers not familiar with it, note that the cfcompile tool--found in cfusion/bin, as a bat file in Windows or an sh for Mac/Linux--was added in CF7, to allow one to manually compile CFML pages in such a way that the CFM file in your source directory is actually REPLACED with the bytecode CF would normally store and run from cfusion/wwwroot/WEB-INF/cfclasses. It's a form of obfuscation.)   3) Anyway, what may be important for you to hear is that with the April 2025 CF updates (in your case, CF2021 update 19), Adobe has CHANGED CF to default to NOT BE ABLE TO EXECUTE such cfcompile'd code. So while you have gotten your cfcompile to work, via the tweak you did, can you confirm if you can RUN that code?   3a) Note that the same Apr 2025 update also added a new JVM arg that would ALLOW YOU to let CF still run such cfcompile'd code. It's: -Dcoldfusion.compiler.block.bytecode=false 3b) They also added then a new pathfilter.txt file (in cfusion/lib) that would allow you to name a folder of such files to allow, then in the May update that was changed to instead a pathfilter.json file (which also is used to allow scheduled tasks to "publish" their output.) Just beware that in the FOLLOWING update sadly CF resets those pathfilter files back to their empty default values. 😞   Anyway, I just wanted to offer this heads-up about cfcompile. (And on a related note, that April 2025 CF update also removed the old cfencode tool--a still older way to obfuscate code--and they removed also the ability of CF to RUN such cfencoded templates, with a JVM arg to revert that also.)  BTW, the cfcompile tool does indeed still remain in CF, even after this update.   4) As such, again it's certainly interesting that you had to make that tweak of copying that jar. If you might have another server where you'll update CF, or if others might experience it, and if you/they confirm there are no update errors in the logs, and you/they confirm that the cfcompile tool still fails even with felix-cache deleted, it would seem helpful to report it as a bug, at tracker.adobe.com. (Adobe may not see you reporting the problem here, of if they do they tend not to fix things raised here unless a bug report is opened...and they do indeed fix things based on those tracker bug reports--though not EVERY bug reported, of course.)    If you do (or anyone else does) file a bug, please add the link here so that others finding this discussion can view it, add votes, get notified of changes as the bug may be fixed.   Hope all that additional info is helpful, to you or other readers.  ... View more

Yep, agreed on the continued importance of even an older technote.    And as you may have been notified since having voted, they have indeed now fixed the problem--updating the update technotes from May 2025 for all 3 versions: cf2025, 2023, and 2021. 🙂    As I just said there, thanks to Adobe for taking care of this so quickly. I appreciate that even such a simple fix can often fall behind in a large pile of to do's. And let this encourage others to take the time to report issues.  ... View more

I went ahead and filed a bug report on this issue with the update technote. It could help if readers here would add a vote:   https://tracker.adobe.com/#/view/CF-4228385 ... View more

Thanks, and yep, the new cfc would have been modified to define all incoming args for any remote methods--which broke once the update came out that required that. They just hadn't thought to tweak that code before releasing the update.   Again, that update technote needs to be made more clear. It would be nice if someone from Adobe might see this and agree (given Roberto's acknowledgment of what I've feared.)   Anyway, thanks for confirming. Hope it may help others.  ... View more

Roberto, while you later clarify that Adobe gave you an updated cfc, can you confirm something for future readers here? You say you "did that", regarding the technote directive to "add the -Dcoldfusion.runtime.remotemethod.matchArguments flag", but it didn't help.   Did you see that to true or false? Or did you perhaps assign no value? It should have been set to false, though that technote does not clarify it.  ... View more

OK Matthew, so that's a couple of things. 🙂 Let me offer a few thoughts on each, which I hope may help you solve this. 1) So first, that's a valuable clue that you've observed it happens ONLY on cf startup after a reboot, but not on subsequent cf startups. That could suggest there's some race condition of something that CF needs to call upon but which has itself NOT YET been completely started, after a reboot (but is working fine later). Of course, it's hard to know FOR SURE what that would be, and it could take additional work to figure that out. a) So one thing you could do it change the Windows service for CF so instead of being of type "automatic" it's instead "automatic (delayed start)".  That causes it to start 2 mins after the box reboot.    As for making such an auto delayed service wait still longer, there are no built-in feature in the Services panel to control that, but there IS a pretty  simple registry tweak which allows you to control that delay time, for a given service. For details, see resources such as this one. (There are also tools that can facilitate that additional startup delay functionality.) b) Another way to look at the problem is instead configure the CF service to start AFTER whatever service it may be conflicting with (need to await its completion first). If we KNEW what that service was, you could change the CF service definition to make it "dependent" on that/them. Again, for now it's not clear what service may be in conflict (needs to start first). Given the error you show about a net.dll exception, which suggests it may be some need to await completion of the networking stack, one guess is the DNS and TCPIP stack. And to modify the CF2023 service to be dependent on those (await their having started first), you could issue this command (at an admin command prompt): sc config "ColdFusion 2023 Application Server" depend= Tcpip/Dnscache Do you find that this problem ALWAYS happens after each reboot? If so, then try rebooting after this change and see if it happens now. If it does, great. But again, it's not clear these ARE what CF needs to await. BTW, to remove those dependencies, this would work: sc config "ColdFusion 2023 Application Server" depend= "" In conclusion, it's certainly possible that JUST changing the service to BE delayed will suffice. Try that first. Or changing the dependencies may help. Perhaps try that next. Finally, tweaking the delay time may be necessary. Perhaps try that last. 2) Finally, as for preventing the mdmp (crash minidump), you should be able to disable it by adding the JVM arg:  -XX:-CreateMinidumpOnCrash As for putting that into CF, you may know you can do that either in the CF Admin ("java and jvm" and its "jvm arguments" field) or in the cfusion/bin/jvm.config file (on its java.args line), which is what the Admin edits. Either way, note that the dashes are important, and you do NOT want to put that on a new line, but instead add it (such as to the end) of the args there. There should also be a space before and after any such arg you add.   I would recommend you make a copy of the jvm.config file before you edit it (or change the cf admin jvm settings), so you can recover if you make some mistake. And also, I recommend you restart CF immediately to make sure it still starts (don't wait for the box reboot--as CF may not start at all if you make a mistake).    Let us know how things go, if you try any of these. ... View more

1) First, the bundles folder should be in the cf folder (coldfusion2021, in your case), not the cfusion folder within that.   2) As for your saying "we pointed the class path to {application.home}/../bundles", that makes no sense to me. I don't find in my cf2021 config that the cf classpath points to bundles AT ALL, neither in the "java and jvm" page of the admin, nor the jvm.config file. Is there anything about your setup that would have you somehow with a non-standard setup? Are you running a normal "server" installation or did you use the "zip" install approach? What OS are you on?   3) As for the error you show about the com and odbc packages, do you really have need of them? The error may be simply saying you didn't install it (most have no need of them). I'll clarify (for anyone wondering) that the Postgres package does not depend on any other packages at all.   4) As for your cfr problems, have you confirmed that the report package is implemented?   5) With all that, even though you previously deleted the felix-cache folder "many times over", please try it now after the changes you made and got things close to working. It may take care of the remaining errors.    6) As for your proxy issue, you did not address my suggestion about that (the first point of my last reply). Again, getting this working may be more important than everything else, if it helps the normal admin update process to work without a lot of tweaking on your end.   I've numbered the points again this time to help. No need to quote them all, though. You can just number your answers. Trying to keep things simple for you and other readers.    And I realize all these update problems can be frustrating. I get the sense there may be some things you've done in trying to resolve things that may have exacerbated your issues. I'm just trying to help, as a fellow CF user (and troubleshooter), based on experience helping others here and elsewhere. ... View more

To your inability to save the proxy settings, that should certainly work. Do you have trouble changing any other settings? What about even on that page? Can you modify the packages url and does it save?   Indeed, your later indication that you point that at the bundles folder is a problem. You should point to the bundlesdependency.json in that folder.    If somehow you can't change the admin, change it in the neo_updates.xml and restart. Then try install or updating one package, either in the admin or using cfpm.   If it works, update them all. If it fails, when you say you extracted the zip into the bundles folder after bsckinfuirup, you do mean that you left what was there and added what was in the zip, right? Some people mistakenly RENAME the bundles THEN extract the zip into there. That leads to package update/uninstall errors.  ... View more

That's certainly lamentable to hear. But I see that the bug bkbk reported above is now marked as fixed. It's not clear what changed. You may well even be seeing a cached version. Can you try from a browser other than what you're using, or try a incognito/private window? Or bkbk do you see what may have changed?   Lisa, it seems these other issues would warrant another bug report. You can file one easily at tracker.adobe.com. Would you be open to doing that, rather than leaving this matter to die on the vine here? It would be a good thing for you to know how to do. Clearly they do attend to them (though no guarantee).  ... View more

Lisa,. I just up voted your comment here. So it is at least working for some. And perhaps it differs per browser or platform (though of course it should not).  ... View more

Jorge, we will be able to solve your problem. There are either of a couple possible scenarios.   1) Someone may suggest you stop cf, delete the cfusion/bin/felix-cache folder, then start again. Others reporting this error (in the title) have found that didn't solve it. But it's worth trying. If it doesn't help, let's proceed.    2) Does your cf instance have access to the internet? When you go the cf admin "package manager" page and click the "check for updates" button, does it respond immediately? If not, you may need to perform what the update technotes call the manual offline update process.    3) So did you do the update via that admin page or from the command line?   4) Either way, did you look at the update log (in cfusion/updates, in a folder for this update, in the log file with install in its name)? At the bottom, several lines up, it reports whether it detected package updates and then it attempts to download them. Do you see any error there?   5) When cf is started by the update process, it's THEN that Cf attempts to update the packages. Look at the coldfusion-out.log, at the time of that first startup after the update. You should see it first "uninstalling" the packages. Then you will see it starting packages (it never refers to updating or even re-installing the uninstalled ones).   The key question is whether you see errors on the attempt to START the packages?   6) If you attempted the manual offline update, where did you extract the zip to? And did you then change the neo_updates.xml (or cf admin) to point the packages url at that? Again, see the update technote for more. (Some people take an unfortunate shortcut which can also lead to errors related to packages.)   I'll wait to hear your replies before offering more. Perhaps my point 1 could well suffice for you.  ... View more

There are ways to convert that binary string to an actual image, but as you're letting it go, I'll stand down as well.   This is such an odd message you got that anyone else getting it will likely find this thread, can read what all we wrote, and pickup the flag then if they want to.  ... View more

Ah, yes: I copied when I should have cut. 🙂   Glad things are working for you.  ... View more

Are you saying that making only the change in the var name used in the a href introduced that error? I'd be very surprised.   Anyway. What, if any, of those 3 cfset's is the line 346 mentioned in the error as doing a cfset?   And do you have (anywhere in the hundreds of lines not shown) a "&lt", as is implied in the error message?   BTW, if you get tempted to share the hundreds of lines in a reply, please don't. There's a feature to attach a file here. And if that fails for you, consider putting it somewhere and linking to it (assuming it's not sensitive code, of course).  ... View more

Thanks for clarifying your situation. Still, it feels like you didn't quite understand my first answer. Have you at least tried it? I really think it will be your solution.   To be explicit, move the a href to AFTER the closing cfif, and replace the variable referenced there to be this:   <a href="https://www.pathlabtalk.com/forum/index.php?/topic/#tid#-#title_seo#/" style="font-size: 18px; text-decoration: none; color:##417394;">#trimmedQuote#</a> ... View more

It would seem your href would work as is if you placed it after that cfml code, and changed #ThreadTitle# to #trimmedQuote#.   But somehow I suspect that answer is too obvious and I'm perhaps missing what was your question. If so can you elaborate?  ... View more

Ok, so now it's not the action of the cfimage that varies the result, but whether you're having it process a blob (binary large object)?   Can you provide us any more info about the blob? You can either cfdump it or use cfimage and its info action to get more.   It would seem hard for us to replicate (or even explain) the problem without that or more info on it.  ... View more

Good luck with that, sincerely. I've looked into it more than once over the years and never could get it working. Maybe there's some simple step we're missing--which perhaps someone else here will enlighten us with. But I've never found any documentation of how to get it all going.   Of course half the battle is having sql server (and the infrastructure) setup for Kerberos. You've got that working, so maybe you're really close.   If no one here solves it, reach out to Adobe support at cfsup@adobe.com. Then I hope you'd fill us all in on the solution--and that they'd better document it. Others definitely want to get this working.  ... View more

Glad you're making progress, and especially glad my hints helped. But no, I would be SHOCKED both that this is some new behavior in cfimage or indeed that it's really related to cfimage at all.   I realize your use of the writetobrowser action seems to prove it "must be", since that "stops it". But I will press on.   First, try putting a cfabort after the cfimage, and try the other types again. Do you still get the message in the logs?   Second, try creating a single line standalone test doing that cfimage (which seems to create the message), and confirm it does.   Now, move that test file into a new test folder under where it is now. In that folder also create an empty application.cfc (or cfm). Now call it (in that test folder). Does it still happen? If not, there's more to your request than you were seeing and inferring (and this would prove it's NOT about cfimage). Then you can pursue what IS done in the application.cfc or application.cfm/on requestend. cfm which may be causing your message.    Finally I'll note I'm writing from a phone so can't just do a test for you (and of course we can't see the cf logs in cffiddle.org or trycf.com).  But this is a couple minutes of effort for you, it seems. Hope you'll try it and report back.  ... View more

Lisa, while I've never used the ASB feature, and I'm reading this on my phone, I might still be able to offer a useful suggestion. And although your code looks like it SHOULD work compared to the docs, here are two things to consider.   First, are you running this that you feel you must rely on writelog, because you can't produce output to the screen? Can you arrange to call it in such a way that you can? If so, it will simply make diagnosing things easier.    For example, what do you see if you writedump(sb)?  That will list all the methods of that cfc instance, including their arguments. Indeed, then dump also your myqueue and schedmessage vars. Despite what our eyes tell us from your code, those may hold something that's somehow unexpected.    Finally, there may also be more useful detail in the error than what your writelog is reflecting. How about dumping the e var within the catch?   Or (sometimes better still) remove the try/catch and just let the normal cf error dump to screen. Another benefit of that is you may see more detail in cf's exception.log (which may not be written to when you catch an error).   Of course, you can also tell writedump/cfdump to write its output to a file instead of the screen, if you must for some reason.    Let us know what you find, or better if you may be able to use that info to resolve the problem on your own. Or maybe someone else will see a different solution for you.  ... View more

Must be some Adobe spyware! Just kidding (though some would assert that must be it)!   First, I can say that I've never seen that in thousands of coldfusion-out.log files I've seen, and hundreds for cf2025. As such, this seems very unique to you...and thus is likely environmental. I can also confirm that I have that same sentiment-analysis-parser-0.1.jar file within my CF2025 jetty\work folder at about the same path, since I'd implemented the Solr feature of CF. But again I am seeing no such LOG entry as you report.   Let's note about that the info message that the thread-id indicates it arose based on a request coming into CF--specifically coming on your port 8024, which is the AJP port. That means the request came into CF by way of your web server, such as iis or apache (as opposed to the port 8500 which is the built-in web server used for the CF admin).   Even so, and especially since the request seems recurrent, you might want to check if perhaps you have a cf admin scheduled task running at that frequency (it could call a URL which ends up on your server, coming through your web server)? Please do check your admin scheduled tasks page.    And I realize you you say you "just" installed this cf instance, in which case you might be tempted to say you "didn't add any tasks". Even so, you technically say you "upgraded" cf, which implies you had a prior cf version on the same machine. Is that right?     If so, during the first launch of the cf admin you (or someone) would have been asked if you wanted to migrate in the cf admin settings from the previous version. If you did that, perhaps something got migrated you're not expecting. Note there is a migration log in the cfusion/logs folder if you did that, showing what was migrated. It might be worth a look.   Finally, since the requests are coming in via your web server, check your IIS or Apache logs for the times shown. That will show the URL as well as the originating IP address (and user agent). Let us know what you find. ... View more