Trending issue: problems with Workflows after applying September 2024 CU for SharePoint 2016/2019/SE

- - 62 Comments

We received reports from several customers about issues with SharePoint 2010 Workflows after applying September 2024 CU.
It is important to review the Known issues in this update section of the KB article for the specific CU before applying it in production. For September CU the KB article documents this specific issue as follows:

You might experience an issue in which SharePoint workflows can’t be published because the unauthorized type is blocked. The issue also generates event tag “c42q0” in SharePoint Unified Logging System (ULS) logs.

To work around this issue, register the safe types in the Web.config file. You can look for event tag “c42q0” in ULS logs to find the blocked type. If the type and assembly are safe, add the type to the authorized list in the Web.config file. For example:

<System.Workflow.ComponentModel.WorkflowCompiler>
   <authorizedTypes>
     <targetFx version="v4.0">
        <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null" Namespace="Microsoft.SharePoint.WorkflowActions.WithKey" TypeName="*" Authorized="True" />
    </targetFx>
   </authorizedTypes>

62 Comments


  1. Hi Stefan,
    we observed that the issue is not limited to publishing workflows. In fact this error is not happening at all throughout all our farms. But instead OOTB SharePoint approval workflows are not starting.

    Reply

    1. Hi Marc,
      can you see the ULS Tag “c42q0” as outlined in the KB article?
      Cheers,
      Stefan

      Reply

      1. Hi Stefan,
        yes, we were seeing the tag when triggering the workflows. It was fixed after registering the safe type as mentioned in the KB article.
        Thanks!

        Reply

        1. We had the same issue, after implement the work around, the issue is resolved.

          Reply

          1. updated above mention code with existing Microsoft.SharePoint.WorkflowActions of webconfig file, still facing same issue.


          2. can you pls let me know how did you do…
            i have added safe types in web.config files but even though it is not working


  2. Dear Stefan,
    Regarding this workflow issue, is Microsoft will fix it later in another CU?
    If yes, for which CU is it planned?
    Thanks!

    Reply

    1. Hi Julien,
      this is a side effect of a security fix and is the new behavior.
      Cheers,
      Stefan

      Reply

  3. Hi Stefan,
    our customer is having the issue after applying the patch. We see the event at the ULS:

    Potentially malicious xoml node:

    We added the folowing line in webconfig:

    unfortunatly it isn’t working. Do you have an idea? Kind regards

    Reply

    1. Hi Stefanie,
      your XML did not go through but to evaluate such things in detail it would be best to open a support ticket with Microsoft to get this investigated in more detail.
      Cheers,
      Stefan

      Reply

  5. Most, if not all of our NINTEX workflow publish or run. Most 2010 workflows written via Designer 2013 will not publish. Do we really need to test every function in every workflow, scour ULS logs and and rewrite our web.config files to get this working?

    Reply

    1. Hi Stephen,
      unfortunately at this moment this is the only viable solution.
      Cheers,
      Stefan

      Reply

      1. Hi Stefan, will there be a better permanent fix than this workaround in a later CU? If there are 100s of workflows, this wouldn’t be a viable workaround especially when workflows are business-critical.

        Reply

        1. Hi Desmond,
          this is not a workaround. That is the permanent solution.
          This code change gives administrators full control and visiblity on all 1st party and 3rd party classes executed in a workflow.
          Even if you have 100s of workflows, many of the specific classes to allow list will apply to a large number of workflows.
          Cheers,
          Stefan

          Reply

    2. UPDATE:
      1) In my original post I said NINTEX was working – It should have stated they were NOT working.
      2) Deploying fix posted at the beginning of this blog did seem to get SP 2010/2013 workflows working but left NINTEX broken.

      Comparing Web.config with our working environment several entries were removed (~16 ). We added these back and NINTEX workflows could be published but “Fail to start”. We are left to swim ULS logs for errors.

      Reply

      1. The XML in the article is just an example. For Nintex there are for such several more namespaces that need to be enabled. Also in ULS check the process column of the “c42q0”. We noticed that customers also occasionally get this for OWSTIMER.EXE where some workflows get compiled – especially with Nintex. In this case the same entries need to be added to the OWSTIMER.EXE.CONFIG file.

        Reply

        1. We blanked out our owstimer.exe.config file as per recommendation from Nintex to avoid having to double-up on the authorised assemblies.

          https://community.nintex.com/nintex-for-sharepoint-14/workflows-stay-paused-after-december-2022-sharepoint-update-31517

          quote:
          “One other thing to note is that, if your owstimer.exe.config file contains <System.Workflow.ComponentModel.WorkflowCompiler> section defined in it, then you will also need all of these authorizedTypes declarations from above articles in owstimer.exe.config file as well.

          Either the owstimer.exe.config file should contain all the authorizedTypes same as the web.config file or there shouldn’t be <System.Workflow.ComponentModel.WorkflowCompiler> section at all.

          Hope this helps!

          “

          Reply

        2. For NINTEX workflows and OWSTIMER.EXE.CONFIG, we were also seeing event tag “64csj” with the similar message as “c42q0”.

          Solution was to add all entries from web.config to OWSTIMER.EXE.CONFIG as outlined in Vladimirs post above. Having a default exe.config did not work for us (SP SE).

          Valdimirs NINTEX community link has additional information and a link to a reference to an older script that adds the necessary sections to exe.config.

          Reply

      2. We have the same issue and are in the process of contacting Nintex for support. Did you get any further with a resolution?

        Reply

        1. We are opening a NINTEX support ticket

          Reply

          1. Nintex got back to me on the scheduled workflows, they gave me a new owstimer.exe.config, as follows:

            <appDomainManagerAssembly value="Microsoft.SharePoint, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
            <appDomainManagerType value="Microsoft.SharePoint.SPAppDomainManager" />

            <System.Workflow.ComponentModel.WorkflowCompiler>

            </System.Workflow.ComponentModel.WorkflowCompiler>

            From there, you need to open a web app’s web.config file and copy everything between the “<System.Workflow.ComponentModel.WorkflowCompiler>” tags to between the same tags in the owstimer.exe.config.
            Then restart SharePoint Timer service and that fixed it for me!


  6. What are your thoughts on the PowerShell scripted workaround of setting EnablePreParseSecurityCheckForWorkflow to false mentioned in https://support.microsoft.com/en-us/topic/some-scenarios-of-sharepoint-2010-workflow-are-affected-after-applying-the-july-security-update-for-sharepoint-server-kb5004862-be361cd6-9f54-48c4-b890-2c4b7cf49d13? That seemed to work for us in our test environment after installing the Sept CU and seeing EventID c42q8 with our workflows.

    Reply

    1. Hi Hondo,
      its exactly what it says: it disables a security fix and allows everything.
      On the other hand the solution specified in September CU KB requires an admin to review and allow sspecifically those classes that are really required and relevant.
      Cheers,
      Stefan

      Reply

  7. This is painful!
    We are in the middle of a migration, and this came up. We canceled our migration two months ago because of the last issue.

    I will try and apply this to the server, it might save the migration, still waiting on Microsoft Support to call me back, lol.

    Reply

  8. Hi Stefan!

    Will this be fixed shortly? We havn’t really been able to patch since June because of the July issues.

    Reply

    1. Hi Robin,
      there seems to be a misunderstanding. There is nothing to fix.
      This is the new normal as this is the result of a security fix.
      Cheers,
      Stefan

      Reply

      1. Had the same impression as Robin and did not plan to implement the September CU because of the issues, how small they might be, it is still introducing a risk to our environment.

        Reply

  9. Hi Stefan,
    thank you for your website and information, it always helps us quickly solve problems.
    This works for me.

    Reply

    1. Hi Thoren,
      I assume someone forgot to update the page.
      I will ping the relevant group.
      Cheers,
      Stefan

      Reply

  11. These are the two lines we had to add based on c42q0 events, hope it helps:

    <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null" Namespace="Microsoft.SharePoint.WorkflowActions.WithKey" TypeName="*" Authorized="True" />

    <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.WorkflowActions.WithKey" TypeName="*" Authorized="True" />

    Reply

    1. Thanx for Posting – Very Helpful!

      Reply

    2. Excellent. It worked for us. I only added it ons the main web.config of the application under <System.Workflow.ComponentModel.WorkflowCompiler>

      Reply

    3. This!!!
      Fixed our issue.
      Have to copy the lines in ALL servers that have config in environment.
      (Back up the original just in case)
      May have to restart IIS on Central Admin and Timer servers to refresh.
      We did not have to republish workflows.
      We re-ran Failed workflows.

      Nice @Vladimir!!

      Reply

    4. Hello Vladimir,

      I have added the above code into our web.config file of central admin as well WEF and we are testing into our UAT environment.

      Reset IIS and Timer also , Even though it is not working, pls suggest do i need to make any other changes.

      Legacy Workflow Infrastructure c42q0 High Potentially malicious xoml node:

      Thanks

      Reply

  12. For us, we noticed that this also affected all of our Nintex workflows, and the majority of them were failing to start. Only one of the lines above appeared in any of our web configs, and once the updated line had been added, Nintex WF’s started to work again

    Reply

  13. Please note that in addition to the described problem with publishing workflows (which was indeed fixed by modifying the config file), we have also seen a lot of issues with 2010 workflows failing while attempting to update column values, even when the column is a simple type such as Single Line of Text. This issue began after a specific weekend maintenance, and the September 2024 CU was the only SharePoint update installed that weekend. We’re also receiving more complaints about slowness than usual, but it’s currently unknown if that’s related to the patch installation or not.

    Reply

  14. I installed the Sep 2024 CU in our 2019 Test/Dev environment and observed the c42q0 event in our logs. I applied the fix on all web applications and so far things seem fine.

    But I got curious and created a new web application after patching. Its web.config doesn’t have the new authorizedType, so it seems we have a new item on our checklist for new web applications.

    Reply

    1. Hi Michael,
      yes indeed. This needs to be added to all web.config files that require these types in workflow actions.
      Cheers,
      Stefan

      Reply

  15. We have also encountered the issue with 2010 workflows that stopped working, but we can’t find ‘c42q0’ or similar tags in the ULS log despite logging everything. If we set EnablePreParseSecurityCheckForWorkflow to false, it works, but we are not allowed to do that. Any help would be greatly appreciated.

    Reply

    1. Hi Max,
      it might be that you are running into a different issue which can be resolved also with the EnablePreParseSecurityCheckForWorkflow option.
      Please check this article. It contains different uls tags to look for:
      https://support.microsoft.com/en-us/kb/5004862
      Cheers,
      Stefan

      Reply

  16. Still struggling with this one, I’ve added the line recommended into the web.config but still receive the following

    Potentially malicious xoml node:

    What is the ‘type name’ in this instance? Any help appreciated

    Reply

    1. Hi Robert,
      the type name to be used will be in the c42q0 ULS message.
      Cheers,
      Stefan

      Reply

      1. Sorry, it didn’t allow me to paste the message for some reason, I have attached it below could you help me find the ‘type’ from the message?
        ns1:ReplaceListItemPermissionsActivity ListId=”{ActivityBind ROOT,Path=__list}” x:Name=”ID8″ Roles=”{ActivityBind ID27,Path=ReturnValue}” __Context=”{ActivityBind ROOT,Path=__context}” Users=”{ActivityBind ID22,Path=ReturnValue}” ListItem=”{ActivityBind ROOT,Path=__item}” xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml” xmlns:ns1=”clr-namespace:Microsoft.SharePoint.WorkflowActions.WithKey;Assembly=Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null” /

        Thanks for the help

        Reply

        1. Hi Robert,
          this Xml is exactly what is addressed in the the example above from my blog post.
          Typename needs to be “*”.
          Cheers,
          Stefan

          Reply

          1. Do you mean replace * with XML


          2. No. you need to enter an asterisk. Similar to the example above in my blog post.


          3. I have another error with same event ID

            Potentially malicious xoml node: <ns0:CodeBinaryOperatorExpression.Right> <ns0:CodePrimitiveExpression.Value> true </ns0:CodePrimitiveExpression.Value> </ns0:CodeBinaryOperatorExpression.Right> <ns0:CodeBinaryOperatorExpression.Left> <ns0:CodeMethodInvokeExpression.Parameters> <ns0:CodeFieldReferenceExpression.TargetObject> </ns0:CodeFieldReferenceExpression.TargetObject> <ns0:CodePrimitiveExpression.Value> Equal </ns0:CodePrimitiveExpression.Value> <ns0:CodeMethodInvokeExpression.Parameters> <ns0:CodeFieldReferenceExpression.TargetObject> </ns0:CodeFieldReferenceExpression.TargetObject> <ns0:CodeFieldReferenceExpression.TargetObject> </ns0:CodeFieldReferenceExpression.TargetObject> <ns0:CodeFieldReferenceExpression.TargetObject> </ns0:CodeFieldReferenceExpression.TargetObject> <ns0:CodePrimitiveExpression.Value> ProductName </ns0:CodePrimitiveExpression.Value> </ns0:CodeMethodInvokeExpression.Parameters> <ns0:CodeMethodInvokeExpression.Method> <ns0:CodeMethodReferenceExpression.TargetObject> </ns0:CodeMethodReferenceExpression.TargetObject> </ns0:CodeMethodInvokeExpression.Method> <ns0:CodePrimitiveExpression.Value> Computer </ns0:CodePrimitiveExpression.Value> </ns0:CodeMethodInvokeExpression.Parameters> <ns0:CodeMethodInvokeExpression.Method> <ns0:CodeMethodReferenceExpression.TargetObject> </ns0:CodeMethodReferenceExpression.TargetObject> </ns0:CodeMethodInvokeExpression.Method> </ns0:CodeBinaryOperatorExpression.Left>


  17. Hi Stefan,

    I’m having a related issue with a custom webpart and the new allowlist and getting nowhere with support or Q&a. We’ve tried the configurations in the CU known issues, your config above (just in case), and our standby with safecontrols that we use with this and other assemblies, but no luck.

    The only thing we’ve found to work is ControlCompatMode=”True”, which is fine for our testing, but we need something legit for production systems.

    6d3sf Medium Missed type in new allowlist. Type = System.Collections.Generic.List`1[(our assmebly).SP.WebParts.WebpartColumn]

    ajlz0 High Getting Error Message for Exception System.ArgumentException: The serialized data is invalid. —> Microsoft.SharePoint.ApplicationRuntime.SafeControls+UnsafeControlException: The control type ‘System.Collections.Generic.List`1[[(our assembly).SP.WebParts.WebpartColumn, (our assembly), Version=1.0.0.0, Culture=neutral, PublicKeyToken=XX]]’ is not allowed on this page. at Microsoft.SharePoint.WebPartPages.SPSerializationBinder.IsAllowedType(Type type) at Microsoft.SharePoint.WebPartPages.SPSerializationBinderBase.CheckIfAllowedType(Type type) at (snipped)

    Appreciate any ideas you might have.

    Reply

    1. Hi Pete,
      this can happen if the 3rd party control uses a binary serializer.
      Using binary serializers is blocked with the latest update as binary serializers are unsafe and can instantiate malicious code during deserialization.
      See here for details:
      https://learn.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-migration-guide/
      If the 3rd party code does not use binary serializers, please ask the developer of the application to open a ticket with Microsoft Support for further investigation.
      Cheers,
      Stefan

      Reply

      1. Thanks for the quick response! We have an open issue with support – we’ll pass on your info to them.

        Reply

  18. Going forward, will the needed safe types in the Web.config file be registered automatically starting with the Oct patch release?

    Reply

    1. Hi Will,
      I cannot predict anything for future CUs but it is a clear no for October CU.
      Cheers,
      Stefan

      Reply

  19. Hi, what about sharepoint online.

    suddnely workflows stop working in shareoint designer 2013

    Reply

    1. Hi Ahm,
      the article here applies only to SharePoint Server.
      If you need assistance for Workflows in SharePoint online I would suggest to open a ticket with Microsoft through the admin portal.
      Cheers,
      Stefan

      Reply

  20. I have added below code into Web.Config file of Web App and Central Admin and reset IIS, even through it is not working.

    Please let me know do i need to add something else or any another files.

    Thanks in advance.

    Reply

    1. Hi Vishal,
      its not clear what you mean with “below code”. The info in my blog post is an example.
      You need to update it with the specific namespaces and assemblies outlined in our ULS log to ensure that classes used in your workflows are allow listed.
      Cheers,
      Stefan

      Reply

      1. I have added some piece code but not visible after submitting it.

        I mean that i have already added safe type code into web.config files into wfe and central admin which you have provided at top of the page.

        I am getting below c42q0 code error.

        Potentially malicious xoml node: b38857a1-994d-a006-d56a-c19018294058

        10/07/2024 09:55:48.04 w3wp.exe (0x1D48) 0xECFC SharePoint Foundation Legacy Workflow Infrastructure c42q0 High Potentially malicious xoml node: 4d8957a1-298d-a006-d56a-c5aad54d9f0c

        Reply

        1. Hi Vishal,
          if you need more detailed assistance I would recommend to open a case with Microsoft Support.
          Cheers,
          Stefan

          Reply

          1. Sure i will do it


          2. Hello Stefan,

            I can see events log where it say to add safe guard -> HarePoint.Activities Assembly but even though flow is getting failed. Could you please suggest what should be the issue

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.