After installing June 2026 CU for SharePoint Server 2016, 2019 and Subscription Edition SharePoint 2010–style workflows are failing.
Solution
A fix for this issue has been released with July 2026 CU for all supported SharePoint Version (2016, 2019, Subscription Edition)
Additional Information
Adding it here for visibility as it got lost in the comments
A) To enable SP2010 workflows with July 2026 CU modify the web.config file as follows as suggested by Stephan and James:
Inside this section:
<System.Workflow.ComponentModel.WorkflowCompiler>
<authorizedTypes>
<targetFx version="v4.0">
Add this entry:
<authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ Namespace="System.CodeDom" TypeName="*" Authorized="True" />
B) To mitigate the issue with the incorrect encoded workflow Url, the following workaround was suggested by Brian D.:
Permalink
Hi Stefan,
After June 2026 patch, we ran below PS cmd to fix the 2010 workflow issue:
$farm = Get-SPFarm
$farm.EnablePreParseSecurityCheckForWorkflow = $false
$farm.Update()
Do we need to run any other command or revert above settings after installing July 2026 patch.
Please confirm.
Permalink
Yes, please revert it by setting the value to $true again.
Permalink
I just deployed latest CU to Sharepoint SE and 2010 workflows are not able to start. Failed to run every time.
Permalink
Hi Matae,
which CU was installed before?
Cheers,
Stefan
Permalink
Hi Stefan,
CU 02/26
Matej
Permalink
Hi Stefan,
Thank you for your work
In a testing in environment, I have the same issue with the CU from April 2026 to July 2026
The workflow does not start.
When I’m using “$farm.EnablePreParseSecurityCheckForWorkflow = $false”, it works.
My Configuration database version is : 16.0.19725.20434
Best regards
Permalink
Yes this helped:
Add-PSSnapin Microsoft.SharePoint.PowerShell
$farm=Get-SPFarm
$farm.EnablePreParseSecurityCheckForWorkflow = $false
$farm.update()
But i think this is not secure to leave it disabled.
@Stefan, any ideas?
Permalink
In our testing environment I have the same issue. June 2026 CU installed before, now July 2026 and the 2010 workflows does not start if the flag is set to $true.
Setting the flag to $false works.
Tested switching several times (from $false to $true and back with server restarts between them to make sure it is used.
I do find the EventID “4letu” in my ULS log when the flag is set to $true as well so it looks like the problem is still active in our environment.
Switching back to “$false” for now since it seems important to get the July-patches in production asap.
Permalink
Hi Stefan,
the 4letu is not related to the June CU issue but related to the fact that authorizedType entries required by the specific workflow actions used in your workflows contain types which are not allow listed.
SharePoint uses a “secure by default” model. Means you need to look for these 4letu entries and then decide whether the assemblies, namespaces and types listed there should be allowed or remain blocked.
Do not expect that these entries go away automatically with future fixes – you need to take action to get these resolved. SharePoint also tells you this in the c42q0 event following the 4letu events:
7172026 175514.89 w3wp.exe (0x271C) 0x39B4 SharePoint Foundation Legacy Workflow Infrastructure c42q0 High Potentially malicious xoml node …. If this type is considered legitimate, add TypeName=’…’ to the authorizedTypes section in server config. Ask your farm administrator to add the corresponding assembly to farm property
Cheers,
Stefan
Permalink
I learned last month during SPSE go-live that depending on the version of SPSE you’re running, you should be running a specific SPWFM version. Where is this documented? For this reason, I was told NOT install the latest June SPWFM version.
Thank you in advance and God bless!
Permalink
Correction: I was told to NOT install the April SPWFM version. I needed to be on version 19127.20336 from November 2025.
Permalink
Hi Marlene,
there is always only a minimum required version. You can always install the latest SPWFM fix.
But there might be problems if the SPWFM version is too old for your SharePoint installation.
Cheers,
Stefan
Permalink
Having just applied Jul 2026 CU to our testing environments, and resetting EnablePreParseSecurityCheckForWorkflow = $true, I too am finding that our Nintex WF are failing to start.
I have yet to test by resetting to $false, but like all others, was under the impression that the issue from Jun CU would be resolved
Permalink
Hi Scott,
yes – it was resolved. But with 30+ security fixes released in July there is a good chance that another security fix now causes problems.
Please open a support case with Microsoft to ensure this is properly investigated.
Cheers,
Stefan
Permalink
So even if we installed the July update the flag still needs to be set to false? Is there then going to be an update to the original July CU?
Permalink
Hi Todd,
no there will not be a rerelease of July CU.
If there is a new issues and a fix is required due to lack of workaround (the flag is not really a valid workaround as it disabled a large number of security fixes) it might be fixed in a future CU for SPSE.
Cheers,
Stefan
Permalink
Hi Stefan,
If the July CU didn’t fix the workflow issue and the flag is not a valid workaround, is there a valid workaround you can recommend instead? Migration in in process (and will take some time to complete) but we still rely on the on premise workflows for the short term.
Will there be any options for paid updates like what was done with OS’s?
Thanks,
Todd
Permalink
Hi Todd,
for SPSE you can open a ticket and try to raise it. As it might be a regression there is a small chance that it is being looked at even if the feature is out of support.
For SP2016/2019 new cases are not an option of course as the whole product is out of support.
Cheers,
Stefan
Permalink
Hi Stefan,
Installed SharePoint 2016 Jul 2026 patches in our test environment hoping that the issue related to SP2010 workflows would be resolved. But they are still failing. We were waiting for this Jul 2026 patch released so that we do not have to do the workaround fix proposed. Due to the fact that, there were greater security risks that the environment would be exposed if we use that workaround fix.
Please advice on how to go about it now. Our Sharepoint 2010 workflows are still failing even after being said that the SP2010 workflow issues would be fixed in Jul 2026 but actually they are not fixed.
Thank you
Permalink
Hi John,
The situation is complicated as SP2010 workflows (and also SP2016) are out of support starting today and customers should no longer use them….
Let me see if there are any options.
Cheers,
Stefan
Permalink
Below is the log for this specific workflow issue
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, Collection
1 events, TimeSpan timeOut)1 events, SPWorkflowRunOptionsInternal runOptions)at Microsoft.SharePoint.Workflow.SPWorkflowManager.RunWorkflowElev(SPWorkflow workflow, Collection
Permalink
Hi all,
everyone reporting that SP2010 workflows still fail – please check the ULS log for relevant messages.
Please provide details about what errors are reported.
We need to check if this is the issue introduced in June 2026 CU or a different one (e.g. required AuthorizedType entries in the web.config missing)
Thanks,
Stefan
Permalink
w3wp.exe (RBK-SP05:0x5998) 0x49B8 SharePoint Foundation Legacy Workflow Infrastructure 72fs Unexpected 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, Collection
1 events, TimeSpan timeOut) at Microsoft.SharePoint.Workflow.SPWorkflowManager.RunWorkflowElev(SPWorkflow workflow, Collection1 events, SPWorkflowRunOptionsInternal runOptions) 8a7727a2-6a7f-1020-4397-cc9c8afe14dfPermalink
Hi Matej,
thanks – this error usually indicates that there is a problem with AuthorizedType entries in the web.config e.g. they are missing or malformed.
The event you shared is the final event and it does not give us information what exactly went wrong.
There should be other events before explaining why it was disabled.
Please look for any of the following events: c42qz, 66eax, 5dzld, c42q0, 66eaw, 5349hm, 64csk, 48hpl, 48hpk, 48hpj, c42q1, 64csj, 7876q, 66eav, de7rp, dfawb, dfawc, 7876p, dfmpq, c42q2.
added.
Cheers,
Stefan
Permalink
Hi, this is what i found:
07/15/2026 12:21:39.89 w3wp.exe (RBK-SP05:0x5998) 0x49B8 SharePoint Foundation Legacy Workflow Infrastructure c42qz High CompileBytesPERF: It took 0 ticks to load the authorized types. 8a7727a2-6a7f-1020-4397-cc9c8afe14df
07/15/2026 12:21:39.01 w3wp.exe (RBK-SP05:0x5998) 0x49B8 SharePoint Foundation Legacy Workflow Infrastructure c42qz High CompileBytesPERF: It took 150369 ticks to load the authorized types. 8a7727a2-6a7f-1020-4397-cc9c8afe14df
07/15/2026 12:21:39.95 w3wp.exe (RBK-SP05:0x5998) 0x49B8 SharePoint Foundation Legacy Workflow Infrastructure c42q0 High Potentially malicious xoml node: <ns0:CodeBinaryOperatorExpression.Right xmlns:ns0=”clr-namespace:System.CodeDom;Assembly=System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″> <ns0:CodePrimitiveExpression.Value> true </ns0:CodePrimitiveExpression.Value> </ns0:CodeBinaryOperatorExpression.Right>. If this type is considered legitimate, add TypeName=’CodeBinaryOperatorExpression.Right’ to the authorizedTypes section in server config. Ask your farm administrator to add the corresponding assembly to farm property WorkflowTrustedAssemblies. 8a7727a2-6a7f-1020-4397-cc9c8afe14df
Permalink
Ok, so the required types are not allow listed. Ensure these are added to your web.config:
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ Namespace=”System.CodeDom” TypeName=”CodeBinaryOperatorExpression.Right” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ Namespace=”System.CodeDom” TypeName=”CodePrimitiveExpression.Value” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ Namespace=”System.CodeDom” TypeName=”CodeBinaryOperatorExpression.Left” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ Namespace=”System.CodeDom” TypeName=”CodeMethodInvokeExpression.Method” Authorized=”True” />
<authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ Namespace=”System.CodeDom” TypeName=”CodeMethodReferenceExpression.TargetObject” Authorized=”True” />
<authorizedType Assembly=”Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null” Namespace=”Microsoft.SharePoint.WorkflowActions” TypeName=”*” Authorized=”True” />
Permalink
Hi John,
I have below eventIDs that i extracted from the uls logs c42qz,c42q0. What should i do now? Do i need above mentioned code in all the web application associated web.config files?
Permalink
So I have some strange goings on in both of my Staging farms. Having had WF fail to start, when Parse check set to $True, I then set them back to $False, and carried out more testing. I then needed to update my Change management team with the testing that had been done, so reset the Parse check back to $True and carried out a simple “Assign FlexiTask” workflow in Nintex, which to my surprise actually completed. I ran this same WF against multiple library items, and each time, the task was generated, and WF completed.
I’m going to have another colleague test the same WF again today, but as far as I can tell, the issue with Jun CU regarding 2010 WF engine does appear resolved, but don’t quote me on that
Permalink
Well, it seems I was mistaken, and not sure how it worked, but the issue has reoccurred, along with a failure to publish a WF following a change.
PreParseCheck set to True and WF failed to start
Issue not resolved
Permalink
Hi Stefan. I added authorized types and restarted iis and timer service, but it didn’t helped
Permalink
Hi Matej,
in this case, please provide the relevant ULS log entries to allow me to check if there is anything else missing.
Cheers,
Stefan
Permalink
07/16/2026 12:15:32.08 w3wp.exe (RBK-SP05:0x48EC) 0x0444 SharePoint Foundation Legacy Workflow Infrastructure c42qz High CompileBytesPERF: It took 155963 ticks to load the authorized types. 97c927a2-5a14-1020-4397-c460227b55b1
07/16/2026 12:15:33.25 w3wp.exe (RBK-SP05:0x48EC) 0x0444 SharePoint Foundation Legacy Workflow Infrastructure c42q0 High Potentially malicious xoml node: <ns0:CodeMethodInvokeExpression.Parameters xmlns:ns0=”clr-namespace:System.CodeDom;Assembly=System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″> <ns0:CodeFieldReferenceExpression.TargetObject> </ns0:CodeFieldReferenceExpression.TargetObject> <ns0:CodeMethodInvokeExpression.Parameters> <ns0:CodePrimitiveExpression.Value> Equal </ns0:CodePrimitiveExpression.Value> <ns0:CodeFieldReferenceExpression.TargetObject> </ns0:CodeFieldReferenceExpression.TargetObject> </ns0:CodeMethodInvokeExpression.Parameters> <ns0:CodeMethodInvokeExpression.Method> <ns0:CodeMethodReferenceExpression.TargetObject> </ns0:CodeMethodReferenceExpression.TargetObject> </ns0:CodeMethodInvokeExpression.Method> <ns0:CodeMethodInvokeExpression.Parameters> <ns0:CodeFieldReferenceExpression.TargetObject> … 97c927a2-5a14-1020-4397-c460227b55b1
07/16/2026 12:15:33.25 w3wp.exe (RBK-SP05:0x48EC) 0x0444 SharePoint Foundation Legacy Workflow Infrastructure c42q0 High Potentially malicious xoml node: <ns0:CodeMethodInvokeExpression.Parameters xmlns:ns0=”clr-namespace:System.CodeDom;Assembly=System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″> <ns0:CodeFieldReferenceExpression.TargetObject> </ns0:CodeFieldReferenceExpression.TargetObject> <ns0:CodeMethodInvokeExpression.Parameters> <ns0:CodePrimitiveExpression.Value> Equal </ns0:CodePrimitiveExpression.Value> <ns0:CodeFieldReferenceExpression.TargetObject> </ns0:CodeFieldReferenceExpression.TargetObject> </ns0:CodeMethodInvokeExpression.Parameters> <ns0:CodeMethodInvokeExpression.Method> <ns0:CodeMethodReferenceExpression.TargetObject> </ns0:CodeMethodReferenceExpression.TargetObject> </ns0:CodeMethodInvokeExpression.Method> <ns0:CodeMethodInvokeExpression.Parameters> <ns0:CodeFieldReferenceExpression.TargetObject> … 97c927a2-5a14-1020-4397-c460227b55b1
07/16/2026 12:15:33.25* w3wp.exe (RBK-SP05:0x48EC) 0x0444 SharePoint Foundation Legacy Workflow Infrastructure c42q0 High …n=b77a5c561934e089″>true </ns0:CodePrimitiveExpression.Value> </ns0:CodeMethodInvokeExpression.Parameters>. If this type is considered legitimate, add TypeName=’CodeMethodInvokeExpression.Parameters’ to the authorizedTypes section in server config. Ask your farm administrator to add the corresponding assembly to farm property WorkflowTrustedAssemblies. 97c927a2-5a14-1020-4397-c460227b55b1
Permalink
By using the previously mentioned Stephan method, through iteration, I manage to start the workflow, after modify my web.config I add the folowing line and the workflow start with $farm.EnablePreParseSecurityCheckForWorkflow = $true:
Permalink
Which line you mean?
Permalink
Permalink
I can’t see anything. Yours last reply is just empty.
Permalink
TypeName=”CodeFieldReferenceExpression.TargetObject”
TypeName=”CodePropertyReferenceExpression.TargetObject”
Permalink
And in what section of webconfig you have added it?
Permalink
Permalink
we have a new error after July update, after installing security update for SharePoint Server 2019: July 14, 2026 (KB5002883)
Sorry, an error occurred. The WorkflowInstanceID parameter is incorrect in the URL.
any help Please
Permalink
We have same issue when i click on status link generated by workflow
Permalink
Hi,
we have the same issue in an SE environment after installing the July CU for testing.
BR
Patrick
Permalink
Same Issue here.
Workflow links are damaged.
Example:
https://domain.xyz/List/_layouts/15/WrkStat.aspx?List=fb8807ba-0149-4450-9b93-85a39c40088b&WorkflowInstanceID=%257b17C4F797%252dD41C%252d4C3C%252d95A0%252dA93CE436FEC7%257d
Correct link should be:
https://domain.xyz/List/_layouts/15/WrkStat.aspx?List=fb8807ba-0149-4450-9b93-85a39c40088b&WorkflowInstanceID=%7b17C4F797%2dD41C%2d4C3C%2d95A0%2dA93CE436FEC7%7d
There are some encoded characters like %2d in this link after WorkflowInstanceID. With this update, sharepoint encodes the % again to %25.
To correct the link, simply remove “25” after each of the 6 %-character.
Permalink
Hi Markus,
thanks a lot for sharing your analysis and the workaround!
🙂
Cheers,
Stefan
Permalink
I ended up having to write a URL Rewrite Rule:
Permalink
<rule name="Fix double-encoded workflow GUIDs on WrkStat" stopProcessing="true">
<match url="^(.)(_layouts\/15\/WrkStat.aspx)" ignoreCase="false" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{QUERY_STRING}" pattern="(.)(List|WorkflowInstanceID)=%257b([0-9a-f]{8})(?:%252d|%2d|-)([0-9a-f]{4})(?:%252d|%2d|-)([0-9a-f]{4})(?:%252d|%2d|-)([0-9a-f]{4})(?:%252d|%2d|-)([0-9a-f]{12})%257d(.*)" />
</conditions>
<action type="Rewrite" url="/{R:0}?{C:1}{C:2}=%7b{C:3}-{C:4}-{C:5}-{C:6}-{C:7}%7d{C:8}" appendQueryString="false" />
</rule>Foo © bar 𝌆 baz ☃ qux
Permalink
minus
Foo © bar 𝌆 baz ☃ qux
🙂
Permalink
Does this really work?
For me, if I test the “match url” with an real url, it simply doesn’t match.
Permalink
It didn’t work for me on the first try either. I had to change “match url” from “^(.)(_layouts\/15\/WrkStat.aspx)” to “^(.*)(_layouts\/15\/WrkStat.aspx)”.
Permalink
Had this same issue.
I did a URL Rewrite at the Load Balancer to temporarily fix this everywhere – I suspect any manual fix (updating URLs in every list everywhere) will cause more headaches if this double encoded URL is fixed.
Could also do one with URL Rewrite modules in IIS I imagine.
IF ‘server variable’ ‘uri_path’
MATCH ‘^.*_layouts/15/WrkStat.aspx$’
AND IF ‘server variable’ ‘query_string’
MATCH ‘^(.(?:^|&)WorkflowInstanceID=)%257b([0-9A-Fa-f]{8})%252d([0-9A-Fa-f]{4})%252d([0-9A-Fa-f]{4})%252d([0-9A-Fa-f]{4})%252d([0-9A-Fa-f]{12})%257d(.)$’
Rewrite type: URL
Action type: SET
Components: URL query string
URL query string value: ‘{var_query_string_1}%7B{var_query_string_2}-{var_query_string_3}-{var_query_string_4}-{var_query_string_5}-{var_query_string_6}%7D{var_query_string_7}’
Permalink
I have the same issue today on 2 non-prod 2019 farms after the July CU.
it was possible to start a nintex workflow, but when I click on the Completed status then I get:
Invalid WorkflowInstanceID parameter in URL.
I rebooted the servers, and even set the EnablePreParseSecurityCheckForWorkflow to False but it did not make any difference.
Permalink
Hi Paul,
ensure to open a support case with Microsoft to ensure that this is investigated.
Cheers,
Stefan
Permalink
Hello Stefan,
The “workaround” for checking the status is working, but I wonder what happened that suddenly SharePoint started to format the URL wrongly for these.
Can I still create a support case for SP2019? 🙂
Permalink
Hi Paul,
Not for SharePoint 2016 or SharePoint 2019.
Microsoft strongly recommends migrating to SharePoint Server Subscription Edition (SPSE) as soon as possible.
Going forward, security updates will only be developed and released for SPSE.
While SharePoint 2016 and 2019 will no longer receive these fixes, they may still be affected by the same underlying vulnerabilities.
Cheers,
Stefan
Permalink
Seems there is a workaround – please double check:
click on the ellipsis – more – workflows
on the workflows.aspx page there is a correct link in the “internal status” column
Permalink
I can’t find your mentioned “ellipsis” in Sharepoint 2016. Where shoud this be? Or is it only in Sharepoint SE?
Permalink
Be very careful when adding the lines to the web.config. I copied and pasted from this post, but the quotation marks didn’t match what my system wanted and crashed the site. I replaced all the quotation marks and now it works fine.
Permalink
I implemented the changes, but then new type names would error out. I manually added this one after seeing errors:
But then another one would pop up to take its place. I finally just went with this:
Which of course allows all System.CodeDom type names. I think this is better than using the $farm.EnablePreParseSecurityCheckForWorkflow = $false workaround.
Workflows are now running properly,
Permalink
Hi James,
I think a line was removed in your previous comment. Please replace all angular brackets with [] to ensure that the info is not removed by the comment system.
Cheers,
Stefan
Permalink
I experienced the same issue. The updated authorized type pinned to the top of this article threw other errors when attempting to run WFs. I updated it to include all TypeNames:
[authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ Namespace=”System.CodeDom” TypeName=”*” Authorized=”True” /]
Removing the 6 suggested authorized type and adding this one made WFs run again. I agree with James as this will be far more secure than using $farm.EnablePreParseSecurityCheckForWorkflow = $false.
Permalink
Of course it is far more secure.
🙂
Permalink
Thanks, Namespace=”System.CodeDom” TypeName=”*” is working with $farm.EnablePreParseSecurityCheckForWorkflow = $true
Permalink
Hi Stephan,
I have more than 5 web applications. So in each of these 5 web applications related web.config we have to make an entry at the top of the line in the file with below mentioned line inorder to get rid of the workflow related issues that are being encountered after applying Jul 2026 patches
[authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ Namespace=”System.CodeDom” TypeName=”*” Authorized=”True” /]
Thank you
Permalink
[]
Permalink
UGH …
[authorizedType Assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ Namespace=”System.CodeDom” TypeName=”*” Authorized=”True” /]
Permalink
Failed to raise event to receiver or the receiver threw an exception. Type: WorkflowConfigRetrieved. Receiver assembly: Nintex.Forms.SharePoint, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c52d764dcf7ec883. Receiver class: Nintex.Forms.SharePoint.EventHandlers.OnWorkflowConfigRetrieved: System.NullReferenceException: Object reference not set to an instance of an object.
at Nintex.Forms.SharePoint.EventHandlers.OnWorkflowConfigRetrieved.Execute(WorkflowConfigRetrievedEventReceiverContext eventArgs)
at Nintex.Workflow.Events.EventReceiverCollection.FireEvents(EventType type, SPWeb web, ReceiverContext eventArgs) (Build:52180)
Permalink
*UPDATE
With the web.config changes and latest Nintex for SharePoint 2019, everything works. Except the workflow progress link broken which we have a workaround on that. This forum is super helpful. Thank you all.
Permalink
👍
Permalink
Good Morning all,
So far so good with my testing. I’ve added all of the lines to web.config, including the wildcard.
Do we know if there will be a fix for the invalid URL parameter when clicking on the WF link, bit of a pain at this time, removing all of the 25’s
Many thanks
Permalink
Hi Scott,
SP2016 and SP2019 are out of support, so ….
But if you have the issue on a SPSE server you could open a support case and ask for a fix.
Please have a look at the workaround suggested here:
https://blog.stefan-gossner.com/2026/07/14/resolved-trending-issue-sharepoint-2010-workflows-fail-after-june-2026-cu/#comment-68466
Cheers,
Stefan
Permalink
Thank you for the continued fix at the top of this blog. I am however, still running into specific Nintex WF’s failing to start after having applied the fix, and reset the PreParseSecurityCheckForWorkflow to $True
Can it be confirmed that the additional line of code is added to the following:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\CONFIG – open the web.config, and add the additional line.
There are of course other web.config files in the IIS virtual directories. I assume these do not need to be updated
Many thanks
Permalink
Hi Scott
actually the web.config files for all web applications unterneath c:\inetpub have to be updated.
For remaining Nintex issues, please contact Nintex – they have implemented their own logic and classes on top of SP2010 workflows and we cannot control their behavior.
Cheers,
Stefan
Permalink
I have some news, and whom so ever mentioned the copy/paste of the code for web config, a good spot. The quotation marks were indeed different, and when corrected, and PreParseSecurityCheckForWorkflow was set to $True, I can now confirm that all WF’s are running as expected at this time
Permalink
I have now fixed the quotation marks. Thanks for the hint!
Permalink
Hi Stefan,
We just installed the July patch and added the two web application settings. Sadly the sp 2010 and 2013 workflows fail soon after starting and just shows failure occured during start. Theres no correlation id to look up. Even when I click on the failed message.
Strangely when we publish a simple workflow without a condition those run. So my next step would be to set
$farm.EnablePreParseSecurityCheckForWorkflow=$false
Do you think we need to add the assemblies listed above also? Or will there be comprehensive repost because digging through all the posts is kinda messy.
Also In my test environment where I had the June fixes applied the upgrade went through without any hiccups and sp 2010 and 2013.
Permalink
Hi Heiko,
if you are coming from a recent CU this should resolve the issue for SP2010 workflows:
https://blog.stefan-gossner.com/2026/07/17/trending-issue-sharepoint-2010-workflows-are-failing-after-installing-july-2026-cu/
For SP2013 workflows – which SharePoint version is this?
If it is SP2016, you are potentially running into this issue which most likely affects SPWFM as well as OOS:
https://blog.stefan-gossner.com/2026/07/17/trending-issue-office-online-server-oos-integration-with-sp2016-fails-after-installing-july-2026-cu/
If this is SPSE, then you need to follow the steps in the “Known issues” section of this KB article to resolve the issue:
https://support.microsoft.com/en-us/kb/5002882
Cheers,
Stefan
Permalink
Hi Stefan thanks for the reply,
Sorry should have been more specific.
Both farms are SPSE and our spfwm was installed in April 2026.
Prod got patched from May 2026 and test got patched from June 2026.
DisableActorTokenAudienceValidation = $true had been set on both farms.
PreserveAttributeConsistency = $false
Had also been applied to both.
PreParseCheck was set to false for test and web config had been altered with the missing assembly types in June. Set it back to true after applying the July patch.
So as mentioned on test is everything working but prod is experiencing a different behaviour because both 2010 and 2013 still fail. And no trace is showing in the uls logs because there’s no correlation id shown.
Also on prod which I cannot reproduce on test is that the workflow status page cannot be opened directly from the list because the instance has a triple encoding with %2525. Workaround with the ellipsis is working, but added a rewrite rule also to be able to access it again.
So my next steps would be to apply the June fixes to prod also because thats the only clue I’ve got left.
Kind regards
Heiko
Permalink
Hi Heiko,
this is strange – it should not matter if you are coming from June or from May CU.
Could be that something went wrong during patching and a dll was not updated.
Please confirm that the config wizard was execute or – if command line version psconfig.exe – that this parameter was provided when executed: “-cmd applicationcontent”
It will ensure that assemblies are copied into the correct locations after installing the fix.
Cheers,
Stefan
Permalink
Hey Stefan,
Gui wizzard did run successful on all servers after applying the patch. FE first, than app one server after another as soon as I saw the success message.
Will rerun psconfig.exe -cmd applicationconten nd and provide feedback. Thank you for your time, help and insights
Kind regards
Heiki
Permalink
Hi Stefan,
the re run did not fix the tripple encoding and we additionaly whitelisted * in our webconfig assembly types. WFs started working again – yay. Would you recommned to remove it and add the needed types 1 by 1?
Cheers Heiko
Permalink
Hi Heiko,
for most customers only these authorized types are required:
https://blog.stefan-gossner.com/2026/07/17/trending-issue-sharepoint-2010-workflows-are-failing-after-installing-july-2026-cu/
In some cases additional assemblies and namespaces need to be allow listed like:
Assembly: Microsoft.Office.Workflow.Actions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=nul,
Namespace: Microsoft.Office.Workflow.Actions
Type=*
and
Assembly: Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null
Namespace: Microsoft.SharePoint.WorkflowActions
Type: *
and
Assembly: Assembly=Microsoft.SharePoint.WorkflowActions, Version=16.0.0.0, Culture=neutral, PublicKeyToken=null
Namespace: Microsoft.SharePoint.WorkflowActions.WithKey
Type: *
This affects mostly customers who skipped several CUs where the additional namespaces/assemblies were already required
Cheers,
Stefan
Permalink
Service Bus exception swallowed at location ServiceBusNamespaceListener.GetSessionAndStateWithRetryAsyncResult.HandleException. System.UnauthorizedAccessException: The token provider was unable to provide a security token while accessing ‘https://xxx/WorkflowDefaultNamespace/$STS/Windows/’. Token provider returned message: ‘
401The security token service cannot translate sid ‘S-1-5-21-1676552614-4247226418-2762286769-3127’ associated to user ‘\SPWFM’..TrackingId:5f5c60a1-0ed0-48af-bd80-755a2287ec84-PRO-SPPAPP1,TimeStamp:7/23/2026 10:02:40 AM’. —> System.IdentityModel.Tokens.SecurityTokenException: The token provider was unable to provide a security token while accessing ‘https://mdc-pro-sppapp1.cnhi.gov.sa:9355/WorkflowDefaultNamespace/$STS/Windows/’. Token provider returned message: ‘401The security token service cannot translate sid ‘S-1-5-21-1676552614-4247226418-2762286769-3127’ associated to user ‘\SPWFM’..TrackingId:5f5c60a1-0ed0-48af-bd80-755a2287ec84_GMDC-PRO-SPPAPP1,TimeStamp:7/23/2026 10:02:40 AM’. —> System.Net.WebException: The remote server returned an error: (401) Unauthorized.at System.Net.HttpWebRequest.GetResponse()
at Microsoft.ServiceBus.TokenProviderHelper.GetWindowsAccessTokenCore(IEnumerator
1 stsUris, Func2 uriBuilder, String requestToken, TimeSpan timeout, DateTime& expiresIn)— End of inner exception stack trace —
at Microsoft.ServiceBus.TokenProviderHelper.ThrowException(Uri requestUri, WebException exception)
at Microsoft.ServiceBus.TokenProviderHelper.GetWindowsAccessTokenCore(IEnumerator
1 stsUris, Func2 uriBuilder, String requestToken, TimeSpan timeout, DateTime& expiresIn)at Microsoft.ServiceBus.WindowsTokenProvider.OnBeginGetToken(String appliesTo, String action, TimeSpan timeout, AsyncCallback callback, Object state)
at Microsoft.ServiceBus.TokenProvider.GetTokenAsyncResult..ctor(TokenProvider tokenProvider, String appliesTo, String action, Boolean bypassCache, TimeSpan timeout, AsyncCallback callback, Object state)
at Microsoft.ServiceBus.TokenProvider.BeginGetToken(String appliesTo, String action, Boolean bypassCache, TimeSpan timeout, AsyncCallback callback, Object state)
at Microsoft.ServiceBus.TokenProviderUtility.GetMessagingToken(ITokenProvider tokenProvider, Uri baseAddress, String appliesTo, String action, Boolean bypassCache, TimeSpan timeout)
— End of inner exception stack trace —
Server stack trace:
at Microsoft.ServiceBus.TokenProviderUtility.GetMessagingToken(ITokenProvider tokenProvider, Uri baseAddress, String appliesTo, String action, Boolean bypassCache, TimeSpan timeout)
at Microsoft.ServiceBus.Messaging.Sbmp.SbmpMessageCreator.GetAuthorizationToken(String appliesTo, String action)
at Microsoft.ServiceBus.Messaging.Sbmp.SbmpMessageCreator.GetAuthorizationHeader(String action)
at Microsoft.ServiceBus.Messaging.Sbmp.SbmpMessageCreator.CreateWcfMessageInternal(String action, Object body, Boolean includeToken)
at Microsoft.ServiceBus.Messaging.Sbmp.AcceptMessageSessionForNamespaceAsyncResult..ctor(SbmpMessagingFactory messagingFactory, ReceiveMode receiveMode, Int32 prefetchCount, CreateControlLinkSettings controlLinkSettings, TimeSpan timeout, AsyncCallback callback, Object state)
at Microsoft.ServiceBus.Messaging.Sbmp.SbmpMessagingFactory.OnBeginAcceptMessageSession(ReceiveMode receiveMode, TimeSpan timeout, AsyncCallback callback, Object state)
at Microsoft.ServiceBus.Messaging.MessagingFactory.AcceptMessageSessionAsyncResult.b__29(AcceptMessageSessionAsyncResult thisPtr, TimeSpan t, AsyncCallback c, Object s)
at Microsoft.ServiceBus.Messaging.IteratorAsyncResult`1.EnumerateSteps(CurrentThreadType state)
Exception rethrown at [0]:
at Microsoft.Workflow.Common.AsyncResult.End[TAsyncResult](IAsyncResult result)
at Microsoft.Workflow.Dispatcher.ServiceBusNamespaceListener.GetSessionAndStateWithRetryAsyncResult.EndAsyncResult(IAsyncResult result)
at Microsoft.Workflow.Common.BackoffRetryAsyncResult.IsolateWithRetry(IAsyncResult result)