Forms causes site to crash in IIS

sebp

Vote:

We recently upgraded a site from CMS 11 to CMS 12 and the site is up and running fine after a few bugs. Now, a few months after the upgrade and deployment there is another bug that I can't quite wrap my head around and that seemingly has something to do with forms. It causes the w3wp to crash and the site to restart.

Looking in the production server's Event Viewer, I get the following error:

Application: w3wp.exe
CoreCLR Version: 6.0.1122.52304
.NET Version: 6.0.11
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ArgumentNullException: Value cannot be null. (Parameter 'source')
   at System.Linq.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument)
   at System.Linq.Enumerable.Count[TSource](IEnumerable`1 source)
   at EPiServer.Forms.Core.Internal.DataSubmissionService.IsMalFormSteps(IForm form)
   at EPiServer.Forms.Core.Internal.DataSubmissionService.GetSubmittableStatus(IForm form, HttpContext context)
   at AspNetCoreGeneratedDocument.FormsViews_Views_ElementBlocks_FormContainerInitScript.ExecuteAsync()
   at Microsoft.AspNetCore.Mvc.Razor.RazorView.RenderPageCoreAsync(IRazorPage page, ViewContext context)
   at Microsoft.AspNetCore.Mvc.Razor.RazorView.RenderPageAsync(IRazorPage page, ViewContext context, Boolean invokeViewStarts)
   at Microsoft.AspNetCore.Mvc.Razor.RazorView.RenderAsync(ViewContext context)
   at Microsoft.AspNetCore.Mvc.ViewFeatures.HtmlHelper.RenderPartialCoreAsync(String partialViewName, Object model, ViewDataDictionary viewData, TextWriter writer)
   at Microsoft.AspNetCore.Mvc.ViewFeatures.HtmlHelper.PartialAsync(String partialViewName, Object model, ViewDataDictionary viewData)
   at AspNetCoreGeneratedDocument.FormsViews_Views_ElementBlocks_Components_FormContainerBlock_FormContainerBlock.<>c__DisplayClass0_0.<<ExecuteAsync>g__RenderFormBody|0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_1(Object state)
   at System.Threading.QueueUserWorkItemCallback.<>c.<.cctor>b__6_0(QueueUserWorkItemCallback quwi)
   at System.Threading.ExecutionContext.RunForThreadPoolUnsafe[TState](ExecutionContext executionContext, Action`1 callback, TState& state)
   at System.Threading.QueueUserWorkItemCallback.Execute()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()

I've done some research on the internal methods it references (GetSubmittableStatus, IsMalFormStep) and the only idea I can come up with is that there is some sort of corrupt form post upgrade causing these internals to crash rather than return true/false as intended.

Looking for any insight or ideas on what might be the cause or ideas of a solution.

#308693

Sep 19, 2023 4:14

Paul McGann (Netcel)

Vote:

Hi Sebp,

What version of forms are you on also?

Is the form setup as a multi-step form at all?

Paul

#308744

Sep 20, 2023 2:10

sebp - Sep 20, 2023 8:12

Hey!

Sorry, forgot that one. The forms version is 5.4.0 and according to the client, as far as he knows, they're not using steps in any forms in any language.

Seb

Quan Mai

Vote:

I believe this is a bug. I will file a bug to Form team. Thanks for bringing this into our attention and apologies for any inconvenience it has caused

#308752

Sep 20, 2023 8:34

Quan Mai - Sep 20, 2023 8:37

bug is AFORM-3581 (not yet public)

sebp - Sep 20, 2023 11:30

Thank you for the info, will keep the client posted.

sebp - Oct 03, 2023 8:03

Are there any updates on this, or is there a place where I can see the status?

sebp - Oct 16, 2023 9:28

Let's try again then, is there any status update?

Quan Mai - Oct 16, 2023 9:50

Apologies for the lack of update. I have just asked the Form team to take another look into it (making it public and moving to fix it)

Arild Henrichsen - Nov 06, 2023 8:31

AFORM-3581 was fixed in Episerver.Forms 5.7.1
https://world.optimizely.com/support/bug-list/bug/AFORM-3581

Quan Mai

Vote:

Meanwhile I think you can make this workaround:

Create a class that inherits from DataSubmissionService
Override IsMalFormSteps

public override bool IsMalFormSteps(IForm form)
{
 if (form == null || form.Steps == null)
{
 return false;
}
return base.IsMalFormSteps(form)
}

That should work in the mean time when the bug is fixed. Thank you for your understanding and apologies for the inconvenince

#310905

Oct 16, 2023 10:01

sebp - Oct 16, 2023 10:19

Thank you, I will give this a try asap :)

sebp - Nov 06, 2023 11:23

It did not quite work for us, but it made the error message a bit smaller:

Application: w3wp.exe
CoreCLR Version: 6.0.1122.52304
.NET Version: 6.0.11
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ArgumentNullException: Value cannot be null. (Parameter 'source')
at System.Linq.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument)
at System.Linq.Enumerable.Count[TSource](IEnumerable`1 source)
at AspNetCoreGeneratedDocument.FormsViews_Views_ElementBlocks_Components_FormContainerBlock_FormContainerBlock.<>c__DisplayClass0_0.<

Quan Mai - Nov 06, 2023 11:37

@sebp - could you debug to see if your custom implementation is registered and used?

sebp - Nov 06, 2023 11:41

Sorry, I updated my previous response with some more information.

Quan Mai - Nov 06, 2023 11:52

if you turn off just my code in VS and debug it, could you see where it is throwing the exception? maybe this is a different thing that deserves a new thread

sebp - Nov 06, 2023 11:58

I'd love to, but afaik it's only been happening on the production site so far. I'll try restoring the production-db locally and see if I can find something. And my guess would be that the issue still persists, that Steps is null and not 0, therefore it throws when trying to Count further down even with the workaround.

Quan Mai - Nov 06, 2023 12:10

Just FYI we have AFORM-3640 which handles the exception in FormContainerBlock better (it does not prevent the exception if any, it just allows the site to continue instead of crashing - as seen in your exception message)

Quan Mai

Vote:

I will also submit a fix to the form team asap

#310908

Oct 16, 2023 10:22

Eric - Oct 18, 2023 7:53

Hi Quan we are having serious trouble with forms affecting the complete DXP environment making it recycle all containers. We will also file a bug for this one. We do not get the same error but it seems to like you do not have errorhandling correct implemented in the form controllers!? We have also confirmed the same error in an alloy for CMS 12. Made an upvote for this bug!

Our ticket is: 1261115

Quan Mai - Oct 18, 2023 8:49

Not quite sure I fully understand the problem. The problem is only with FormContainerBlock right? I can see a potential problem with FormContainerBlockController

Quan Mai - Oct 18, 2023 9:06

I have asked the Form team to look into this - will get back to you when I hear from them

Eric - Nov 06, 2023 9:54

Thank you for you help both the quick fix and the new release of forms did help us as well. We found ohter bugs within forms though, but that is another ticket for another day :)