CF2021 CFMAIL Error after update 21

[jrathmann01]

Trying to wrap my head around this new error I have popping up trying to send an email. This seems to have worked through update 19. I cannot speak for Update 20 because we updated to 20 and then 21 within a few days of each other. I am running the latest approved JVM 11.0.27 from Adobe's site, on Server 2019. 

Below is the error I am seeing when I try to send. The page does not end up doing a redirect, but hangs after submit.  Running out of ideas for how to resolve, I have followed another Adobe post but that didn't work either so I reverted back to the old bouncy castle: Solved: CFMAIL Stopped Working After CF2018 Update 14 - Adobe Product Community - 13035484

Any suggestions would be welcome, thanks!


Jul 10, 2025 12:21:07 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [CfmServlet] in context with path [] threw exception [Servlet execution threw an exception] with root cause
java.lang.VerifyError: Bad type on operand stack
Exception Details:
Location:
coldfusion/mail/MailImpl.signMail(Ljavax/mail/internet/MimeMessage;Ljavax/mail/Session;)Ljavax/mail/internet/MimeMessage; @238: invokevirtual
Reason:
Type 'org/bouncycastle/asn1/smime/SMIMEEncryptionKeyPreferenceAttribute' (current frame, stack[1]) is not assignable to 'org/bouncycastle/asn1/ASN1Encodable'
Current Frame:
bci: @238
flags: { }
locals: { 'coldfusion/mail/MailImpl', 'javax/mail/internet/MimeMessage', 'javax/mail/Session', 'java/security/KeyStore', '[Ljava/security/cert/Certificate;', 'java/security/PrivateKey', 'org/bouncycastle/asn1/ASN1EncodableVector', 'java/security/cert/X509Certificate', 'java/lang/String', 'org/bouncycastle/asn1/cms/IssuerAndSerialNumber' }
stack: { 'org/bouncycastle/asn1/ASN1EncodableVector', 'org/bouncycastle/asn1/smime/SMIMEEncryptionKeyPreferenceAttribute' }
Bytecode:
0000000: 2ab4 0028 c600 212a b400 28b6 009e b600
0000010: 5e99 0014 bb00 e159 2ab4 0028 b700 e2b6
0000020: 00e3 9a00 0fbb 00e4 592a b400 28b7 00e5
0000030: bf2a b400 2bc7 000b 2a2a b400 2ab5 002b
0000040: 2a2a b400 282a b400 2ab7 00e6 4e2a b400
0000050: 29c6 0010 2ab4 0029 b600 9eb6 005e 9a00
0000060: 0c2a 2a2d b700 e7b5 0029 2d2a b400 29b6
0000070: 00e8 3a04 1904 c600 0919 04be 9a00 0fbb
0000080: 00e9 592a b400 29b7 00ea bf2d 2ab4 0029
0000090: 2ab4 002b b600 ebb6 00ec c000 ed3a 05a7
00000a0: 000f 3a06 bb00 ef59 1906 b700 f0bf bb00
00000b0: f159 b700 f23a 0619 0403 32c0 00de 3a07
00000c0: 1907 b600 f3b9 00f4 0100 3a08 bb00 f559
00000d0: bb00 f659 1908 b700 f719 07b6 00f8 b700
00000e0: f93a 0919 06bb 00fa 5919 09b7 00fb b600
00000f0: fc19 06bb 00fd 59b2 00fe b700 ffb6 00fc
0000100: bb01 0059 b701 013a 0a13 0102 1905 b901
0000110: 0301 00b6 0104 9900 09b2 0105 a700 0613
0000120: 0106 3a0b bb01 0759 b701 0812 b5b6 0109
0000130: bb01 0a59 1906 b701 0bb6 010c 190b 1905
0000140: 1907 b601 0d3a 0c19 0a19 0cb6 010e bb00
0000150: 1959 b700 1a3a 0d19 0d19 0403 32b9 008d
0000160: 0200 5719 0abb 010f 5919 0db7 0110 b601
0000170: 1119 0a2b b601 123a 0ebb 00bd 592c b701
0000180: 133a 0f2b b601 143a 1019 10b9 0115 0100
0000190: 9900 1519 0f19 10b9 0116 0100 c001 17b6
00001a0: 0118 a7ff e719 0f19 0eb6 0099 190f b600
00001b0: a519 0fb0 3a04 1904 bf3a 04bb 0119 5919
00001c0: 04b7 011a bf
Exception Handler Table:
bci [139, 159] => handler: 162
bci [77, 435] => handler: 436
bci [77, 435] => handler: 441
Stackmap Table:
same_frame(@37)
same_frame(@49)
same_frame(@64)
append_frame(@97,Object[#679])
same_frame(@106)
append_frame(@127,Object[#680])
same_frame(@139)
same_locals_1_stack_item_frame(@162,Object[#681])
append_frame(@174,Object[#682])
full_frame(@287,{Object[#455],Object[#603],Object[#606],Object[#679],Object[#680],Object[#682],Object[#683],Object[#652],Object[#453],Object[#684],Object[#685]},{})
same_locals_1_stack_item_frame(@290,Object[#453])
full_frame(@393,{Object[#455],Object[#603],Object[#606],Object[#679],Object[#680],Object[#682],Object[#683],Object[#652],Object[#453],Object[#684],Object[#685],Object[#453],Object[#686],Object[#608],Object[#607],Object[#603],Object[#687]},{})
same_frame(@421)
full_frame(@436,{Object[#455],Object[#603],Object[#606],Object[#679]},{Object[#632]})
same_locals_1_stack_item_frame(@441,Object[#612])

[chrisb84545572]

I'm having the same issue.  Known good code working with CF2021 Update 20 is not working with CF2021 Update 21.  If I comment out the <cfmail> block in that known good code, it works as expected.  

I cannot find anything in coldfusion-out.log, exception.log or coldfusion-error.log related to the issue.  The app now returns an HTTP 500 error page to the browser.

[chrisb84545572]

Forgot add I'm running OpenJDK 11.0.24

[Charlie Arehart · Accepted solution]

Yep. See the technote for the technote for update 21. There’s a new “known issue” bullet that was added today, showing that this problem is solved by stopping cf and deleting the felix-cache folder, in cfusion/bin.

(Note that if you're running multiple instances, it would be [instancename]/bin.)

Let us know if it works for you both. 

[TuesdayM]

Hi Charlie - big thanks again! You are of great help! Much appreciated!
Adobe is not delevering on its own promise: "Build robust applications with ColdFusion". The latests updates are far from robust. As big and (very) longtime CF aficionados (since Allaire) we are a tiny bit disappointed.
But keep up the good work 🙂

[chrisb84545572]

Thank you for the prompt reply.  This resolved my issue

[rocky_6925]

Charlie, I also had this problem and you saved me again! Thank you!

[jrathmann01]

Yes, Thank you Charlie! This did resolve my issue.

[brigitteShef]

Charlie: You are a treasure. Thank you! 

[ripleyc2024]

I patched our test servers last week and they all have this issue.  I patched our prodiction boxes this week and none have the issue.

Did Adobe update the download package after the original posting?

[ripleyc2024]

Funny thing, we had monthly windows patching last night and after the reboot we had the issue on our production server. I would follow the steps for the fix and complete even if your server is working at the moment.

[BenNadel]

Worked for me too! Phew!

[mattInVail]

We ran into this issue after the patch. Cleared the cache. All better.... or so we thought. After a restart many days later the same isseu happened again. Again clearing the cache fixed it, but a recurring issue is a lot different than a problem that just happens when patching. Now I have to figure out some system to monitor for this issue continuously. 

[Charlie Arehart]

Matt, I think there's a different solution to this new problem you raise (this seeming need to "clear the felix cache" more often than just after a cf update). And I don't think the solution is for you to "monitor anything", thankfully: we just need to fix the root cause problem. 🙂 And I have an educated guess of what it is. This will take a couple of minutes to read, Please bear with me, as I offer some diagnostics which will help you (and other readers) even if my proposed solution might prove not to work for you.

A key to me is that you said the problem started after a CF restart. My bet is that we'll find that for you EACH CF RESTART is causing package updates (which then leads to that need of clearing the felix-cache). SHOULD CF be updating packages on each CF restart? No. Is there a reason it's happening? Yes, there will be. How can you find and resolve it? Let me give it a shot.

1) First, we'll want to look at the coldfusion-out.log (in the logs folder for the cf instance in question, which is cfusion by default, but if you have more than one instance look for a sibling folder with that name). As you may know, that file tracks many lines of info about each CF restart. 

It ALSO tracks still MORE detail whenever CF updates happen. Specifically, in the first startup AFTER such an update the next restart should show lines indicating "uninstalling the package", naming the ones to be updated, and then for each package also it names then the specific jars for the package being uninstalledat that time. (To be clear, we don't then see any line in the log saying "updating" or "installing".) That should ONLY happen when there have been package updates--whether per a CF update or by manually updating some particular package in the admin or via cfpm.

But before looking at the log, it's important to note also that on EVERY restart, we DO see lines for each package you have installed, indicating that it was started, as in "package xxxxx was started".

I suspect that in your case, you may find that this "uninstalling" of packages is happening on each restart, when it should not. And I have found that when this happens, there's a reason and a solution. More on that in a moment. Let's confirm if things are as I suspect. 

2) So let's now look at that coldfusion-out.log of yours. Go to the bottom and search up for the phrase "coldfusion started". That's shown on each restart, and it's preceded by dozens of lines about CF starting up. Within those, for EACH of your restarts, you will again see many  saying each of your packages was "started".

But do you also see with that last restart lines saying also '"uninstalling the package"? Then if you look at each preceding restart (look for that "coldfusion started"), do you see again "uninstalling the package" lines? You SHOULD see them there for the date you did the cf update (which is tracked in the name and date of the log in the hf-updates folder for that update). And you WOULD see them there if anyone were to update some particular package via the admin or cfpm.

But if you find these "uninstalling the package" lines on EVERY cf restart, that's indeed the problem to resolve.

3) Assuming you confirm that issue, let's next check a couple more things:

a) look at your CF admin (or the CF Admin for the instance in quesiton, if you have more than one). Go to the "package manager" page, and see its available "settings"  tab offered at the top of that page. In there, what is the value for the "packages url"? And for the "default packages url"?

b) Next, if YOU are the one who does the CF updates, do you do them from within the CF Admin or via the command line?

c) And if you do it from the command line, do you also perform the "manual offline steps" (in the update technote) of downloading and extracting the zip offered there? Where do you extract it to?

Often, what is happening is that someone (in a past update) changed that packagesurl (whether in the CF admin or by editing the neo_updates.xml file, as suggested in the technote).  But if you do a later update and should point to a NEW extracted zip, instead CF thinks it should go back to the OLD one...and you end up with it thinking it needs to update packages, when it shouldn't.  And that happens on each restart. 

Could I have just started with point 3? Sure. But then we'd need to await your answer, and THEN I'd have discussed points 1 and 2. I offer all this to help folks in this situation to know better WHERE to look, in order to diagnose the problem rather than just "pop a pill". Often people are told to do that, or are not given complete info.

(Indeed, I would argue that the technote offers incomplete info--because if one does that manual offline update for one update but later gets CF to be able to talk to the internet, they will do a later update that way...but the CF update mechanism will download the new files and put them into the cf bundles folder...but this pointer to the extracted zip from the earlier update will keep the update mechanism from USING those newly updated bundles files...leading to your error.)

Well, it's one common cause. Again, I didn't want to start with that. I wanted to have you assess the coldfusion-out.log to confirm first if WHAT I suspect is happening shows to be happening (packages being updated on each restart). That's the what and how of your problem. The rest is the why, and at least one suggested reason and its resolution.

If it's not the right what or why, we'll have to dig in a different direction to get you out of this hole you're in. 🙂 We've got shovels at the ready. 

Let us know how the above goes for you.

[mattInVail]

Thank you for the thorough and timely reply. You are a huge asset for the community. There was a lot to dig through. Let me try to take it point by point.

1&2) I believe that the package related logs are as intended. (see attached) There are "unistalling" records after the patch, but not after later restarts.

3a) Not sure if this applies since Uninstalling looks correct, but our package settings are the defaults; Update Site URL: https://www.adobe.com/go/coldfusion-updates , Package Site URL: https://www.adobe.com/go/cf2025_packages .

3b&c) Yes and no. Updates are run via cmd line, but it's not the 'offline' process. I don't trust CFadmin UI installs. They have failed too often with no feedback. I use the admin to download the patch and then run cmd as admin. You at least get some feedback from the cmd line. I run them by calling the instance java.exe -jar <the patch file that I downloaded via cfadmin> and then clicking through the installer app.

It may be unrealated, but the second time that the error popped up was following a CF memory issue where the whole server was crashing from a code loop in the dark corners of the application. If I remember right, running out of memory is one of the cases where the JVM is able to impact the whole machine as it struggles to garbage collect. The machine had to be hard restarted via the console.

I'm attaching a file with the relevent log info. Thanks again for your help.

Matt

[Charlie Arehart]

First, thanks for the very kind regards.  And solving problems with CF is what I love to do, and I do it about all day each day...albeit normally on a consulting basis. But I bring that experience to bear here in the community, especially on such knotty problems (we have a couple going on here in the forums this week).

1) So for anyone who may look at Matt's log attachment that he shared, note that it's not ONE log. Instead he shareds a bit of a couple of CF runs, then adds some commentary (separated by -------------- lines to help), and then more CF runs, then more comments. That wouldn't be obvious to some, who may just start "searching" the log for info and perhaps would not see the context he offers there.

2) I confirmed that the uninstalling only shows up for the one startup after he had applied updated. Good thing I was careful to couch my proposal above (that he might find package updates happening on each start) as merely a possibility. 🙂

3) So what can we take away from all the info he's shared? Well, I don't see any ready explanation in CF's log lines. But he says here and a bit more in the log text that the last problem happened after a box restart...which they'd done because of a memory problem in CF (with I suspect high cpu). That may be were the problem lies. More on that in a moment.

4) I'll note first that you could have avoided the box reboot by just killing the CF task. I do realize you likely tried to stop the service (which would "shut it down gracefully") but you probably found it "wouldn't stop". That happens when memory runs out, GCs get excessive, and CF CPU takes over most of the machine.

And since I can see from the logs you're on Windows, I suspect further that you either gave up waiting for the progress bar of the service to finish, or it popped up saying it couldn't be started. Here's good news in that situation: if you'd waited just another minute then CF would have killed the process. But perhaps you didn't want to wait: in that case, you could have killed the coldfusion.exe process yourself in task manager (not something to do regularly, for reasons I'm about to explain).

But FWIW, when you opted to reboot the box, the same effect could have happened: Windows again tells all services, "hey y'all. shut down." But if they don't, then IT just kills the whole running OS.

5) Now, what's this got to do with your scenario? Well, maybe somehow when CF doesn't go down gracefully  (is killed by you, or by Services not being able to shut it down gracefully, or by a box reboot), perhaps THAT is when something goes amiss with the felix-cache. This is just a guess.

I just don't know enough about how the felix-cache internal processing works. Perhaps someone else or Adobe could chime in. (It's not clear they are reading this thread or will. You may want to open a ticket at tracker.adobe.com reporting the issue. Let us know the ticket number if you do.) 

6) If this is indeed the issue, then that's a hard thing to "monitor" (going back to your original idea). There's no mechanism I know of that tracks if CF did or did not shut down gracefully in its previous run.

You could "watch out for the problem" manually: if you look at that coldfusion-out.log, you'll notice you don't see lines about it "stopping", like you showed when it "went down normally", for example (from your log):

Jul 10, 2025 20:15:59 PM Information [Thread-12] - Monitoring Service stopped.
Jul 10, 2025 20:15:59 PM Information [FelixStartLevel] - Monitoring Service stopped.
Jul 10, 2025 20:15:59 PM Information [Thread-12] - ColdFusion stopped

So if I ever DO wonder if someone/something "killed" CF, this is what I look for. Or if I'm reviewing logs with folks and I see it does NOT log that (in coldfusion-outl.log, or similar but different lines in coldfusion-error.log, such as "A valid shutdown command was received via the shutdown port. Stopping the Server instance"), that tells me CF crashed or was killed (and usually I'd want to find out why).

I'm just saying that's ONE thing you could watch out for. Sadly I'm not aware of even any means to programatically tell how long CF has been up (so that you could watch for when it may have recently "started", then look to see if those log lines are missing--in which case you could proactively stop CF and clear the felix-cache and start it again.)

But I will note at least that if you have FusionReactor, that DOES show on its metrics<web metrics page (in the text below the graphs) when CF "started" (it refers to it as "server started" but it IS referring to CF, or Lucee, or BoxLang, or Tomcat, or Wildfly, or whatever Java app.app server FR is monitoring--which is why they just say "server", though many misread that as "the server".)

Sorry I don't have better news. Again, maybe someone else will, or Adobe may get back to you if you file a ticket. Please do keep us posted. I've not heard of this happening to many others, but it certainly COULD be happening to others. I hoep we may find some "better" explanation for your situation, as it would be lamentable if a mere "hard crash" of CF could lead to this need to clear the felix-cache. I actually hope it's proven that it's NOT the case, actually.

[Charlie Arehart]

Wow, after all that (and dealing with the other issues I'd mentioned), I finally found that there ARE in fact already other folks reporting the same issue (needing to clear the felix-cache AGAIN after having done it following an update).

And one of them created a tracker ticket about the issue, that interested folks will want to vote on and/or follow.

Still, I hope all I wrote earlier today might still benefit someone. If nothing else, things we share here feed the AIs, so perhaps it could benefit even those who never see this thread. 🙂 

[mattInVail]

Well if nothing else, I've learned a little more about CF and logging. The shutdown information is all good to know, but in my case, the machine was struggling to hard to do much of anything. Remote desktop stopped working and I don't have console access. What I did eventually figure out worked was remote powershell commands, but it took me a while to figure out the exact name of the windows services for our CF instances that you need for the command. Others out there might want to jot those down somewhere. 

Thanks for sharing the links. I guess that will at least get it into the black box that is the CF bug backlog. I think that I am going to go ahead with monitoring so that at least we can tackle this quickly if it occurs. It should be simple enough to set up a task to see if a test page is throwing a 500 error and alert us if it is. We have already addressed the bug that led to our memory issue. We really should only be restarting once a month. As long as this only happens at restart, I think we can deal with it until Adobe addresses the issue. 

Thanks Again.

[Charlie Arehart]

Yep, Matt. And on your idea of simply testing if a simple cfmail fails, that's a great idea that some folks may want to hear a bit more about. There are at least two ways one could go about that.

One is to just create a simple cfm page, with a simple cfmail (to/from/subject) and confirm it works. Then wrap that cfmail in a cftry/cfcatch (or script equivalents), and if the attempt to mail fails (because of this bug), in the catch somehow alert yourself (sadly, you can't send an email when this bug is in play). Then you could set that up a call to that simple cfm page as a scheduled task, to run as little as every minute (or more flexibly with the cron feature of CF scheduled tasks.)

Or a more robust approach is to use a service, like checkcentral.cc (which offers a free plan), where you setup CF to send it mail on a regular basis (like every 15 mins) and IT will alert you if it does not get the email as expected.  I use this myself for detecting if ever my mail processing out of CF is failing (for any reason, such as a problem in the cf mail spool or the smtp server not delivering).

It's quite simple really: again just create a simple cfm page doing a simple cfmail (no need of try/catch)...but in this case the "to" address would be one you setup via checkcentral. Then on checkcentral you create a "check", telling it to WATCH for this email to arrive every 15 mins: and if it doesn't arrive within a time you set (1 min, 5 mins, 10 mins, etc.), then IT will alert you: and the free plan can send an email (which comes from their servers, not yours) or a push notification (to their mobile app).

While the free plan should suffice for this basic need we have here, paid plans (starting at $25/mo) can also send sms texts, browser notifications, slack, and dozens more options. More on the plan differences here. Note that the free plan supports 5 such "checks" (the above is one "check": it's NOT referring to the frequency of checks).

Finally, note that the main focus of the tool/service is to instead create more powerful checks, such as from a backup tool, looking at text in the email, and more.  They have a 6-min YT video going over the basics of setting up such a check. Again, while it focuses on such a "backup" check, the same steps would apply to our CF mail send check. 🙂 Hope that helps, you or others here.

[Charlie Arehart]

Thanks, folks, for the kind regards. Of course, the real thanks goes to those who first announced the resolution in comments on the Adobe forum post here about announcing the update--then to Adobe for adding the pointer in the known issue.

As for what this says in the larger sense about cf and Adobe's stewardship, I'll just say it's a big ship with lots of officers and crew--and corporate bigwigs above them. They don't all know everything that's going on, let alone what each other are doing, to affect the passenger experience. It's doesn't excuse failures. I just mean there are sometimes reasons things can't change until there's full alignment of intent, purpose, action, and accountability.

And I don't sense there's a true captain, instead different people with leadership roles (cruise director, executive chef, head of housekeeping, head of engineering, head of sales, etc), each responsible for their own area but none with absolute authority to command resolution of glaring issues, let alone a commitment to "go down with the ship" before all else fails.

Oh well. There are other cruise lines. 🙂 Or we who choose to ride this ship seemingly must accept that it is what it is, until somehow something changes. Often things do, sometimes things don't. It's never really been clear how to truly effect significant change. It's not even about "who you know". Again, see what I said above. So I help how I can and celebrate little victories (like that technote being updated for this issue). 

[Michael Guenther]

Had the same issue.

Weird things happened for me when I cleared the felix-cache.

I restarted the service running the instance, and it just hung there until the service restart timed out.  No errors in the coldfusion-error.log, exception.log, or server.log.  About 30 or new bundle folder were created in the felix-cache. And going to the website ended up giving me a 500 error.

All in all, it took four attempts to restart the service before it 'took'. About 160 new bundle folders created all told.

So strange - but it works.  I'd hate to have to do this on my QA or PRD system for all the instances we have running....