Since multiple Trending Issues have now been documented for the September 2025 CU, and it’s becoming increasingly difficult for individuals to keep track, I’ve decided to create a single summary page.
Senior Escalation Engineer for SharePoint Products and Technologies @ Microsoft
All Posts provided "AS IS" with no warranties, and confers no rights.
The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft.
The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft.
Permalink
Thank you so much for doing this for everyone – as always, I along with everyone else appreciate you and all that you do to support us
Permalink
Thank you for this Summary and for your Support.
Permalink
thanks Stefan
Permalink
Thanks, Stefan, for this summary. Has anyone else, to your knowledge (or anyone else reading this article, I’m all ears), had issues in Subscription Edition where the Secure Store fails, citing cryptographic errors preventing the contents from being retrieved? Refreshing the key and generating a new key had no effect. We have a ticket open with MS, and we provided some information, but the ticket has stalled. This is the error we see:
Decrypt Failed:System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed.
at System.Security.Cryptography.CapiSymmetricAlgorithm.DepadBlock(Byte[] block, Int32 offset, Int32 count)
at System.Security.Cryptography.CapiSymmetricAlgorithm.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
at System.Security.Cryptography.CryptoStream.Dispose(Boolean disposing)
at System.IO.Stream.Close()
at Microsoft.Office.SecureStoreService.Server.DotNetSecureStoreCryptoProvider.DecryptInternal(Byte[] crypt, Byte[] secureKey, Byte[]& decryptedData)
I’m going to attempt to rebuild the service and see if that will restore functionality (thankfully the list of target APPs is small).
Permalink
The technician working our support ticket for this issue did mention that they were able to reproduce the problem after seeing it come up with another client. So we aren’t the only one, but it either doesn’t seem to be widespread, and/or people just may not be using that service as much anymore. I will follow up with our tech and see if he has any further information (I will post a reply here if he does).
Permalink
Hi Dustin, we are facing the same issue and having the same ULS log entries. Currently, we are unable to edit items in the Secure Store Service Application, it ends always up in ‘Group claim validation failed.’ error. We also see a couple records later in ULS: “SharePoint Foundation General ajlz0 High Getting Error Message for Exception System.Web.HttpUnhandledException (0x80004005): Exception of type ‘System.Web.HttpUnhandledException’ was thrown. —> Microsoft.Office.SecureStoreService.Server.SecureStoreServiceException: Group claim validation failed.” Am 0x80004005 is typically an access denied on something…
Have you tried to rebuild the service application? And what was result?
Permalink
From our Microsoft rep:
“It appears there has been some changes in some of our code that was to tighten security down and it breaks how we decrypt claimshasvalues from the Secure Store. As far as I know, there is no way to fix this current issue, other than to recreate the TargetApplications on the SSSA ( Secure Store Service Application ).”
This is what we’ll try. We didn’t recreate the service yet, and thankfully our store only has a small number of entries.
Permalink
WORKAROUND (and it’s not great, but I’ve tested it):
–Delete any existing damaged entries.
–If no entries remain, reset the store passphrase, else refresh it with the original passphrase.
–Rebuild the entries the exact same way they were before the patch (hopefully you have those documented!!)
–Test affected applications.
Permalink
Yes, that’s the workaround we discussed yesterday. Great that it worked!
Thanks for the confirmation.
🙂
Permalink
@dustin.. we are working with our engineering team to see what other options we have.
Permalink
I did the same without setting the passphrase again, and it worked too. Happily, that all can be scripted with PowerShell, because we have a couple of Farms and Applications… In addition, we face this issue only on SharePoint SE, not on SharePoint 2016. Thank you all for your participation here!
Permalink
Thank you very much Stefan!
Permalink
Thanks for the summary.
Permalink
Thankyou Stean! We’d be lost without this blog!!
Permalink
Kudos for all your support Stefan. Once again, your work is extraordinary!
Permalink
Thanks! 🙂
Permalink
Thanks, Stefan 💪😊🙏
Let’s hope things calm down and become more stable in the coming months. 🙏
Currently we’re investigating another issue in SharePoint Server Subscription with Microsoft Support: w3wp.exe crashes 💥when uploading some signed and protected PDF files 📃 (faulting module: ucrtbase.dll). May have nothing to do with the September update. SharePoint 2016, 2019 and Online are not affected. When we change the file extension or compress it into a zip-file, it works. I’m curious to know what the cause is.
PS: The Workflow 2010 issue (OWSTIMER.EXE) is currently missing in your overview.
Cheers from 🇨🇭 Switzerland,
Benjamin
Permalink
Yes – indeed. Was pretty late yesterday when I requested the fix and added the Trending Issue article and update the summary article – but just forgot to publish it.
Permalink
Microsoft Support just confirmed there are many issues in September 2025 CU and mentioned your blog. They recommend either do a rollback before the CU was installed, or use a workaround and wait until October 2025 CU, which should fix the process crashes.
Permalink
👍
Permalink
Wow as far as I know there is no way to roll back or uninstall CU? IS there a way to uninstall the CU?
Permalink
The only way I know is by following some best practices:
– have a Test environment
– execute a Farm backup before CU
– test in detail & keep checking this blog for a few days
– based on the severity of the issues
– – revert to the previous Backed-up state and wait for a newer CU
– – – or
– – install the CU on Production (following the backup process before the installation)
– – – and if CU issues appear even afterwards, need to decide if roll back to previous version & lose data created in the meantime or keep it as it is and wait for the next CU
Permalink
Yes. Correct summary.
For virtual environments rollback can be simplified by having a cold snapshot of the farm (SharePoint Servers + SQL servers) from before the CU was installed.
“Cold” means that all SharePoint servers and SQL servers need to be in shutdown state when the snapshot is taken.
“Hot” snapshots are unsupported with SharePoint due to inconsistent state between SharePoint and SQL servers which can lead to database inconsistencies.
Permalink
Unfortunately this is not fixed with the October 2025 CU. w3wp.exe still crashes on two servers. I just opened a new support case.
Permalink
Hi Benjamin,
feel free to send me the SR number using contact the blog author at the top right of this screen to allow me to have a look.
Permalink
Hey Benjamin,
We also still have w3wp.exe crashing on our SPSE App servers after applying the October 2025 CU. Please let us know what you hear back from your case. Thanks.
Permalink
Feedback from Microsoft Support:
This is a known issue caused by a regression in the September 2025 Cumulative Update, leading to worker process crashes (0xc0000409) in owssvr.dll.
Our Product team is actively working on a fix, which will be released soon.
Permalink
Have you got a fix for this issue ?
Permalink
No. We need to wait for the next Cumulative Update. Hopefully the fix is in there.
Permalink
The issue is still being investigated at this time.
So December CU will not include a fix.
Cheers,
Stefan
Permalink
Hi Stefan,
I’m currently facing an issue on our SharePoint Server 2019 environment. In the Event Viewer, I see the following error message:
Product: Microsoft SharePoint Server 2019 Core — Error 1706.
An installation package for the product Microsoft SharePoint Server 2019 Core cannot be found.
Try the installation again using a valid copy of the installation package ‘sts.msi’.
The problem occurs whenever the application pool tries to start, and it looks like Windows Installer is attempting a repair but fails because sts.msi cannot be located.
Environment: SharePoint Server 2019 (patched up to the latest CU)
Error observed: Event ID 11706 (MsiInstaller)
File missing: sts.msi
Questions:
What is the correct way to resolve this error? Should I run a repair using the original SharePoint 2019 ISO and point to sts.msi under Servers\Global\sts.msi?
Permalink
Hi Ariq,
this is not a SharePoint problem but a Windows Installer issue.
It sounds as if the Windows Installer Cache is corrupt.
If you have multiple servers in your SharePoint farm which were all patched identically there is a chance to repair it using the following script:
https://gist.github.com/huaditsai/8729c2b3ff9a2adaae8afa4dd55abe46
Otherwise the only chance would be to either rebuild the server or at least uninstall and reinstall SharePoint.
Cheers,
Stefan
Permalink
Hi Stefan,
Thank you for your quick response and for clarifying that this is more related to the Windows Installer cache rather than SharePoint itself.
I checked the logs more deeply and found that the initial trigger seems to be a missing/corrupt file (ManagedBlingSigned.dll under the 16\ISAPI folder).
Error Message on EventViewer:
Detection of product ‘{90160000-1012-0000-1000-0000000FF1CE}’, feature ‘WSS_ProductFiles’, component ‘{3AFE36AB-9ABD-4FA2-8ADD-0EB56B67349A}’ failed. The resource ‘C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\ISAPI\35dd9a50\ManagedBlingSigned.dll’ does not exist.
This appears to have caused Windows Installer to attempt a self-repair, which then fails because it cannot locate the sts.msi source. Based on your advice, I’m planning to try the script you shared (OPUtil.vbs) with /RepairCache /ReconcileCache and point it to the extracted SharePoint 2019 ISO (sts.msi under Servers\Global\Wss).
Before I proceed, may I confirm:
1. Is it safe to run this script directly on a production farm server, or should I first test it on one WFE node while the others stay online?
2. After repairing the cache, do I need to re-apply the latest CU and re-run PSConfig to ensure binaries and schema are in sync?
3. In case the cache repair doesn’t succeed, is the recommended next step a full uninstall/reinstall of SharePoint on the affected server(s) while reattaching them back to the farm?
Appreciate your confirmation and guidance on the safest approach for a production environment.
Best regards,
Ariq
Permalink
Hi Ariq, I’m not certain that this will work.
If your farm has more than one server, please use this command instead:
“cscript.exe OPUtil.vbs /RepairCache /SRestoreLocation=\HEALTHY_SERVER_NAME\c$\windows\installer”
Ensure to replace HEALTHY_SERVER_NAME with the name of the server that does not have the problem.
Cheers,
Stefan
Permalink
Thank you so much
Permalink
Regarding “Upgrade to SharePoint 2013 Workflows required before July 14th, 2026 due to Upcoming End of Support for SP2010 workflows!” Does this mean that 2010 workflows will stop working after July 14th, 2026…or will they run but being unsupported?
Permalink
Hi Frederik,
I’m not aware of a decision here, but you can assume that as soon as the first potential security issue for this area is detected the relevant code path will be eliminated. So better plan as if it is no longer there, rather than getting a bad surprise.
Cheers,
Stefan
Permalink
Hi Stefan,
We went to the sept patch for SE from the July critical cve patch and the only real issue we are seeing is when crawling. We are getting huge .dmp files generated from the w3wp.exe specifying owssvr.dll as the faulting module. This is happening across all our farms.
Has this been widely reported at all for this patch and any idea what we would need to do to resolve it?
Many Thanks
Permalink
Hi Dave,
no I have not seen any such reports.
My recommendation would be to open a ticket with Microsoft support and be prepared to share one of these .dmp files for analysis.
Cheers,
Stefan
Permalink
Hi Dave & Stefan
We have the same, incremental crwal each half of hour make the application pool to crash. So had to use only one front Webb for customers and the other to crawl with crashes.
All after latest CU and we have SP Subscription as well. Hopefully soon have a patch or workaround to solve it soon.
Permalink
Hi Johnny,
please open a support ticket for this. This is currently no known issue and is not being investigated.
To investigate further (and potentially request a fix) we need a support ticket.
Cheers,
Stefan
Permalink
Dave & Johnny,
Did either of you submit a Microsoft support ticket for your issue? I also started seeing Windows Application Log entries for Event Code 1000 with faulting module owssvr.dll and faulting application name w3wp.exe. The error seem to also coincide with my incremental search crawl schedule, but did not begin until after about 30 minutes into the first full crawl after applying the SPSE Sep CU. I must not have crash dump collection enabled, because I can’t find any .dmp files in any of the common related directories. I haven’t noticed any issues related to search crawls or search results.
Permalink
Hi Fred,
Yes I’ve submitted a support issue ticket it but no real response yet.
Permalink
Hi Dave & Fred
No, sorry not crerate ticket yet, thank´´s Dave to do. Input from my partner in SP have do a research about what the reason could be, we are not sure but an indicator are Visio. Do you have the same error in the SP logs where Visio files are included ?
Johnny
Permalink
Johnny,
We analyzed a crash dump file and reviewed the ULS logs. There were some errors that made us think the issue might be related to the indexing of Visio VSD files, so we removed them from the File Type indexing list in Central Administration, and performed another incremental crawl and it looks like we have just about as many app pool crashes.
Dave,
Any new from your support ticket?
Permalink
Still nothing back from Microsoft, have chased again this morning.
Permalink
Can confirm also our SharePoint Subscription Edition WFEs are getting regular error Event ID 1000 related to w3wp.exe, owssvr.dll and KERNELBASE.dll
Faulting application name: w3wp.exe, version: 10.0.20348.1, time stamp: 0x405e4c14. Faulting module name: owssvr.dll, version: 16.0.19127.20100, time stamp: 0x689cd397. Exception code: 0xc0000409
Faulting application name: w3wp.exe, version: 10.0.20348.1, time stamp: 0x405e4c14. Faulting module name: KERNELBASE.dll, version: 10.0.20348.3932, time stamp: 0x4c7b412e. Exception code: 0xc06d007e
Faulting application name: w3wp.exe, version: 10.0.20348.1, time stamp: 0x405e4c14. Faulting module name: KERNELBASE.dll, version: 10.0.20348.3932, time stamp: 0x4c7b412e. Exception code: 0xe0434352
Permalink
Hi Timo,
to ensure that this is being analyzed, please open a ticket with Microsoft Support.
Cheers,
Stefan
Permalink
I see the same, In my case if you check C:\Windows\System32\LogFiles\HTTPERR. It fails when something try to access http://yoursharepointsite/site/_vti_bin/sharedaccess.asmx or http://yoursharepointsite/site/_vti_bin/sitedata.asmx Connection_Dropped SharePoint.
Permalink
I have tested SPSE September CU and SPS2019 September CU by uploading the same .vsd file to a document library and crawled both. SPS2019 crawls it successfully, but SPSE every time throws “Processing this item failed because the parser server ran out of memory. ( Error parsing document ssic://1159. Document failed to be processed. It probably crashed the server.”. Every time that file is crawled two .dmp files are written in “C:\Users\All Users\Microsoft\Windows\WER\Temp\”. So, I can confirm that there is a problem with .vsd files.
As in the past there was a problem with legacy office file crawling (like .doc) tested that too – no problem. Crawled.
Permalink
Hi Atis,
did you open a ticket to get this analyzed?
Cheers,
Stefan
Permalink
Hi Stefan,
Next week I probably will. Hopfully Dave will have more info to share by then.
Thank you!
Permalink
We already opened a ticket at MS. The issue has nothing to do with the Sept. CU 2025. It is in SharePoint SE since release. There was a wrong or bad iFilter for Visio included in the binaries. Currently it is unknown, when it get fixed, I expect somewhere by the end of the year. Meanwhile as a workarround you can take another iFilter for Visio from SP2019 or SP2016 and copy it over to SPSE. But be aware, that everytime you patch SharePoint, you need to copy it over again, because it get overwritten.
@Stefan: Holger has more info on this one.
Permalink
Thanks Richard!
Permalink
Unfortunately I have to disagree on ‘since release’ part. I tested the same .vsd file on farm with February patch applied (conf. db version 16.0.17928.20396) and file was crawled successfully.
By looking up HKEY_CLASSES_ROOT.vsd\PersistentHandler value I can determine filter used. In my case it resulting to HKEY_CLASSES_ROOT\CLSID{FAEA5B46-761B-400E-B53E-E805A97A543E}\InprocServer32 which stores path to iFilter used: C:\Program Files\Common Files\Microsoft Shared\Filters\VISFILT.DLL.
I have compared both .dll versions:
SPSE February: 16.0.17928.20396
SPSE September: 16.0.19127.20100
Cheers,
Permalink
I can narrow down to July (last) update (db: 16.0.18526.20508) – also crawled successfully.
iFilter version: 16.0.18526.20508
Permalink
Apparently problem with .vsd was introduced in September 2025 CU as farm with August CU (db version: 16.0.18526.20518) can crawl it too.
iFilter version: 16.0.18526.20518.
Cheers,
Permalink
3 potential causes of app pool crashes. I am working with Microsoft ticket on search crawl crashing target application app pool likely due to A calendar list or calendar web part because of specific views as shown in crashing dumps. Along with .vsd and .pdf issue, this likely warrants its own trending article, if not created yet. I am facing the issue after November 2025 CU.
Permalink
Hi Joseph,
yes – the C0000409 exception is caused by this.
But we have a variety of crashes with different exception codes and a variety of reasons which is not yet clear.
That is the reason that I haven’t created an article on this.
We are still investigating why such a variety of problems have occurred with recent builds.
Cheers,
Stefan
Permalink
Hello Dave,
Have you got any updates regarding your case? We have this issue on our front ends dedicated for the search crawl. It seems to be related to search crawl so luckily our other front ends are not affected.
Seems like a lot of people have the same issue here so just wanted to hear before I too open a case.
All the best,
David
Permalink
Hi David, we still have an ongoing conversation with Microsoft support to get to the bottom of this. Applying Octobers patch has reduced the issue but we are still seeing the dump/errors. They did suggest adding an exclusion rule to the crawl for https://*calendar.aspx which also reduced some but the overall problem does still exist.
Permalink
Thanks for the reply. Very interesting! My dump analysis showed issues with the Calendar rendering path and a failing thread inside OWSSVR.DLL (native) while .NET is in
Microsoft.SharePoint.WebControls.CalendarSourceView.initCollection() →
SPListItemCollection.EnsureListItemsData() →
SPRequest.GetListItemDataWithCallback2(…).
Permalink
Interesting. If you can repro this on a new web application, with new site collecton and new calendar list -> could be a problem in our code.
Otherwise these type of issues usually indicate a corrupt list which could not be properly initialized.
Permalink
Just as a quick follow-up Microsoft Support have managed to recreate this issue and are currently investigating how they are going to handle it. Stay tuned.
Permalink
Hi Dave,
Please update on Crawl as we too have same issue and crawling is not running automatically.
Thanks
Permalink
Hi Vishal, unfortunately the latest update, as of yesterday, is that Microsoft engineers are still working on how they are going to handle this issue.
Permalink
Same exact issue here, openning a suuport case.
Permalink
Got an update from support: confirmed it’s a known bug affecting some environments and causing the IIS worker to hang. They’re investigating, and the fix is planned for the February(!!!) patch.
Permalink
Hello Stefan,
after applying the September 2025 CU for SharePoint Subscription Edition all of our sites are down showing the “HTTP 500 Internal Server Error”. When trying to access the Central Administration the error is the same. We tried applying all the fixes you mentioned but it hasn’t resolved our issue. In IIS the whole configuration, bindings etc. also looks fine. Have you heard or encountered a issue like this? Are there any troubleshooting/fixing steps we can take right now?
Permalink
Hi Jacek,
my assumption is that you are running into this issue:
https://blog.stefan-gossner.com/2023/10/17/trending-issue-module-sprequestfiltermodule-could-not-be-found-after-september-october-2023-cu/
Cheers,
Stefan
Permalink
Hello Stefan,
Thank you for your precious attention on this particularly problematic update …
It seems I’m facing a new issue on workflows described here :
https://learn.microsoft.com/fr-fr/answers/questions/5563089/sharepoint-workflow-manager-after-september-2025-u
If you have any clue ?
Permalink
Hi Fred,
unfortunately I have not seen this issue myself and I’m currently not aware of a support case for this.
If you need assistance for this issue, please ensure to open a ticket with Microsoft Support to get this investigated.
Cheers,
Stefan
Permalink
We’ve ran into a new issue aswell aside from all the other things in this patch… All after the september patch.
“The Execute method of job definition Microsoft.Office.Server.Search.Analytics.AnalyticsJobDefinition (ID dfc82078-d207-4bcf-8e37-63788da62a8c) threw an exception. More information is included below.
Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.. (Correlation=2226c9a1-0c28-6096-668b-9ebc851d5ed5)”
We’ve checked that database and there is alot of activity but nothing that indicates that it would completly fill upp any pools…
This occurs on multiple jobs and eventually the search service application completly shuts down (takes 1-2 days). Restarting the timer service resolves the issue for 1-2 days again. This issue seem to affect our SPSE farms, not SP16.
Any thoughts or ideas? We’re leaning towards a Microsoft ticket for this one.
Permalink
Hi Ben,
I think going for a support ticket is the best option to get this analyzed quickly.
Cheers,
Stefan
Permalink
We are facing such errors since July CU. 2508080050002122 ticket was opened on August 8th and it is still open.
After 26 hours on various farms the following tasks start to fail:
Analytics Timer Job for Search Service Application Search Service Application (Microsoft.Office.Server.Search.Analytics.AnalyticsJobDefinition),
Query Logging (Microsoft.Office.Server.Search.Administration.QueryLogJobDefinition)
and Shared Services complain about ‘Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance’. All related to connection pool.
SPTimerV4 recycle solves the problem for next 26 hours (a ‘Timer Service Recycle’ timer job does not solve the problem).
Have not seen problems with SSA itself, though. Crawls does not seem to be affected (BDC and native).
Cheers,
Permalink
My environment:
SharePoint Server Subscription Editon on Windows Server 2022. MS SQL Server 2022 on Windows Server 2022.
We got the same issue:
The Execute method of job definition Microsoft.Office.Server.Search.Analytics.AnalyticsJobDefinition (ID 4c756a61-7007-4ab5-b69b-fcd1c6e4bd0a) threw an exception. More information is included below.
Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.. (Correlation=6d69caa1-23d2-7086-5d95-0d0db3bee298)
I found out, that it depends, as the error message says, that the max pool size was reached. I found out, that SharePoint allows a maximum of 100 connections to a database. In my case, the database “Service Application Search LinksStore” has 102 connections, and that should be the reason for this issue.
You can check it, when you execute the following sql query on your MS SQL Server:
SELECT DB_NAME(dbid) as DBName, COUNT(dbid) as NumberOfConnections
FROM sys.sysprocesses
WHERE dbid > 0
GROUP BY dbid;
When I execute the sql query:
sp_who
I see a lot of connections are “sleeping” in the status column, and I think this ist not correct. They should be closed.
I found out, that the database connection limit is 100 per default in SharePoint, but you can increase it up to more connections, but I still don’t know how, and if this is best practice.
I think, it has also something to do with ADO.NET, but I’m not familiar with it.
@Stefan Goßner: Can you please put this issue to the summary of issues, because in my opinion this is a big issue.
Permalink
Hi Stefan,
This is exactly the same Issue we have since August CU 2025 that I mentioned here: https://blog.stefan-gossner.com/2025/08/12/august-2025-cu-for-sharepoint-server-subscription-edition-is-available-for-download/#comment-39350
Seems like the Cases are still open with Microsoft and no fix was found yet. Really hope for October to have a fixed package.
Cheers,
Marc
Permalink
I found this article to this topic
https://stuffandtacos.azurewebsites.net/2015/11/22/max-pool-size-reached-on-sharepoint/
But I’m not sure, if this solves the problem.
Permalink
Hey Stefan,
We have a SharePoint Workflow Manager Server running on Windows Server 2022 and after the Windows Server 2022 OS Update for September 2025, the Service Bus Message Broker is stuck on starting. Any insight into this issue?
Thanks,
Daniel
Permalink
Hi Daniel,
I’m not aware of any issues caused by Operating System patches.
My suggestion would be to open a support case with Microsoft to get this investigated.
Cheers,
Stefan
Permalink
After the September CU (SharePoint Subscription Edition 16.0.19127.20100) we’re seeing repeat w3wp crashes on certain requests (notably calls hitting search/Managed Metadata endpoints). Faulting module: owssvr.dll; exception: 0xC0000409 (stack buffer overrun). Occasionally we also see 0xE0434352 and ASP.NET Event 1325 (SEHException) with stacks in System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion. Issue appears on API-style calls rather than standard SharePoint UI usage. This did not occur before the September patch, anyone else seeing this, or aware of a fix in a later CU?
Permalink
Hi Max,
this is not a known issue. Just checked: there is no ongoing investigation for such an issue.
I would suggest to open a ticket with Microsoft to get this analyzed.
Cheers,
Stefan
Permalink
We have most likely resolved our issues related to the September 2025 CU. Where the installation initially appeared successful, the environment was later found to be only partially upgraded and in a corrupted state. Investigation showed that “NT AUTHORITY\SYSTEM” was a member of the local WSS_WPG group, which conflicts with new security changes introduced in this update and likely prevented PSConfig from completing properly (probably because WSS_WPG is now explicitly denied write access to the _layouts directory).
After removing SYSTEM from WSS_WPG and re-running PSConfig, everything has since been stable without further issues. Interestingly, the CU adds SYSTEM back to WSS_WPG during installation, in contradiction to Microsoft’s own guidance…
Permalink
Hi Max,
We are seeing exactly what you described with owssvr.dll; exception: 0xC0000409. Also seems related to API-calls to SharePoint. Did I understand you correctly that runnign psconfig resolved it? We never installed september CU so SYSTEM should not be a problem if I understood Stefan correct.
Permalink
Feedback from Microsoft Support:
This is a known issue caused by a regression in the September 2025 Cumulative Update, leading to worker process crashes (0xc0000409) in owssvr.dll.
Our Product team is actively working on a fix, which will be released soon.
Permalink
Hi Stefan, appreciate your efforts here. We had the nasty issue with the SharePoint Workflow Manager not being able to be Configured.
The command and message follow;
PS C:\Program Files\Workflow Manager\1.0> Add-WFHost -WFFarmDBConnectionString ‘Data Source=prodsharepointdb;Initial Catalog=WFManagementDB;Integrated Security=True;Encrypt=False’ -RunAsPassword $WFRunAsPassword -EnableFirewallRules $true -SBClientConfiguration $SBClientConfiguration -CertificateAutoGenerationKey $WFCertAutoGenerationKey -Verbose;
VERBOSE: [2/10/2025 08:49:10]: Validating input and configuration parameters.
VERBOSE: [2/10/2025 08:49:10]: Installing auto-generated certificate.
Add-WFHost : Keyword not supported: ‘asynchronous processing’.
At line:1 char:1
+ Add-WFHost -WFFarmDBConnectionString ‘Data Source=prodsharepointdb;In …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Add-WFHost], ArgumentException
+ FullyQualifiedErrorId : System.ArgumentException,Microsoft.Workflow.Deployment.Commands.AddWFHost
The solution was to update the database and remove “Asynchronous Processing=True” using the following query;
SELECT *
FROM [WFManagementDB].[Store].[ServiceConfig]
Begin Transaction
Update [WFManagementDB].[Store].[ServiceConfig]
SET value = ‘Data Source=prodsharepointdb;Initial Catalog=WFInstanceManagementDB;Integrated Security=True;Encrypt=False’
Where Name = ‘WorkflowServiceInstanceMgmtDBConnectionString’
Update [WFManagementDB].[Store].[ServiceConfig]
SET value = ‘Data Source=prodsharepointdb;Initial Catalog=WFResourceManagementDB;Integrated Security=True;Encrypt=False’
Where Name = ‘WorkflowServiceResourceMgmtDBConnectionString’
SELECT *
FROM [WFManagementDB].[Store].[ServiceConfig]
Commit Transaction
Permalink
Hi Graham,
this is a known issue. Unfortunately the solution requires to update an entry in the database.
Direct database modifications require approval from the product group.
Please open a ticket to ensure that support can get approval for the update in your environment.
Cheers,
Stefan
Permalink
Otherwise you can leave the farm, remove sbmanagementDB and WFmanagementDB and recreate the farm as part of a disaster recovery (https://learn.microsoft.com/en-us/sharepoint/governance/sp-wf-mgr-farm-restore-disaster-recovery) which is supported and quite painless ..
Permalink
Hi Stefan,
Maybe a bit unrelated to this CU, but we have identified that on some Farms (Subscription Edition), several .js files (from C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\Next\spclient...) (e.g.: sp-pages-assembly.js, sp-classic-page-assembly.js, listview-host-assembly.js) were not updated by this CU, neither by the previous CUs for a long time.
All other files have a new modified date, except these ones. Need to mention that these files were modified by us a long time ago after having this issue: https://learn.microsoft.com/en-us/answers/questions/1373533/sharepoint-server-subscription-changing-look-and-f – I know it’s a bad practice, but we had to do it at that moment.
The question is: does modifying a js file from the Layouts prevent them to be updated by SharePoint Update in the future?
Many thanks!
Permalink
This might be related to the same issue I described in my post above.
In our case, the CU appeared to install successfully, but parts of the environment were not upgraded because “NT AUTHORITY\SYSTEM” was a member of WSS_WPG, which now has deny write permissions on the _layouts folder. That prevented some files from being updated during patching. If those JS files couldn’t be overwritten due to modified ACLs or manual edits, it’s likely the same underlying cause. Removing SYSTEM from WSS_WPG and re-running PSConfig resolved it for us.
Permalink
Yes – this can also cause the problem of course if it only happens with September CU.
Permalink
Hi Andrei,
potentially yes. I have seen this happening a couple of years ago in my own environment. It is required to take a backup of the original file and restore them before installing a patch to guarantee that the MSI installer will update them.
Cheers,
Stefan
Permalink
Hi Stefan,
Since September CU we have been experiencing problems with totals in task lists. Other types of lists seem to work fine. The problem occurs if the view is filtered. The result is either that the total is blank or that it is calculated incorrectly. The error occurs with all types of totals (count, average, maximum, minimum, sum, std deviation, variance). It never happens in a grouped view though. Is this a known issue? Anyone else experiencing this?
Regards,
Nicklas
Permalink
Hi Nicklas,
I’m not aware of this issue as of now.
Best would be to open a ticket with Microsoft Support to ensure this gets investigated.
Cheers,
Stefan
Permalink
Good day All,
I have tried to install the new October CU KB5002786 on two SharePoint Subscription Edition farms, but after 3 hours installation fails. I have tried to restart and retry but the issue is the same. Do you have any evidence of the same problem?
Regards
Massimiliano
Permalink
Hi Massimiliano,
please check if WSS_WPG or IIS_IUSRS group contain NT AUTHORITY\system.
If yes remove it.
See here for details:
https://blog.stefan-gossner.com/2025/09/11/trending-issue-sharepoint-fixes-fail-to-install-after-installation-of-september-2025-cu/
Cheers,
Stefan
Permalink
Thanks to your suggestions, everything works now.
Thanks!
Permalink
Hi Stefan,
After applying September 2025 CU patching, AppFabric Caching Service is stopped running in App server. No issues in web server. we already removed the Farm service account from the local admin group & WSS_WPG or IIS_IUSRS group doesn’t contain NT AUTHORITY\system I gave read & execute permission to the farm service account for AppFabric 1.1. Windows Server folder. still the same. I am getting ‘Error:5 Access is denied’. Please help me on this.
Permalink
Hi Bas,
I would suggest to take a process monitor log to see if the access denied is somewhere on file system level.
Also check the ULS log for more specific details.
If you need further assistance with this my recommendation would be to open a ticket with Microsoft Support.
Cheers,
Stefan
Permalink
Good day All,
After KB5002784 & KB5002786 Nintex workflow stopped to work correctly. I have analyzed tracelog files and I have found this unexpected error:
“Compilation failed. Cannot execute a program. The command being executed was "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /noconfig /fullpaths
It seems an old issue, but i have checked the “exploit protection section” and all is configured correctly.
Do you have any evidence of the same problem?
Regards
Massimiliano
Permalink
Hi Massimiliano,
this is a known issue. See above at “SP2010 workflows fail on SPSE”.
Details and solution are listed here:
https://blog.stefan-gossner.com/2025/09/18/trending-issue-sharepoint-sp2010-workflows-fail-on-spse-after-installing-september-2025-cu/
Cheers,
Stefan
Permalink
Hello Stefan!
Thanks for all the information you put out in these messy times.
One question:
In a few articles and in many comments you talk about WSS_WPG, IIS_IUSRS, local admin groups as well as what accounts should and should not be used in CA under “Configure service accounts” for each service.
With the updated SharePoint security that comes with the latest patches…could you please create an article where you specify what configuration is the correct one moving forward?
I you could provide like a checklist that would be fantastic. Then we all can go through all severs/farms and make sure we are set moving forward.
I´ve tried on my own to summarize your security recommendations but it´s hard to get it right.
This should come from you in my opinion. You already have the overall view.
Thanks!
Permalink
Hi Frederik,
thanks for the suggestion!
FYI: Going forward from October CU it is possible to keep the existing configuration for the service accounts. Its no longer necessary to update them, as the critical change introduced in September 2025 CU was reverted with October CU due to the significant amount of problems that were introduced.
As of now there is no need to update any account here.
In case further restrictions are implemented in the future the relevant guidance will be made available based on these future requirements.
With other words: if the previous patch level is August 2025 CU or oder and you are going to October 2025 CU you can just install it and you are good.
Only if September 2025 CU was installed before October 2025 CU an additional action is required and that is to remove the local system account (NT AUTHORITY\system) from the WSS_WPG and the IIS_IUSRS group – otherwise October CU will not install.
Hope that helps.
Cheers,
Stefan
Permalink
Okay I see. Thanks for clarification!
Permalink
I am So glad the Oct CU fixes all the problems Microsoft created, the only issue is it WILL NOT INSTALL due to the problems Microsoft caused.
Permalink
Hi SB,
it will install with these steps:
– remove deny ACE for WSS_WPG from …\template\14\layouts folder
– remove deny ACE for IIS_ISURS from …\template\14\layouts folder
– remove deny ACE for WSS_WPG from …\template\16\layouts folder
– remove deny ACE for IIS_ISURS from …\template\16\layouts folder
Afterwards the installation of the fix should work.
Cheers,
Stefan
Permalink
Hi Stefan,
Do we know when this app pool crash issue will be fixed for SPSE. As we installed SPSE OCT2025 CU and since then app pool is getting crashed intermittently.
If we know the fix details it will really help.
Permalink
Hi Ketan,
If you are talking about crashes with Exception Code C0000409 – the issue is still under investigation.
Cheers,
Stefan
Permalink
Thanks for the update hopefully this get fixed in Jan 2026 CU so this is impacting our environments.
Permalink
I am also encountering similar to “Timo P”
Faulting application name: w3wp.exe, version: 10.0.20348.1, time stamp: 0x405e4c14. Faulting module name: KERNELBASE.dll, version: 10.0.20348.3932, time stamp: 0x4c7b412e. Exception code: 0xc06d007e
Faulting application name: w3wp.exe, version: 10.0.20348.1, time stamp: 0x405e4c14. Faulting module name: KERNELBASE.dll, version: 10.0.20348.3932, time stamp: 0x4c7b412e. Exception code: 0xe0434352