Application pool crashes can quickly locate the causes by analyzing the IIS log. 1. First check the W3SVC log at the crash time point, search for 503 errors, and determine whether it is caused by application pool crash or frequent recycling; 2. Combined with the HTTPERR log, check whether there are any underlying error entries such as Connection_Dropped or RequestQueueFull, and confirm that the backend cannot respond; 3. Check the application and system logs in the event viewer, find events such as 5002, 5015, 5017 from WAS or IIS-WMSVC sources, and confirm that the application pool life cycle abnormality; 4. Troubleshoot common causes, such as code exceptions, unavailability of dependencies, rapid failure triggers, memory leaks, etc., and combine debugging tools and performance monitors to further analyze. Through multi-log cross-validation, gradually narrow the scope of the problem.

When your website runs on IIS, you will occasionally encounter the problem of application pool crashing. Although event viewers and logs can provide some clues, many times the truly useful information is hidden in IIS's log files. By analyzing these logs, you can locate the root cause of the problem faster, rather than relying on guessing or restarting to solve the problem.

View exception time points in IIS log

By default, IIS will generate log files in C:\inetpub\logs\LogFiles directory, and each site has a separate folder. First, you need to confirm the approximate time when the application pool crashes, and then find the log entry for the corresponding time period.

Common practices are:

• Open a log file that takes several minutes before and after the crash
• Search for requests with status code 503 (service is not available)
• Note the continuous 503 errors, which usually means that the application pool has just crashed or is being recycled frequently

503 The error is not always caused by an application pool crash, but it is an important signal. Combined with the startup time and failure limits of the application pool, it can be determined whether the application pool is disabled due to the fast failure protection mechanism.

Combining W3SVC logs and HTTPERR log cross-analysis

In addition to IIS's own W3SVC log (record access information by site), there is another often overlooked HTTPERR log, which is located in C:\Windows\System32\LogFiles\HTTPERR by default.

The difference between these two logs is:

• W3SVC log : records the details of successful or failed HTTP requests, such as which page the user visited and what status code it returned.
• HTTPERR log : It records more underlying errors, such as connection timeout, protocol error, and server busy.

When you see a large number of entries like Connection_Dropped or RequestQueueFull appear in HTTPERR, it may indicate that the backend application pool is no longer able to respond to the request, further demonstrating the application pool crash or hang.

In addition to looking at logs, check system logs and application logs

The IIS log itself does not tell you why the application pool crashes. To get a deeper diagnosis, you also need to check:

• Windows Event Viewer → Application Logs and System Logs
• Find entries from WAS (Windows Process Activation Service) or IIS-WMSVC
• Pay attention to event IDs: 5002, 5015 , 5017 and other events related to the application pool life cycle

For example, if you see a log with event ID 5002, which looks like "Application pool 'MyAppPool' is being disabled because it failed to recycle", it means that the application pool is disabled due to failed recycle.

In addition, if Failed Request Tracing is enabled for IIS , more detailed error stack information can be obtained from it.

Common causes and investigation suggestions

After finding clues from the log, the next step is to find out the specific reason. Here are some common causes and troubleshooting methods that cause application pool crashes:

• Code exception not handled
  For example, NullReferenceException or StackOverflowException in .NET will cause the w3wp.exe process to crash. You can further analyze by enabling Windows Error Reporting (WER) or generating memory dumps using debugging tools such as DebugDiag.

• Dependence on services or resources is not available
  Problems such as not being able to connect to the database, failing to load third-party components, insufficient permissions, etc. may also indirectly cause crashes. Check whether there are keywords such as database connection timeout and COM component call failure in the log.

• Fast failure protection trigger
  If the app pool frequently crashes (such as multiple times per minute), IIS will automatically disable the app pool. Check the Quick Fault Protection option in the App Pool settings and adjust the threshold appropriately.

• Memory leak or excessive use
  If there is no obvious error in the log, but the application pool crashes regularly, it may be that the memory usage exceeds the limit. You can use the performance monitor (perfmon) to view the memory usage trends of w3wp.exe.

Basically that's it. Diagnosing application pool crashes is not a one-step task, and it requires cross-verification of multiple log sources. The key is to start with IIS logs, find the exception time points, and then gradually narrow the scope with system logs and actual code behavior.

The above is the detailed content of How to diagnose application pool crashes from IIS logs?. For more information, please follow other related articles on the PHP Chinese website!