ASP.NET Errors Not Logging to Application Event Viewer on Windows Server 2025

Question

ASP.NET Errors Not Logging to Application Event Viewer on Windows Server 2025

Freerk Duursma 15

Running ASP.NET sites in IIS on Windows Server 2025 results in ASP.NET errors failing to log correctly to the Application Event Viewer.

Whenever an event with the Source ASP.NET 4.0.30319.0 is raised, it does not show the error or stack trace. Instead, it displays the following error message:

System.Web.HttpException (0x80004005): The EventLogWebEventProvider provider failed to log an event with the error code 0x80070057.

   at System.Web.Management.EventLogWebEventProvider.ProcessEvent(WebBaseEvent eventRaised)
   at System.Web.Management.WebBaseEvent.RaiseInternal(WebBaseEvent eventRaised, ArrayList firingRuleInfos, Int32 index0, Int32 index1)

It appears that the system intends to raise an HttpException, but it cannot write it to the event viewer. We are not using any custom logging providers, but all is handled by the IIS defaults.

A testing page that raises an HTTP Exception was created and placed in the default website, running under the default ApplicationPoolIdentity. This configuration works on other servers, but fails on all Windows Server 2025 installations. Is this a known problem and are there any ways I can restore the logging functionality?

Marco Testa 15 Reputation points

2025-06-24T14:52:20.04+00:00

I have the same exact problem with a Windows server 2025.

In my case the application pool is using a user different than ApplicationPoolIdentity, I checked also permission on the Application.evtx file to be sure the user has sufficient permissions to write the file and that's it.

2 answers

Your answer

Marco Testa 15 Reputation points

2025-06-24T14:52:20.04+00:00

I have the same exact problem with a Windows server 2025.

In my case the application pool is using a user different than ApplicationPoolIdentity, I checked also permission on the Application.evtx file to be sure the user has sufficient permissions to write the file and that's it.

Answer 1

Hello Freerk Duursma,

On Windows Server 2025 the built‑in ASP.NET event source either isn’t registered correctly or the default ApplicationPoolIdentity no longer has rights to write to the Application log, so you get the 0x80070057 invalid parameter error when the EventLogWebEventProvider fires. You can restore full logging in a few minutes:

I) Re‑register ASP.NET’s event source

# ensure IIS‑ASP.NET45 is enabled, then:
dism /online /enable-feature /featurename:IIS-ASPNET45 /all  
& "$env:windir\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe" -i  
# or simply:
New-EventLog –LogName Application –Source "ASP.NET 4.0.30319.0"

II) Grant your AppPool identity write ACLs on the log file and registry

# replace DefaultAppPool with your pool name if different
$appPool = "IIS APPPOOL\DefaultAppPool"
# EVTX file ACL
$logFile = "$env:windir\System32\winevt\Logs\Application.evtx"
$acl    = Get-Acl $logFile
$rule   = New-Object System.Security.AccessControl.FileSystemAccessRule($appPool, "Write","Allow")
$acl.AddAccessRule($rule); Set-Acl $logFile $acl
# Registry ACL
$regKey = "HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Application"
$acl    = Get-Acl $regKey
$rule   = New-Object System.Security.AccessControl.RegistryAccessRule($appPool,"SetValue,WriteKey","Allow")
$acl.AddAccessRule($rule); Set-Acl $regKey $acl

III) Recycle your AppPool (or IIS) and repro

You should now see the full exception and stack trace in the Application log.
Workaround: If you’re still blocked, you can switch to the file‑based provider in your web.config to write errors to disk via System.Web.Management.FileWebEventProvider until a Server 2025 patch ships.

I hope this helps.
Finn

Edward Forgacs 5 Reputation points

2025-08-07T07:10:45.39+00:00

I wish this worked, sadly it simply does not. Note that the regiis command

& "$env:windir\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe" -i

Has not worked on recent versions of Windows (for quite some time), which makes me think the "workaround" had not actually been tested.

Additionally, ASP.NET 4 was already installed and would be necessary for the error to be generated in the first place. The DISM command did succeed, but didn't make any changes, as it was already installed.

The "FileWebEventProvider" referred to, does not exist in the ASP.NET docs. https://learn.microsoft.com/en-us/dotnet/api/system.web.management.webeventprovider?view=netframework-4.8.1 This answer is suspiciously starting to sound like the work of an AI bot.

I am requesting confirmation as to whether the workaround actually been tested? Are there any other changes which need to be made to assign permissions?

Answer 2

Georgiana Nitu 10 Microsoft Employee

Hi, The fix for the issue is here

August 28, 2025-KB5064401 Cumulative Update for .NET Framework 3.5 and 4.8.1 for Windows 11, version 24H2 and Microsoft server operating system version 24H2 - Microsoft Support

Thus, the behaviour is restored to the expected one.

Marco Testa 15 Reputation points

2025-09-23T08:41:50.4466667+00:00

Hi, the issue is solved after installing the update