1. Record the exact URL, request time, login state and action that produced the error. Determine whether it affects one page, one application or every site.
2. Open the affected site's IIS request log. Match the request and record sc-status, sc-substatus and sc-win32-status, using the log's field header.
3. Compare recent deployment, configuration, runtime and credential changes. Check the application pool and actual application folder.
4. Review the Application event log and the application's own protected logs at the same time. For ASP.NET Core startup failures, include events from the hosting module.
5. Use local detailed errors or an isolated test copy to obtain diagnostic detail. Keep detailed errors and developer exception pages away from public visitors.

If the available logs do not identify the failing module, confirm the IIS Tracing role service is installed. In IIS Manager, select the site, open Failed Request Tracing Rules and add a rule for the relevant content and failing status.

Enable Failed Request Tracing for that site and set a protected output directory and bounded file count. Reproduce the issue once, inspect the trace and disable temporary collection afterwards. A trace can contain request details that should not be posted publicly.

For an ASP.NET Core startup problem, temporary module stdout logging may help. Use a directory writable by the intended pool identity, inspect the resulting error and disable the diagnostic setting when finished. Do not leave unlimited diagnostic files growing on the system volume.

Fix the specific missing dependency, invalid configuration, permission or application exception supported by the evidence. Repeat the original request and a nearby working function. Preserve the error and change record if the application developer must continue the investigation.

In PowerShell on the affected Windows Server, collect recent application errors after recording the failed request time. This reads at most 30 warning or error events. It does not enable public detailed errors or change the website.

Get-WinEvent -FilterHashtable @{
  LogName = 'Application'
  Level = 2, 3
  StartTime = (Get-Date).AddMinutes(-15)
} -MaxEvents 30 | Select-Object TimeCreated, ProviderName, Id, Message

Read the result: Match the provider, application and time with the IIS request log's sc-status, sc-substatus and sc-win32-status. A nearby unrelated application error is not sufficient evidence. Some application failures are written only to the application's own log or a configured tracing destination.

Use the matching exception, missing component or configuration error to choose the next investigation. Keep connection strings, request contents and customer data out of shared diagnostic excerpts. If events do not identify the cause, configure a bounded Failed Request Tracing rule for the specific failing request.

• Enabling and using IIS request logs
• Investigating a Windows service failure with Event Viewer
• Choosing and securing an IIS application-pool identity
• Diagnosing IIS HTTP 503 Service Unavailable

• Microsoft: troubleshoot IIS HTTP errors
• Microsoft: IIS application pool identities
• Microsoft: IIS site log files

• Microsoft: Get-WinEvent