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

Question

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?

Answer 1

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.

Answer 2

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