In the last couple of weeks we have received several reports of for SharePoint Server Subscription Edition application pool worker process crashes with a combination of the following Exception codes 0xC06D007E and 0xE0434352 being reported in the event log similar to these:
Faulting application name: w3wp.exe, version: 10.0.20348.1, time stamp: 0xcfdb13d8
Faulting module name: KERNELBASE.dll, version: 10.0.20348.4294, time stamp: 0x689cd397
Exception code: 0xc06d007e
Fault offset: 0x0000000000041b39
Faulting process id: 0x32fc
Faulting application start time: 0x01dc37c6ba77ea7f
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: 7e7b773c-9f8a-45bd-85ae-fc587c155e4d
Faulting module name: KERNELBASE.dll, version: 10.0.20348.4294, time stamp: 0x689cd397
Exception code: 0xc06d007e
Fault offset: 0x0000000000041b39
Faulting process id: 0x32fc
Faulting application start time: 0x01dc37c6ba77ea7f
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: 7e7b773c-9f8a-45bd-85ae-fc587c155e4d
and
Faulting application name: w3wp.exe, version: 10.0.20348.1, time stamp: 0xcfdb13d8
Faulting module name: KERNELBASE.dll, version: 10.0.20348.4294, time stamp: 0x689cd397
Exception code: 0xe0434352
Fault offset: 0x000000000003f33c
Faulting process id: 0x32fc
Faulting application start time: 0x01dc37c6ba77ea7f
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: d0aafe37-7956-48db-be27-7c034d2da6eb
Faulting module name: KERNELBASE.dll, version: 10.0.20348.4294, time stamp: 0x689cd397
Exception code: 0xe0434352
Fault offset: 0x000000000003f33c
Faulting process id: 0x32fc
Faulting application start time: 0x01dc37c6ba77ea7f
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: d0aafe37-7956-48db-be27-7c034d2da6eb
You might see more than one of each of these events in the event log before the process terminates.
Solution
We have meanwhile been able to reproduce the issue and analyze it.
A fix is currently in development.
Permalink
I have a potential workaround. We had the same error messages for OWSTIMER.exe which was resolved by creating an exemption from the DISA Baseline GPOs for Windows server 2022.
Path:
Computer/Admin Templates/Windows Components/Microsoft Defender Antivirus/Microsoft Defender Exploit Guard/Attack Surface Reduction
Policy: Exclude files and paths from Attack Surface Reduction Rules
Setting: Enabled
Exclusions from ASR rules:
– “C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\BIN\OWSTIMER.exe”
assuming you can include the paths above:
c:\windows\system32\inetsrv\w3wp.exe
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\isapi\owssvr.dll
For some reason, SharePoint binaries seem to be included in the “Office” definitions.
Permalink
Hi Brian,
I don’t think this will help.
I have debugged the problem and the problem here is a race condition between two threads executing http requests.
Cheers,
Stefan
Permalink
Ah ok – thanks! This resolved an issue presenting as workflow issues (pauses were failing).
Permalink
Sounds as if you were running into this issue:
https://blog.stefan-gossner.com/2025/09/18/trending-issue-sharepoint-sp2010-workflows-fail-on-spse-after-installing-september-2025-cu/
Permalink
Hello Stefan
I have the same codes, i.e. 0xC06D007E and 0xE0434352, but with KernelBase.dll . Is it the same issue?
Permalink
Hi Joseph,
thanks a lot!
You are right – it is KernelBase.dll. Was a copy&paste error when formatting the blog post. Copied to many details.
The post has been updated.
Cheers,
Stefan
Permalink
Hi,
I couldn’t find a proper workaround, so I decided to create a Windows scheduled task that checks every minute whether the SharePoint application pools are still running. If an application pool has crashed, it is automatically restarted.
While this is not a very professional or long-term solution, it works for us until a permanent fix is available.
Regards,
Johan
Permalink
Hi Johan,
I’m not sure why this would be necessary. IIS does this automatically.
And in case that IIS stops doing this due to too many crashes happening in a short timeframe you can disable “failfast” in the application pool settings and IIS will always restart it.
Cheers,
Stefan
Permalink
Thanks for acknowledging this.
we had to put search on a separate wfe, it got bettet for us.
Premier Support at ms do not earn its name. Like banging the head against a wall.
Permalink
Hi Eric,
it took us several weeks to get an inhouse repro and on top of this several days to be able to get the correct set of data from this repro to allow us to debug it.
Understanding the problem was really not a trivial issue – so please do not blame support for this.
Cheers,
Stefan
Permalink
Thanks for your work !! i guess i’m just frustrated over the struggle with indian communication..
Permalink
Hi Stefan,
OK, this explains why this only occurs on our dedicated WFE servers that are used by the SharePoint Search farm crawlers. The app pools regularly crash during crawls, and after a while the application pool remains disabled. I wasn’t aware of the ‘failfast’ settings. Thanks for the tip 🙂
Thanks!
Johan
Permalink
This seems to help. Not recommended if public facing SharePoint as it effectively disables AMSI:
Run PowerShell as Administrator
$sites = (“Site1″,”Site2”)
foreach ($site in $sites)
{
& $env:SystemRoot\System32\inetsrv\appcmd.exe set config $site
/section:system.webServer/modules/-“[name=’SPRequestFilterModule’]”
Verify
& $env:SystemRoot\System32\inetsrv\appcmd.exe list config $site `
/section:system.webServer/modules | Select-String “SPRequestFilterModule”
}
Permalink
Hi Joseph,
yes this will help – but is not recommended for security reasons.
AMSI is an important security feature which protects the machines against a variety of attack vectors.
We have seen the impact of this protection during the July zero day exploit where machines protected by AMSI were fully protected compared to machines without this protection.
Cheers,
Stefan
Permalink
Hi all,
I have been able to minimize the impact of search crawlers by partially reducing the impact it has on crawl targets by using:
Set-SPEnterpriseSearchService -PerformanceLevel PartlyReduced
Permalink
Hi Robi,
yes, this makes sense.
As the issue is caused by a race condition between different http requests being executed in parallel reducing the load significantly reduces the chance of getting hit by this issue.
Another suggestion would be to use a dedicated WFE for crawling which is not part of regular load balancing to minimize the impact on users browsing the site if worker process restart after crashes.
Cheers,
Stefan
Permalink
What is the current, best-practice method of designating a specific WFE for crawling?
On one of our “APP with Search” servers, we’re using the hosts file to point all URLs to localhost. That could be changed to point to a specific WFE. Are there better ways?
Thanks for all your hard work, Stefan! And happy holidays. 🙂
Permalink
Hi Will…
This is the most common way it is done.
There is also the option to configure dedicated crawl servers for each web application. This can be done using the webapplication property $w.SiteDataServers, but i have almost never seen this in the wild
Permalink
Hi Heiko!
Thanks for confirming. Yes, I also remember something about the .SiteDataServers property, but it’s rarely or never mentioned by anyone…
Best regards, W
Permalink
Hi Stefan,
yes, if we have multi server farms, I do tend to configure crawl server to either crawl itself of to have separate crawl targets.
Permalink
Do we know which patch month is associated with this issue? Or at least which one is not?
We are currently on a long process to upgrade a very high number of farms to October 2025 atm
Permalink
It was introduced in September 2025 CU for Subscription Edition.
Permalink
No this is not correct.
The first reports for this issue were reported after the July 2025 CVE fix.
Cheers,
Stefan
Permalink
Hi Stefan,
I have not applied the September CU in SPSE and I am glad I did not.
With regards to all these other issues cropping up, I am going to wait.
What are your thoughts on just waiting for January?
Permalink
Hi Richard,
delaying the installation of fixes means that important security fixes are not applied.
The evaluation of delaying the installation of these secuerity fixes needs to be carefully evaluated.
You can also take into consideration that most of the remaining issues are planned to be fixed in February CU.
Cheers,
Stefan
Permalink
Is there any way to track down, which http request that triggers the Application Pool crash ?
We found out that something with a calendar web part created the crash regarding to owssrv.dll in the Application Log.
Permalink
Hi Tomas,
per my knowledge this is only possible by analyzing a dump when the process crashed.
That’s how I identified the issue in customer cases.
Cheers,
Stefan
Permalink
Hello Stefan,
Hello Stefan
I have the same code 0xe0434352 with KernelBase.dll for workflow service. Is it same issue?
Faulting application name: Microsoft.Workflow.ServiceHost.exe, version: 16.0.19127.20336, time stamp: 0xb30d63ba
Faulting module name: KERNELBASE.dll, version: 10.0.26100.6899, time stamp: 0x761b8f73
Exception code: 0xe0434352
Fault offset: 0x00000000000c804a
Faulting process id: 0x2874
Faulting application start time: 0x1DC7F43EC727B8D
Faulting application path: C:\Program Files\Workflow Manager\1.0\Workflow\Artifacts\Microsoft.Workflow.ServiceHost.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Permalink
Hi Abu,
no this is something different. Please open a support case with Microsoft to get this investigated.
Cheers,
Stefan