several time in day my Application pool is stopped with following error:
Application pool 'MyApplicationPool'
is being automatically disabled due to
a series of failures in the
process(es) serving that application
pool.
How to resolve this?
thanks, for the any advice.
This is because your application pool is crashing more than 5 times in 5 minutes [default settings - Rapid Fail]
Instead of disabling Rapid Fail, you should consider taking Crash Dumps and try to find out the root cause. http://blogs.msdn.com/b/rahulso/archive/2006/03/02/what-is-a-crash-technically-in-asp-net-and-what-to-do-if-it-happens.aspx
I had the same problem and after some struggle I realized it was caused by a change in my domain password that runs the application pool. Going to the application pool > Advanced Settings > Process Model > Identity and set it with the new password.
You may not have the same exception causing the application pool to recycle, but this answer should address your situation as well: A process serving application pool 'Classic .NET AppPool' suffered a fatal communication error with the Windows Process Activation Service. HTTP Error 503
The gist of it is that something in your application is causing the app pool to keep recycling itself. You'll need to determine what is throwing so many exceptions. After you've fixed the cause of the exceptions, your app pool should run without recycling itself to the point where it hits the Rapid Fail Protection limit.
I had this same problem and after a few hours of wrestling with it and following solutions that didnt work, I went to Application Pool > Advanced Settings > Process Model > Identity and set it to LocalSystem. Magcally, the whole thing worked.
Related
I've seen a ton of questions about this, but it seems like I'm missing something fundamental here.
I've seen this article by Microsoft: https://support.microsoft.com/en-us/topic/resolving-view-state-message-authentication-code-mac-errors-6c0e9fd3-f8a8-c953-8fbe-ce840446a9f3
Here they detail 4 different causes of this exception:
The application is running in a web farm
The worker process uses the IIS 7.0 application pool identity
The application pool is configured by using LoadUserProfile=false
The Page.ViewStateUserKey property has an incorrect value
In my scenario, there is only a single webserver, we're on IIS 10, and we are not using Page.ViewStataeUserKey.
We DO have LoadUserProfile=false on the app pool. However, they list using an explicit as a resolution to avoid this exception.
In our web.config, we have an explicit machineKey element set under configuration->system.web.
We are still seeing this exception logged from time to time. So my question is:
Why am I still seeing this exception?
Have I misinterpreted how to resolve this issue?
Is it possible that there has been tampering with the view state and this is why this exception occurs from time to time?
I have a rather large ASP.NET Core application running in an IIS application pool with overlapped recycling. I have set IHostApplicationLifetime handlers and I see that it is hitting all of the lifecycle methods as well as the AppDomain.CurrentDomain.ProcessExit handler that I've set. When I request a recycle, here's what happens:
ApplicationStopping is hit
ApplicationStopped is hit
Dependencies configured in Startup are disposed
Breakpoint after webHost.Run() in Program.cs is hit (this is the last line of the Main method of the program)
ProcessExit handler is run
At this point I would expect w3wp to be dead. But no, it lingers around for quite a while after, and continues to take a lot of memory. I also can view it in Process Explorer and I see it still has a bit of activity.
I guess the obvious things to look for are things that need to be disposed, but I don't know how to look for these. How can I figure out why w3wp will not go away for such a long time / what is keeping it around?
As far as I know, hit the ProcessExit handler means the asp.net core application has been down, not the w3wp.exe.
The w3wp.exe is managed by IIS not the websites. The IIS will check the w3wp.exe is free or not(handing request). If there is no request coming in about 20 minutes(by default). Then the IIS will stop the w3wp.exe.
The IIS console manager contains the idle timeout value. If you want to shut down the w3wp.exe as soon as possible. I suggest you could reduce the value to 1 which means if there is no request coming in 1 minutes, it will stop the w3wp.exe.
More details about how to set it, you could refer to below steps:
Open the IIS management console and find the application pool
2.Click the advanced setting and modify idle time-out
I'm working on a ASP Net MVC system, and the problem i'm having since the begining is that my session variables and static variables are getting reset after some time around 30-45 minutes (but i'm not sure it happens always).
The options i've already tried:
* Change session timeout from the config file
* Check recycling time
* Use server state session instead of in process
* Maybe something else i don't remember
I don't know what else to try, or where to investigate, and i don't have a certain clue at the moment. It's really annoying when trying functions while developing.
Any ideas?
Config file
<sessionState timeout="120" />
Pool config
As far as I know, in IIS version 7.0 and above, the worker process terminates after a period of inactivity by default(20min).
Because of this, if Secret Server is in its own application pool, the application pool will stop after a period of no requests.
I suggest you could follow below steps to modify application pool settings to keep the web application always running to avoid session missed.
Open IIS (Start > inetmgr)
Right-click the application pool, and then click Advanced Settings.
Under the Process Model section, set the Idle Time-out (minutes)
option to 0
Not sure if this is your problem, but one possibility that caused me far too much head-to-wall banging is: your deployed IIS has the AppPool Maximum Worker Processes set to something greater than 1 (note that #BrandoZhang's screenshot above has it set to 1). Static variables, classes, and even ApplicationState aren't shared across processes.
I setup ASP.NET Auto-Start on my Windows Azure Web Role (I use ASP.NET 4.5 and IIS 8 on Windows Server 2012). I basically followed those instructions.
I am setting startMode="AlwaysRunning" on the application pool and preloadEnabled="true" on the website through the OnStart method of the webrole.
I used remote access and verified that those two properties are correctly set (through IIS Manager, as well as checking the applicationHost.config file).
I also added this to the web.config file:
<applicationInitialization skipManagedModules="true">
<add initializationPage="/" />
</applicationInitialization>
This page says the Idle Timeout should be disabled when auto-start is enabled. Yet, I can see from my log that it is not, the application pool gets restarted after some inactivity. I can also see that in the event log (several times over 6 hours):
A worker process with process id of '772' serving application pool 'cf9d3284-6454-4bbf-8a8e-efd73df4ed83' was shutdown due to inactivity. Application Pool timeout configuration was set to 20 minutes. A new worker process will be started when needed.
The strange thing is that it seems a new application pool is started immediately after this is logged, even if there is no request to the website. So if I don't get a single request in one hour, the application pool is recycled and restarted 3 times (I confirmed this from the logs). Is my configuration incorrect or am I missing something?
Setting the Start Mode to Always Running alone didn't work for me either but setting the Idle Timeout to 0 in the application pool's Advances settings did.
(http://developers.de/blogs/damir_dobric/archive/2009/10/11/iis-7-5-and-always-running-web-applications.aspx)
i have struggled a lot in this issue. I did everything i could to keep my services alive in IIS but eventually got tired and had to take different approach. I created a windows service just to keep those app pool alive. One approach you can try is go to IIS config file and verify that you can see the configuration you made is reflected in that config file.
Refer to the link on top. But your configuration will be reset on app pool restart whatever time you set it to go to sleep. You might need to comeup with some approach.
I spawn a worker thread in an ASP.NET application running on Windows Server 2008, IIS 7.5 The first thing this worker thread does is sleep for N seconds, and then it does its real work. During the sleep, a catch a ThreadAbortException.
Can you explain this behavior, and bonus points of you point me to any IIS/ASP.NET settings that can be used to adjust the behavior.
EDIT: More info. The suggestion to catch the ThreadAbortException helped me work around the problem, so thanks. I totally rewrote the wording of this question based on what I learned, but still, the same question, WHY is this worker thread getting aborted during a sleep?
A ThreadAbortException happens on your worker thread because someone else called Thread.Abort on it, so it's probably nothing directly that your worker thread did, but rather some external cause. The first place you should check is your own code for any thread management or aborting that you might do. Otherwise, for IIS, this could be due to a worker process (w3wp.exe) or app pool, or AppDomain being recycled.
The recycling might be due to the idle timeout setting for the app pool, a regularly scheduled recycle, or a memory/CPU use trigger. These are configurable through the IIS Configuration Manager in the Server Explorer (on Win 2K8) or by just running inetmgr.exe. According to Tess' blog here, there are a number of other reasons for AppDomain recycling:
Machine.Config, Web.Config or Global.asax are modified
The bin directory or its contents is modified
The number of re-compilations (aspx, ascx or asax) exceeds the limit
specified by the
setting in machine.config or
web.config (by default this is set to
The physical path of the virtual directory is modified
The CAS policy is modified
The web service is restarted
(2.0 only) Application Sub-Directories are deleted
That blog post also has information on tracking down why a recycle happened. For starters, try looking in the Event Log (eventvwr.msc) to see if there's any detailed info.
You could also try debugging the worker process directly. Attach the VS debugger to the w3wp.exe instance where your code runs, add a breakpoint on Thread.Abort (you might need to enable ".NET Framework source stepping" in the debugger options), and see where the Abort is originating from by using the call stack window. This won't tell you why it's happening, but at least you'll know who's doing it.