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

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>

96 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

  4. 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!


  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

    5. Thank you, Stefan and Vladimir for posting your solutions. After applying the first authorized type from Stefan’s post, we observed an old Nintex site workflow in one of our SharePoint 2019 farms that was still ‘failing on start,’ yet other site workflows in the same web app & collection were working fine. We have 6 production SharePoint 2019 farms (3 with Nintex), and we observed this issue in 2 of them.

      The ULS log reported this, which matches Vladimir’s post:
      Potentially malicious xoml node: <ns2:FindValueActivity.FindValue> </ns2:FindValueActivity.FindValue>

      Since this is a Nintex site workflow, it runs in the owstimer.exe process, not the w3wp.exe process. To over-simply how it works in my simple mind (please feel free to correct and/or elaborate details of this comment), I think of it this way, as it relates to Nintex workflows:
      web.config settings govern user-initiated workflows that run in the w3wp.exe process, such as a list workflow that triggers upon item creation or modification (until/unless that list workflow reaches a pause or another action that would put it into the workflow timer job processing).
      owstimer.exe.config settings govern scheduled site workflows and list workflows that meet the criteria described above.

      As Vladimir and others described above, owstimer.exe.config can omit these settings, and then owstimer.exe will refer to the web app’s web.config settings. Since we do specify these settings in owstimer.exe.config on that SharePoint farm, the solution for us was to add both authorized types into both the web application’s web.config file and into the owstimer.exe.config files that reside on each server that run the workflow process (typically WFEs & in C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\BIN).

      Thanks to all for sharing your experiences and what worked for you. Please correct anything I’ve stated here, as the SharePoint learning journey has no end!

      Reply

      1. Not exactly. Workflows started through a user interaction (manual start, upload/change an item, …) run in w3wp.exe. Workflows which are started through non-interactive events run in owstimer.exe

        Reply

        1. Thanks, Stefan – i really appreciate your time and effort maintaining your blog and answering questions. It has been a huge help over the years.

          I know nothing about SharePoint Designer workflows, but the exception to w3wp.exe user-initiated workflow processing that I was referring to is Nintex list workflows that contain a Pause action in them (or a Change State). When that workflow instance reaches the pause point, the rest of that workflow processing is moved to the owstimer.exe process by way of the Nintex Workflow Scheduler timer job.

          This is the only official Nintex doc I could find that mentions it:
          https://community.nintex.com/nintex-for-sharepoint-53/scheduled-workflows-and-the-nintex-workflow-scheduler-job-15057

          Since Nintex list workflows normally run to completion in w3wp.exe, troubleshooting failures of list workflows with Pauses in them can lead folks (like me!) in the wrong direction because it may not be readily apparent that owstimer.exe.config could be involved.

          Reply

          1. Correct. the end of the pause is an non-interactive event which causes the workflow to continue in the timerservice.


    6. Pre-patch Remediation:

      I wanted to point out that we were able to pre-remediate our environment by adding Vladimir’s entries to all of our web.config files prior to applying the patch. These changes held after applying the patch and running psconfig on the servers.
      This will minimize downtime when patching the Production environment.

      Thanks Vladimir for the tips, and thanks a ton Stefan for your great work supporting this community over the years!

      Reply

      1. Thanks Brett! 🙂

        Reply

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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>


  15. 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

  16. 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

  17. 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

  18. 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


  19. Thx you saved my day. WF where Fail to start and list WF were not able to publish after patch sp 2019 current version.

    Reply

  20. Hi Stefan (and others)

    We have multiple virtual directories. Would I have to add it to every web.config?

    Also, we have a c42q8 immediately following the c42q0 (same milisecond in the uls log) which leads me to believe these are connected, am I wrong to assume this?

    Best regards!

    Reply

  21. Hi @stefan,

    We are seeing same error in ULS logs but I failed to find type. Do I need use “*” as type ?

    Potentially malicious xoml node:

    Reply

  22. Hi Stefan,

    Your web.config entry worked fine in my SharePoint/Nintex 2019, after October SharePoint upgrade workflows wouldn’t work. Thanks a lot…

    Kevin

    Reply

    1. Hi Kevin,
      please open a support ticket with Microsoft to get this analyzed.
      Cheers,
      Stefan

      Reply

  23. I applied the fixed and workflow issue was resolved, however, i’m now getting a workflow failed to run when it comes time for the reminder email to go out. Has anyone else experienced this? Have a fix for it?

    Reply

    1. Hi Cheri,
      please check the ULS log. In some cases the autzorized types have to be added as well in the web.config and also in the owstimer.exe.config to ensure that the workflow actions can also be compiled in the timer service.
      Cheers,
      Stefan

      Reply

  24. From reading the comments, Microsoft is not going to add this to the source code. I’m using 2010 workflows and no 3rd party. Shouldn’t Microsoft control this code for 2010 workflows since it’s their product? Can you let me know a reason why the customer needs to manage this instead? Thanks

    Reply

    1. Hi Kurt,
      there is currently a code change in development which is planned to be included in December 2024 CU which will automatically add the entries required for 1st party workflow actions.
      Cheers,
      Stefan

      Reply

      1. Hi Stefan,
        do you know already, if this fix is in the December 2024 CU?
        Cheers,
        Hans

        Reply

  25. Thanks for this post. Faced the same issue after the upgrade. We updated the web.config as per instructions and had to reset IIS and SharePoint Timer Service. We also had to manually start those failed workflows .

    Reply

  26. Dear all,

    we are facing the same issue with the September CU. When I search the logs for “c42q0” I got the following entries:

    RunWorkflow: System.InvalidOperationException: This feature has been temporarily disabled. at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.CompileBytes(Byte[] xomlBytes, Byte[] rulesBytes, Boolean doTestCompilation, String assemblyName, SPWeb web, Boolean forceNewAppDomain) at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.LoadXomlAssembly(SPWorkflowAssociation association, SPWeb web) at Microsoft.SharePoint.Workflow.SPWinOeHostServices.LoadDeclarativeAssembly(SPWorkflowAssociation association, Boolean fallback) at Microsoft.SharePoint.Workflow.SPWinOeHostServices.CreateInstance(SPWorkflow workflow) at Microsoft.SharePoint.Workflow.SPWinOeEngine.RunWorkflow(SPWorkflowHostService host, SPWorkflow workflow, Collection1 events, TimeSpan timeOut) at Microsoft.SharePoint.Workflow.SPWorkflowManager.RunWorkflowElev(SPWorkflow workflow, Collection1 events, SPWorkflowRunOptionsInternal runOptions)

    Event manager error: Could not load file or assembly ‘Netwrix.SharePoint.Audit, Version=9.8.5314.0, Culture=neutral, PublicKeyToken=012e133840e45132’ or one of its dependencies. The system cannot find the file specified.

    System.InvalidOperationException: This feature has been temporarily disabled.
    at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.CompileBytes(Byte[] xomlBytes, Byte[] rulesBytes, Boolean doTestCompilation, String assemblyName, SPWeb web, Boolean forceNewAppDomain)
    at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.LoadXomlAssembly(SPWorkflowAssociation association, SPWeb web)
    at Microsoft.SharePoint.Workflow.SPWinOeHostServices.LoadDeclarativeAssembly(SPWorkflowAssociation association, Boolean fallback)
    at Microsoft.SharePoint.Workflow.SPWinOeHostServices.CreateInstance(SPWorkflow workflow)
    at Microsoft.SharePoint.Workflow.SPWinOeEngine.RunWorkflow(SPWorkflowHostService host, SPWorkflow workflow, Collection1 events, TimeSpan timeOut)
    at Microsoft.SharePoint.Workflow.SPWorkflowManager.RunWorkflowElev(SPWorkflow workflow, Collection
    1 events, SPWorkflowRunOptionsInternal runOptions)

    Micro Trace Tags: 0 avwhy,0 nasq,0 avwhz,46 bjkuz,1 a9fy6,0 bjvyg,0 bnksk,0 avwh6,0 agb9s,0 ajd6k,0 ajd6l,0 avwh7,0 avwh8,0 avwh0,0 avwh1,0 aj1kn,0 avwh2,0 avwh3,0 avwhu,0 a6oo3,7 a6oo3,0 anvuv,16 avwhv,3 anvuv,1 arc5u,0 ax0rv,7 ab3dt,0 ajoij,0 ax0ru,0 abnwl,6 84lu6,5 75ge,0 8sl3,2 adelw,0 az6gu,1 anvuv,74 adhpr,18 adhpr,0 f6l7,0 b4ly,8 aowzv,0 aowzw,67 avwh5,23 nasq,145 adhpr,18 adhpr,0 f6l7,0 b4ly,37 azx1e,0 bmr7d,129 ahk8x,654 ahk8y,11 nasq,32 b0mok,4 adhpr,122 ab3dt,0 ajoij,0 ax0ru,0 abnwl,0 ajpl9,25 amq7p,0 adhpr,32 ab3dt,0 ajoij,0 ax0ru,0 abnwl,0 ajpl9,4 eev1,58 c42qz,241 c42q0,0 c42q8,0 c42rh,78 a0ic2,6 b4ly,0 72fs,67 nasq,92 aqnr1,0 an53i,226 ar15b,239 ar15b,28 ar15b,9 ar15b,0 ar15b,4 bhxdp,0 ar15b,0 ar15b,352 ar15b,4 f6l7,6 aqnr2,2 amq7s,2 98d8,0 aqnr1,0 an53i,2 ar15b,2 ar15b,31 ar15b,2 ar15b,0 ar15b,3 bhxdp,0 ar15b,0 ar15b,22 ar15b,0 f6l7,0 aqnr2,0 bmr7e

    I don’t know why it references another solution (which I completely removed from the farm and all servers).

    And where can I find the specific “Type” I need to insert into the web.config file? Because I already did this for all web apps web.config files with these two lines:

    Thank you very much!
    Tom

    Reply

    1. Hi Tom,
      just put a “*” for the type.
      Cheers,
      Stefan

      Reply

  27. Dear all,

    after apply the CU I noticed that at least for one workflow is duplicating the items result. Has anyone detected the same behaviour?

    Thanks!

    Reply

  28. The web.config update alone didnt fix my issue and after call with MS found this did

    $farm=Get-SPFarm
    $farm.EnablePreParseSecurityCheckForWorkflow ## Output was true.
    $farm.EnablePreParseSecurityCheckForWorkflow = $false
    $farm.update()

    Did the IIS reset and tried the workflows started completing as expected.

    Reply

  29. Hello Stefan
    We see one entry of same event id c42q0 in Uls

    Potentially malicious xoml node: <ns1:SetFieldActivity.Value> In Review </ns1:SetFieldActivity.Value>

    What shall by Type and Assemble ?

    So do I add the same as you given in blog
    <System.Workflow.ComponentModel.WorkflowCompiler>

    Reply

    1. Hi Reshma,
      this seems to be a completely different scenario.
      I would recommend to open a support ticket with Microsoft to get this investigated.
      Cheers,
      Stefan

      Reply

  30. We already have a similar section in our web.config so I’m trying to figure out how to merge the existing authroized type with what has been suggested in this article. When I try it brings down sharepoint so I have to go to my backed-up web.config.
    So hiow can I change

    How to incorporate the new XML please?

    Reply

    1. Hi Jay,
      if you already have authorized types configure – just add the additional lines.
      If you run into an error, I would suggest to check the ULS log to understand what is wrong.
      Cheers,
      Stefan

      Reply

  31. Thanks, I tried that but then goy an internal error when trying to load sharepoint (in my experience this means badly formed web.config (especially if you’ve juts edited it 🙂 )
    The XML was stripped from my original post so I’ll try again.
    Note that that I have a tag called AuthorizedTypes (plural).
    I added the AuthorizedType line from above underneath the original tag and no good (broke SP). So I added the whole section under the original tag include the TargetFX bit. I either need to break down the XML section into separate types or somehow incorporate the above info into the exiting tag.

    Reply

  32. It stripped it out again, is there a wordpress tag to denote code or something? I see others have been able to post their XML ok

    Reply

    1. Hi Jay, I guess you need to escape the Xml.
      Means replace “<” with &lt; and “>” with &gt;
      Cheers,
      Stefan

      Reply

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.