Same issue on SharePoint 2013 and Nintex Workflow 2013… did happen on the september 2022 update as well… 

Is there any Solution?

Still working with Nintex support on it but it seems that our OWSTimer.EXE.CONFIG has been changed in the past (added a few rows in the  <System.Workflow.ComponentModel.WorkflowCompiler> part). I think because it was not working back in the day and added a few rows fixed it.

We removed the rows from the OWSTimer.EXE.CONFIG on all our SharePoint 2013 servers and restarted the SharePoint Timer Service. Slowly the workflow are resuming but it will take some hours/days till all are resumed.

Below is now our OWSTimer.EXE.CONFIG

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <sectionGroup name="System.Workflow.ComponentModel.WorkflowCompiler" type="System.Workflow.ComponentModel.Compiler.WorkflowCompilerConfigurationSectionGroup, System.Workflow.ComponentModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
      <section name="authorizedTypes" type="System.Workflow.ComponentModel.Compiler.AuthorizedTypesSectionHandler, System.Workflow.ComponentModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
      <section name="authorizedRuleTypes" type="System.Workflow.ComponentModel.Compiler.AuthorizedTypesSectionHandler, System.Workflow.ComponentModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    </sectionGroup>
  </configSections>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0.30319" />
  </startup>
  <runtime>
    <NetFx40_LegacySecurityPolicy enabled="false" />
    <appDomainManagerAssembly value="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
    <appDomainManagerType value="Microsoft.SharePoint.SPAppDomainManager" />
  </runtime>
  <System.Workflow.ComponentModel.WorkflowCompiler>
  </System.Workflow.ComponentModel.WorkflowCompiler>
</configuration>

Facing the same problem with Workflows which are having a “Pause for”. 

Currrent workaround is to “disable” the “Pause” and publish it without. Then the WF is running.

Also raised already a ticket, but no solution yet from Nintex Support.

We are running Sharepoint 2016.

I found this article about which code was added in the past into the OWSTimer.EXE.CONFIG (https://learn.microsoft.com/en-us/archive/blogs/rodneyviana/after-installing-net-security-patches-to-address-cve-2018-8421-sharepoint-workflows-stop-working)

I checked our OWSTimer.EXE.CONFIG and we have this code for Sharepoint 2016 inside the file:

However, after the update, the following lines are necessary for SharePoint 2013 and beyond:

              <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeBinaryOperatorExpression" Authorized="True" />

              <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodePrimitiveExpression" Authorized="True" />

              <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeMethodInvokeExpression" Authorized="True" />

              <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeMethodReferenceExpression" Authorized="True" />

              <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeFieldReferenceExpression" Authorized="True" />

              <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodeThisReferenceExpression" Authorized="True" />

              <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" NameSpace="System.CodeDom" TypeName="CodePropertyReferenceExpression" Authorized="True" />

Can somebody confirm the same lines of code and maybe check if the remove of it will solve the issue? 

I have exactly the same problem you’ve described…
 

Facing the same problem with Workflows which are having a “Pause for”. 

 

Currrent workaround is to “disable” the “Pause” and publish it without. Then the WF is running.

 

Also raised already a ticket, but no solution yet from Nintex Support.

 

We are running Sharepoint 2016.

 Initially after the Dec CU all our workflows were failing to start but adding the 2 following authorised assembly types to the web.config got things working again - albeit now with the pause issues

<authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System" TypeName="Int64" Authorized="True" />
        <authorizedType Assembly="mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System" TypeName="Int64" Authorized="True" />

I can confirm our OWSTimer.EXE.CONFIG has the same code as a yours hagowski.

I’ve added the same authorised assembly types to the timer config so it now contains the following..

 <targetFx version="v4.0">
        <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System" TypeName="Int64" Authorized="True" />
        <authorizedType Assembly="mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System" TypeName="Int64" Authorized="True" />
        <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.CodeDom" TypeName="CodeTypeReferenceExpression" Authorized="True" />
        <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.CodeDom" TypeName="CodeBinaryOperatorExpression" Authorized="True" />
        <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.CodeDom" TypeName="CodePrimitiveExpression" Authorized="True" />
        <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.CodeDom" TypeName="CodeMethodInvokeExpression" Authorized="True" />
        <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.CodeDom" TypeName="CodeMethodReferenceExpression" Authorized="True" />
        <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.CodeDom" TypeName="CodeFieldReferenceExpression" Authorized="True" />
        <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.CodeDom" TypeName="CodeThisReferenceExpression" Authorized="True" />
        <authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.CodeDom" TypeName="CodePropertyReferenceExpression" Authorized="True" />
        <authorizedType Assembly="System.Workflow.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.Activities.Rules" TypeName="RuleDefinitions" Authorized="True" />
        <authorizedType Assembly="System.Workflow.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.Activities.Rules" TypeName="RuleExpressionCondition" Authorized="True" />
      </targetFx>

But no cigar

Workflows running but only with pauses disabled for some. Interestingly I have a couple of workflows with pauses that still pause and proceed. I created a new simple workflow which pauses and then sends an email - this works fine

...which made me think I just need to delete and replace existing pauses - but no luck

So, i’m still in the same position as you and as we have a workaround will have to come back to this - hopefully by then they’ll be a solution

@Fud 

Hi Fud, I received today an answer from Ninteport with this info:

I should run this Powershell script to check if the Sharepoint Timer Recycle History is working as expected.

As I need my local admin this can  be checked next week.

TimerRecycleHistory.zip (551 Bytes)

http://files.nintex.com/link/HM438vPKgF5y8Ult14x1Gq

From your side any news?

@hagowski 

I’ve run that script and the timer recycle history isn’t reporting any errors

I was hoping this SharePoint workflow timer job is stuck at Pausing - SharePoint | Microsoft Learn might be of assistance but I’ve gone through cleared the config cache etc. and no change.

Interesting that it says The most likely cause is a bad workflow instance

I’m yet to find one so, no change. All workflows running ok but with all Pause Until steps disabled for the moment.

I might try recreating one of mine as a test. As reported before, a new simple workflow with a pause sandwiched between couple of send notifications works fine. So the issue isn’t affecting every pause action.

I’ll provide an update once I’ve tested recreating one of the workflows that is affected.

HI Everyone, 

There has been three different changes/fixes that Microsoft has made to SharePoint at different times in the past which affected Nintex.

Nov 2018 CU: https://community.nintex.com/nintex-for-sharepoint-67/workflow-failed-to-run-failed-to-publish-workflow-workflow-stuck-in-progress-after-applying-microsoft-update-16631
July 2021 CU: https://community.nintex.com/t5/Technical-Issues/Unable-to-publish-or-run-workflows-after-installing-SharePoint/ta-p/206499
Sep 2022 PU: https://community.nintex.com/t5/Technical-Issues/Unable-to-publish-or-run-workflows-after-installing-September-PU/ta-p/223483

As you know, SharePoint updates are cumulative, so the issue that you are currently facing with Dec 2022 CU could actually be the same issue that started in Sep 2022 CU. 

Depending on which CU version that you upgraded from, you may need to patch the changes from all of the above articles to web.config file.

Alternately, you can also upgrade to the latest version of Nintex Workflows (3.6.4.0/4.6.4.0/5.2.4.0) and perform Nintex Workflow web application activation, which will add all the required authorizedType entries to web.config files.  

One other thing to note is that, if your owstimer.exe.config file contains  <System.Workflow.ComponentModel.WorkflowCompiler> <authorizedTypes> 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> <authorizedTypes> section at all. 

Hope this helps!

@KavinR 

Many thanks for this info. I’m pleased to say after a couple of painful weeks this has helped resolve the issues with workflow failures and pause until action problems.

What sorted it for me wasn’t the inclusion of the additional authorised types in the web.config (although I did remove all references from the owstimer.exe.config) but the advice about alternatively upgrading and running the Nintex Workflow web application activation.

So for info, the steps I took to resolve the problem were:

1. check my web.config files contained all the authorised types required following the Nov 2018, July 2021 and Sept 2022 CUs   
2. remove all references from the owstime.exe.config
3. iisresets (note: after this the issue still remained)
4. Nintex Workflow web application activation - I considered upgrading but thought I’d first try reactivating the version we’re running 

As soon as I’d hit go with the Nintex Workflow web application activation my workflows started running and so far all seems to be back to normal.

Hopefully, that Nintex Workflow web application activation was required might help others who have experienced the same problems - @hagowski ?

Many thanks again!
 

You’re most welcome! 

Hello together,

these week we also get the issues that every Nintex workflow which we want start immediately aborted with the status Failed on Start and no publishing of any workflow were possible after the installation of Windows update (Security Updates) from December 2022 on our SharePoint farm.

After contacting Nintex Support I got this solution attempt.

----

This is symptomatic of issues introduced as a result of installing SharePoint Server updates. Please see the link below on steps to resolve the issue.

https://community.nintex.com/nintex-for-sharepoint-67/unable-to-publish-or-run-workflows-after-installing-september-pu-17076 After adding the two lines (as per suggestion) in the above link in the web.config files, you will also need to add all the entries in the the authorizedTypes config section of the web.config to the owstimer.exe.config files on all your SharePoint servers.

----

I have configured this solution on our SharePoint farm and after this it was possible publish a workflow and also starting a workflow without the errors which we got before. But all workflows got stuck after startup, i.e. did not continue even after completion of tasks or review within the workflow. Not even after more than 15-20min.

Finally I tried the steps which @Fud posted now everything works great again. This means I can publish workflows, start them without error and finish them completely.

Thanks again to Fud for sharing this!

Thanks Fud and finaly we could also get our WF back with “Pause”. In my case if was enought to remove all references from the owstime.exe.config and do a iisreset. Then our WF worked again :)

Thanks you for your quick input on this topic.

An input which will be helpful für future Sharepiont Pack updates: https://help.nintex.com/en-US/platform/ReleaseNotes/NintexSharePoint2016.htm

Here is Nintex mentioning which releae was tested with wich SP Service Pack/CU and SQL Database. Something to consider before updating the Sharepoint.

@KavinR @Fud @hagowski Thanks a lot for your posts which has helped us resolve this issue after installation of Dec 2022 SharePoint update.

We had the issues that scheduled workflows did not start and showed error “Failed on Start (retrying)”, and any workflows with the Pause task got stuck and would not complete.

Initially we added all the authorizedTypes entries as described in the articles in KavinR’s post into our web.config files. Our owstimer.exe.config file had some authorizedTypes entries already, and we added the ones in the articles here too. We still had the issues after this.

We then removed all authorizedTypes entries (in fact the complete <authorizedTypes > section) from the owstimer.exe.config file as suggested in the follow up posts by other users, followed by iisreset and timer service restart. After this our issues got resolved.

We now have an empty <System.Workflow.ComponentModel.WorkflowCompiler> section in our owstimer.exe.config as below:

<System.Workflow.ComponentModel.WorkflowCompiler> 
</System.Workflow.ComponentModel.WorkflowCompiler> 
 

Although this seems to have resolved the issue, I just wanted to confirm if the removal of all authorizedTypes entries from the owstimer.exe.config file could result in any other issues? Especially because we did have some authorizedTypes entries in this file previously which we have now removed.

Or is it more advisable to add all authorizedTypes as defined in the web.config into the owstimer.exe.config file?

@KavinR Could you please advise on that?

Thanks again.

Hi @simranjeev.chawla 

Removing the authorizedTypes entries from owstimer.exe.config file shouldn’t cause any problems as you have all those entries defined within the web.config file. 

However, you may want to remove the <System.Workflow.ComponentModel.WorkflowCompiler> 
</System.Workflow.ComponentModel.WorkflowCompiler> section in your owstimer.exe.config.

Cheers!