Reputation: 21
For some reason my application pool keeps crashing once in a couple of days. The biggest problem is that there are no logs about errors or warnings in my administrative events about this pool. (there are several warnings in other pools, but it is only this pool that keeps crashing). Changes I make can only be tested if they worked if I wait a couple of days.
I tried to bring my code back to the stage where the problems did not occur, but this does not seem to help.
Most crashes happen when the site is not very busy, although not that inactive that IIS shuts it down for inactivity.
Windows server 2008 R2 (SP 1), IIS Build 7.5.76, Umbraco, Sql server 2008
IIS logs: only showing some recycling of the pool (once every 3 hours) Rapid fail detection: disabled
Where should I start with solving this problem?
Upvotes: 0
Views: 3657
Reputation: 1017
WER (Windows Error Reporting) should have made crash dumps for you unless disabled. The default location for the crash reports is c:\ProgramData\Microsoft\Windows\WER\ReportQueue\ , but as far as I can remember, the Windows event log entry for the crash contains the full path for the dump file (Application event log). Pop it into your VS and check what went wrong.
You can also try installing DebugDiag, but personally I highly do NOT recommend it on a production server as it screws up the WER configuration for its own purposes in an unreversible way affecting other applications too.
Upvotes: 1
Reputation: 3315
I'd start by running the risk application on a different application pool to minimize the impact.
There is an iss property which stops the app pool from rebooting after 5 errors occur in x minutes.
You could try increasing this setting, it should give you an idea to how frequent this is happening and if it goes wrong once it'll keep going wrong or not.
If it's a wcf service you can enable tracing logs(which log quite a lot , maybe even your error).
As for places to look i would recommend checking out stack overflows and multi threaded code.
Both of these can cause situations in which the event log will contain no information.
Upvotes: 0
Reputation: 107000
The standard approach is to start making trace log files. Write detailed log messages at every critical point in your application - when the request starts, when it ends, somewhere in the middle, when doing DB operations, etc. The logfiles will probably take up gigabytes at the end of the day, but you can afford that for a little while. Then, when it crashes again, check the logfile to see what was the last thing it was doing before the crash. If there's not enough detail, add more logging and repeat.
Upvotes: 1