I have a very isolated situation I can use a hand troubleshooting.
I have a server that has a fresh install of v12 on it, not upgraded from v11. It has only 2 Forms processes on it that are in use. It is a server that runs all the LF applications sans directory server. The server is Windows 2025. Forms is the latest version from October 2025.
As users interact with one of the Forms processes it bloats up, locks and often needs to be rebooted. If I can catch it early enough, I can just restart the Routing service. I have to do that twice. Sometimes it doesn't fully reconnect on service restart. I suspect because of the RAM getting eaten up. This is it before it gets to 93%+ which is the danger zone:
The first thing I checked for are runaway loops in lookups and/or javaScript. There are none. The Workflows end in a timely fashion:
First thing in the morning before any users are even awake it sits at 93% from the previous day. It does not release the RAM.
My VAR and I dug through the workflow that runs. The only thing out of the ordinary is that is sends docs to DCC sometimes. Other than that it is just combining pages and moving docs.
Could WF subscriber not be releasing it's connection to the repository and somehow passing that retained connection to Forms?
I have set the Forms user that saves to the repo to have no attributes whatsoever. So no generating pages are occurring at the save to repo task.
We've been looking at this for a couple weeks now and am out of ideas except that there is a bug.
I have completely uninstalled and reinstalled Forms on this machine which makes me think the issue is my server or the database itself. Either of those seem very unusual. My next move is to import the process to a non-2025 server and see if I can reproduce the error.
Anyone else out there see this before? Any suggestions on things to try next?
Thanks!
Question
Question
v12 Forms Routing Service not releasing RAM
Answer
Apparently I am NOT crazy. Laserfiche has filed Bug 673897 regarding this issue. Currently they are expecting to have the fix included in the next release of Forms that is expected to be released sometime in July.
If you are also experiencing this, hang in there. Submit a support ticket to Laserfiche to get hotfix sent prior to the July 2026 update if you need it sooner than later.
Replies
- Do you see anything in the App/System or Forms event logs?
- Do you have the same issue with running simpler Forms processes too to rule out design?
- You could also try excluding the process from AV or temporarily disabling AV to rule out involvement.
Thanks for the suggestions!
1. The only clues I saw in event viewer are when the server runs out of resources and things start to lock up. For example at this moment (5:40AM PST) the RAM is at 4.6GB from the day before.
There are no errors or warnings from yesterday whatsoever in the Admin folder. In Operational I only have timeout errors:
Application log has one error from yesterday:
2. It is a good chance the save to repo task on this process is somehow the issue. Either that or the WF that runs. There is only only one other active Forms process on this server and it functions normally. Comments on suspected activities and steps from the above post: "My VAR and I dug through the workflow that runs. The only thing out of the ordinary is that is sends docs to DCC sometimes. Other than that it is just combining pages and moving docs.
Could WF subscriber not be releasing it's connection to the repository and somehow passing that retained connection to Forms?
I have set the Forms user that saves to the repo to have no attributes whatsoever. So no generating pages are occurring at the save to repo task."
3. I'll run this by my IT Director and see what his thoughts are on it.
Thanks so much!
Hello Chris,
One thing we have noticed when upgrading to 12, any custom IIS settings are reverted to default. If you had any IIS performance tuning in 11, you may want to look over that to see if any of those settings changed. Hope this is helpful!
Drew! Hello sir!
This was a fresh install. No previous IIS anything...or anything anything ha ha
The Workflow Subscriber has no knowledge of Forms, so no, there is no way it's contributing to the memory usage in Forms. At least not directly. Nor is the Subscriber used to interact with DCC.
There are lots of things that happen in the routing service besides saving forms to the repository. I would recommend generating a memory dump when the memory usage is around 2GB and opening a case with Laserfiche Support.
Shot in the dark, try changing the Forms app pool start mode to "AlwaysRunning" and idle time-out to "0".
Drew, we always set idle time out to 0. I set the start mode to AlwaysRunning to see if it made a difference. I had to restart the service earlier today and recycled the appPool when I did that. As I type this at 8:45 PST the routing service is retaining 5.6GB with nobody using it.
I captured a memory dump earlier today when it was at 97% RAM usage. Hopefully that holds some clues here. Thanks for the tips!
Apparently I am NOT crazy. Laserfiche has filed Bug 673897 regarding this issue. Currently they are expecting to have the fix included in the next release of Forms that is expected to be released sometime in July.
If you are also experiencing this, hang in there. Submit a support ticket to Laserfiche to get hotfix sent prior to the July 2026 update if you need it sooner than later.
I'm not sure this is applicable, but I had been chasing a memory leak for years in Forms running version 11.0.2311.50564. The resolution was adding a line in the RoutingEngineServiceHost.exe.config file. Under the <runtime> block add
<gcServer enabled="true"/>
When adding this on both Form nodes, it immediately fixed the memory issue upon restarting the routing service.
David
Do we know if this fix was included in the July 2026 update for Forms? I don't see anything mentioning this type of issue in the changelog.
Hi Blake, I don't recall seeing this in previous versions or the July 2026 release. I am hoping this was resolved with 12. We're moving to 12 in a few weeks, so we'll see.
Hi @████████ ,
Bug 673897 was included in the July 2026 release of Forms already, we somehow didn't include the description but I'm sure it's there. We'll follow up with updating the documentation when available, sorry for the inconvenience.
Oh it's there? My VAR has not informed me that is the case yet. I'll have them follow up for confirmation.
The interim fix for this was to set DCC to generate pages instead of the save to repo task. Since DCC can only do PDFs that is the tradeoff.
Thanks for the good news.