I want to know all possibilities that IIS7 application pool automatically restart.
Because I'm facing such situation and i have no idea about what should i looking for.
There are a lot of reasons that an IIS app pool may restart. The best resource I've found was a blog post ASP.NET Case Study: Lost session variables and appdomain recycles, by Tess Ferrandez that goes into detail on how to identify the issue and fix it. She lists the following reasons that an app domain will recycle:
An application domain will unload when any one of the following occurs:
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 15)
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 (see Todd’s blog http://blogs.msdn.com/toddca/archive/2006/07/17/668412.aspx for more
info)
Related
I am developing with VS2012 also it was same with VS2010. I working on a Web Application project. I have added a virtual application on IIS and set my project root folder as localhost/MyWebApp.
It often happens, when I do a simple page edit (on .aspx files) my site loses sessions. I am sure that no server side code is changed or no runat=server tag was affected.
How can I get rid of this?
Elaborating on David's comment:
File Change Notification
ASP.NET 2.0 depends on File Change Notifications (FCN) to see if the
application has been updated, and depending on the magnitude of change
the application pool will recycle. If you or your application are
adding and removing directories to the application folder, then you
will be restarting your application pool every time.
Altering the following files also causes an immediate restart of the
application pool:
web.config
machine.config
global.asax
Any file in the /bin directory or subfolders
Updating .aspx files, etc. causing a recompile eventually triggers a
restart of the application pool also. There is a property of the
compilation element under system.web called
numRecompilesBeforeAppRestart. The default value is 20, meaning that
after 20 recompiles the application pool will recycle.
Taken from: Losing ASP.NET Sessions - Why Application Pools recycle
Answer from Hans V:
When using the default SessionState Mode "InProc", you session will
be lost when the application pool recycles. Therer are many reasons
why this could happen, but also when you change aspx files:
ASP.NET depends on File Change Notifications (FCN) to see if the
application has been updated. Depending on the change the application
pool will recycle. If you or your application is adding and removing
directories to the application folder, you will be restarting your
application pool every time, so be careful with those temporary
files. Altering the following files will also trigger an immediate
restart of the application pool:
web.config
machine.config
global.asax
Anything in the bin directory or it's sub-directories
Updating the .aspx files, etc. causing a recompile will eventually
trigger a restart of the application pool as well. There is a
property of the compilation element under system.web that is called
numRecompilesBeforeAppRestart. The default value is 20. This means
that after 20 recompiles the application pool will recycle.
Answer reference
I am getting the error:
Module IIS Web Core
Notification Unknown
Handler Not yet determined
Error Code 0x80070005
Config Error Cannot read configuration file due to insufficient permissions
Config File \\?\C:\inetpub\wwwroot\web.config
The file itself has full permissions for IUSR. IIS is running its app pool under ApplicationPoolIdentity. I did a file monitor on the file, and I see this:
9:04:43.8035456 AM w3wp.exe 8104 CreateFile C:\inetpub\wwwroot\Web.config ACCESS DENIED Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, AllocationSize: n/a
No idea why I am getting this error... Any ideas?
Try giving read/write access to these accounts to the root folder of your Web application and all files/subs within:
NETWORK, NETWORK SERVICE, and of course IIS_IUSRS
I found that adding the mymachine/USERS with full permissions to C:\inetpub\wwwroot fixed the issue.
The problem was caused because I shared some sites content inside C:\inetpub\wwwroot with other developers. This must have changed permissions and broke my IIS completely.
First, make sure IUSR has Read permission on the config file (which I believe you have done that)
Then, change IIS authentication method to BasicAuthentication
If still not working, probably the .config extension is not properly installed in IIS.
Try all 3! Good luck!
EDIT: Forget to ask you, what kind of appliation is it?
I just came across this and was unable to find applicationpoolidentity as an account in order to add it to the folder security. I changed the application pool identity from applicationpoolidentity to Local Service and the site ran fine.
I was copying a live WordPress site to my local machine for editing/updating when this IIS error occurred. Changing permissions did nothing.
In my case, simply deleting the web.config did the trick.
I ran into this issue again today. This time, no amount of granting permissions worked (tried all the usual accounts, everybody, read-only, modify, full control).
Closed processes, restarted IIS, full reboot. No results.
Eventually changed the owner from "Administrators" to myself, and things fell into place.
I usually run Visual Studio at Admin level (using my own account) because I like to use the local IIS for hosting / debugging ASP.NET sites. Perhaps that caused new files to be owned by \Administrators, which in turn may have limited access to those files by the IIS or App Pool processes.
My DefaultAppPool identity is set to load the user profile. I don't know at what point the session manager applies UAC / permissions drops and whether user profile loading has any influence on this. Food for thought...
is there a way in ASP.NET to find out, wheter a *.aspx page was changed.
I need it to refresh a cached static variable in a base-page constructor.
Thank and best regards.
Presumably you know that the ASP.NET page has changed (because you've uploaded it). Why not, at that point, recycle the app pool OR do something that will cause the app pool to recycle (such as modifying web.config)?
This question...
What causes an application pool in IIS to recycle?
... talks about what causes an app pool recycle. This MSDN article...
http://blogs.msdn.com/b/tess/archive/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles.aspx
... has an excellent write up about the subject.
When you upload the new .aspx you should get a recompilation, but you might not get an app pool recycle. The number of recompilations before a recycle is controlled by config. See Tess' article (above) for details but this snippet she gives is...
[Recycling occurs when] 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
15)
Background Info: File Replication is Lame
Currently, we have a massive, high-traffic ASP.NET web application load-balanced across 8 different IIS servers. Due to the nature of the site, minor changes to .aspx files and .ascx controls happen frequently throughout the day, and after being tested and published to live, are replicated out to each of the public webservers through xcopy deployment on a scheduled basis every 10 minutes.
Of course this is incredibly inefficient, as each server must have a redundant copy of the entire site, and we would like to eliminate the 10-minute publishing lag.
Possible Improvement: Hosting from Shared Storage
We now have the option to use centralized storage with an iSCSI interface to host the entire site centrally, with each server believing that the remote storage is a local drive. Publishes would be instantaneous and system-wide.
Note: Hosting the drive off a UNC share is not possible, as there are so many different directories in the site structure, each requiring a FileSystemWatcher for ASP.NET to monitor for changes, that the SMB maximum command count is quickly reached. Yes, we know about the MaxCmds and MaxMpxCt registry settings.
The Problem: Web.config changes trigger massive recompiles
The problem we forsee is that certain changes to the file system structure can cause nearly every compiled .aspx or .ascx to have to recompile, causing queued requests and a perception that the server is down. Most resources are not used system-wide and so recompiling them on a change causes hardly a blip in resources. A global master page used by all pages on the site can cause this, but this can easily be managed by code.
The primary culprit is the web.config file. Changes to the web.config file cause the entire web application to recycle, and recompilations to occur. So, we currently don't replicate web.config changes. Any web.config changes requires bringing the web server off the load balancer, applying (and testing) the changes, and then warming the server up with junk requests before it is placed back on the load balancer.
However, if the web.config file, like the rest of the web application's directory structure, is located on centralized storage, there is only one copy of the file, and individual servers could not be patched and warmed up anymore.
The Question
Is there a way to get an ASP.NET web application to take its marching orders from a source other than a file named Web.config?
Ideally there would be one file per server, for example:
default.aspx
global.asax
Web-ServerA.config
Web-ServerB.config
...
Web-ServerN.config
Where is the name "web.config" defined anyway? Is there a registry setting that could be set on a per-server basis? Is there an entry that could be made in the machine.config or the global web.config to specify what file to use?
Things Out Of Scope
Just so I am clear, I am not asking how to have different AppSettings for debug, test, and live. There are other topics that cover this, and all my web.configs will be identical most of the time, the only time I need them to be different is when an update is being performed.
We aren't using the web.config for any appSettings information; this is for the really important stuff, like assembly references, httpHandler definitions, and other system.web settings that can not be databased.
Update
I tried searching the registry for Web.config, and found nothing except for applications that noted that I had recently edited web.config files, which I apparently do a lot. No help there.
My first question would be what are you keeping in the web.config & can you move it to a database? We keep every config setting in a table in our database and use the machine.config to store the db connection information.
Not sure how much of a rewrite that would be for you, but it would avoid your issue.
Another option would be to house your configuration items in an external file and reference it from the web.config. Changes to that file would not be re-read until the aspnet wp was recycled but would allow you to change setting and then cycle each server via an IISRESET.
<configuration>
<appSettings file="OtherFile.config">
...
Just curious, what filesystem are you using? NTFS is not a shared storage file system. In other words you can't have more than one node writing to the filesystem at a time.
I would suggest virtual directories under the site in IIS. This will probably require a little bit of restructuring the layout of your code, but shouldn't be too major. So, you would have the root home dir of the site with the web.config that is specific to that machine and then a vdir mapped to whatever shared filesystem resource you setup.
If I add "trace=true" into my directive on an asp.net 2.0 .aspx page, will it recycle my application pool?
I know if I enable tracing in web.config that will recycle the application pool.
The webserver is IIS 6.0.
Thanks.
I'm not 100% sure but it shouldn't. Any change to a web.config file would cause an app pool reset, but a page level change shouldn't even in the directive.
Check out the section "Why does an application domain recycle?" in this link
Technically if it's the 15th re-compile it could cause a reset... but other than that no.
I believe it will just trigger a recompile of that page. Editing of an aspx file is not a trigger for an application restart.
Why not test it out and see?
Ok - I just tried it out on a testing server - adding in the "trace=true" directive on the page level did NOT recycle the application pool.
It won't. the app pool only recycles when a dll is changed in the Bin directory or if the web.config file is changed. If you are concerned about loosing your session info as that is what the question seems to me to be more related to then you can use the asp.net session state provider and that way your app pool can recycle as many times as it likes without you loosing your session.