We have an ASP.NET 2.0 Web Application Pool running on .NET 3.5 and "all of sudden" we started to experience a weird session timeout which is kicking out the users from the system.
From the event viewer we can see a warning message saying that app pool is restarting due to an exception with no much detail on why. As you may guess session is In Proc and due to early mistakes in the application design using state server will require a lot of work and time which we do not have(I guess you never experienced that too) and also I am eager to find what is happening.
At some point we had decided to compile the site using: Aspnet_compiler -v /WebApplication1 this was done in the server itself. When we put both versions to run the compiled and the non-compiled and we noticed the issue occurs way more often in the compile version than the non-compiled version. Like every 5 min. in the compiled version vs 1 or 2 times a day in the non-compile.
What may be affecting the compiled version or forcing the app pool to restart?
Related
I have an ASP.NET MVC 5 application running on Windows Server 2012 on IIS 8.
Every so often my site gets ridiculously sluggish to the point where it takes at least 5 seconds just to load the basic About page. It tends to feel as though it's running in Debug mode, even though my deploy process is automated, so I'm not accidentally deploying in Debug mode, and I can find no signs that it's in Debug mode. I've sometimes wondered if it's a memory issue, but I don't see the server memory getting out of control. I've also wondered if it's something weird with IIS settings such as Application Pool recycling (or something to that effect). I've been dealing with this issue for over a year, not knowing where to look next. I have MiniProfiler running in my development and staging environments, so I'm pretty familiar with the performance of my various site pages etc. Also, I have another web app on the exact same IIS server that doesn't seem to suffer from the same problem. The only difference I can think of between the 2 is that for one site I use Ninject for dependency injection, but I don't for the other site.
I'm really at a loss, but the only "cure" when the site gets bogged down is to completely delete the application files for the site and redeploy. This does the trick every time and then the site will act snappy again (loading the About page in under 1 second). I seem to have to repeat this ritual every week or 2, or at least once a month (whenever I notice the site is at a crawl).
Back in October we upgraded one of our sites (on IIS 6) from .net 3.5 to .net 4.0. Since then we have been getting the following warning and error pretty much everyday:
Warning:
ISAPI
'c:\windows\microsoft.net\framework\v4.0.30319\aspnet_isapi.dll'
reported itself as unhealthy for the
following reason: 'Deadlock detected'.
Error:
It is not possible to run two
different versions of ASP.NET in the
same IIS process. Please use the IIS
Administration Tool to reconfigure
your server to run the application in
a separate process.
We have checked all applications and ensured that they are running on the correct versions of ASP.NET and also in their own separate app pools.
We have looked at the IIS logs at the time the errors are recorded but this doesn't give any clues as to the issue. Is there a tool available that could give us more information as as to which application is causing the errors and what was happening at the time?
The discussion here might be helpfull for you as well:
You can configure the application pool to orphan the worker process rather than kill it when this condition happens - you can then use adplus to collect a hang dump of the worker process which can be analyzed to figure out what in the process is deadlocked.
(...)
It means that the asp.net thrads have not returned from whatever activity they were doing for a very long time and asp.net has run out of threads - this would normally indicate deadlock. This kb also talks about how to generate dumps for analysis for this condition.
I had the exact same error, and it was due to a .NET 2.0 custom error page that my .NET 4.0 app was referring to.
I had set up a custom error page that was developed in .NET 2.0 and it was applied at the top level of the IIS web site.
The .NET 4.0 application was using a unique MVC URL routing scheme, and for some reason just that application kept locking up and eventually those deadlock errors would come up.
I got rid of the custom error page setting which pointed to the .NET 2.0 web page and switched it back to the default "Not Found" static error. I restarted the application pool and the web page started working without issue.
Hope this helps someone else out there.
http://adamantinewolverine.blogspot.kr/2012/10/running-iis6-in-32-bit-mode-on-64bit.html
Backstory
Last month our development team created a new asp.net 3.5 application to place out on our production website. Once we had the work completed, we requested from the group that manages are server to copy the app out to our production site, and configure the virtual directory as a new application.
On 12/27/2010, two public 'Gineau Pigs' were selected to use the app, and it worked great.
On 12/30/2010, We received notification by internal staff, that when that staff member tried to access the application (this was the Business Process Owner) they recieved the 'Server Application Unavailable' message.
When I called the group that does our server support, I was told that it probably failed, because I didn't close the connections in my code. However, the same group went in and then created a separate app pool for this Extension Request application. It has had no issues since.
I did a little googling, since I do not like being blamed for things. I found that the 'Server Application Unavailable' message will also appear when you have multiple applications using different frameworks and you do not put them in different application pools.
Technical Details - Tree of our website structure
Main Website <-- ASP Classic
+-Virtual Directory(ExtensionRequest) <-- ASP 3.5
From our server support group:
'Reviewed server logs and website setup in IIS. Had to reset the application pool as it was not working properly. This corrected the website and it is now back online. We went ahead and created a application pool for the extension web so it is isolated from the main site pool. In the past we have seen other application do this when there is a connection being left open and the pool fills up. Would recommend reviewing site code to make sure no connections are being left open.'
The Real Question:
What really caused the failure? Isn't the connection being left open issue an ASP Classic issue? Wouldn't the ExtensionRequest application have to be used (more than twice) in the first place to have the connections left open? Is it more likely the failure is caused by them not bothering to setup the new Application in it's own App Pool in the first place?
Sorry for the long windedness
You'd really need to obtain and review the server's Application & System event and HTTPERR logs for the period the server was reporting these errors.
Without these it'd be hard speculate what was the root cause of the problem.
Update:
OP incorrectly tagged his question so this next section no longer applies. However I'll leave in place because I think the information is useful for those encountering these issues and perhaps thinking about migrating to IIS7.x.
You are correct that running two different .NET Framework's in the same application pool can cause these errors but that's something you'd tend to see on Windows 2003/IIS6, not Windows 2008/IIS7.
IIS7 uses a slightly different approach to specifying which .NET Framework version is loaded and it's determined by the Application pool's managedRunTimeVersion property. When requests are processed by IIS/ASP.NET the site's Handler Mapping's use a preCondition attribute to determine when to load the requisite handler (which is kind of like a script mapping in previous versions of IIS).
This mechanism prevents the incorrect runtime version being loaded into the application pool's worker process.
So if an application pool is configured to run .NET Framework version v4.0 only that version will load, even if your application is built against v2.0.
There's a great article on how this works here:
Achtung! IIS7 Preconditions
The section on Handlers about half way through explains why the dangers of accidentally loading the wrong .NET version into a pool are mitigated by the preCondition feature.
A Server Application Unavailable error usually means something catastrophic has happened (like loading the wrong ASP.NET version's ISAPI filter into an already running worker process).
Not closing SQL connections is unlikely to cause this type of serious error. You'd more than likely be seeing a yellow screen of death runtime errors if that were the case. Running out of SQL connections usually doesn't bend ASP.NET so out of shape that the whole service tops itself.
My prime suspect would be a permissions problem where the application pool identity was unable to correctly access the application folders. But it's just a hunch.
Again, what you need to do is get the Application & System event logs and the HTTPERR logs (they reside in %systemroot%\System32\LogFiles\HTTPERR. That will contain clues and facts about what went wrong.
Update 2:
On Windows 2003/IIS6, if you have two applications running different ASP.NET versions that reside in the same pool you will get this error. In my experience (I work for a web hoster) it is the primary cause of this infamous error page:
There's also a tell-tale event logged to the Application Event log:
Event Type: Error
Event Source: ASP.NET 2.0.50727.0
Event Category: None
Event ID: 1062
Date: 12/01/2011
Time: 12:31:43
User: N/A
Computer: KK-DEBUG
Description:
It is not possible to run two different versions of ASP.NET in the same
IIS process. Please use the IIS Administration Tool to reconfigure your
server to run the application in a separate process.
Whilst your root application may not be written in ASP.NET it's likely that something has triggered loading of a different version of the framework into your site's application pool.
there's a rogue web.config in the root...this will trigger ASP.NET to load
there's a wildcard mapping to ASP.NET 1.1 in the site script maps (less likely, but possible)
I'm inclined to think that your new application most certainly ended up in a pool where other sites or applications were running a different framework version. The only way to really find out is to obtain the Application event logs and look for the event shown above.
It's hard to tell; there could be many causes (too many resources used, calling outside of .NET caused something to crash, etc). I would look in the Event log and see if you can find something there.
If you're running different versions of .NET you definitely want separate pools. If you have the option, I would recommend separate pools for each application (even if in the same .NET version).
As far as "closing the connection" (I assume you mean the connection to the database). If you're creating "low level" connections (i.e. SqlConnection, SqlCommand) then make sure you're wrapping them in a "using" statement, otherwise your connection pool can fill up. In my experience though, you should receive regular .NET errors in this case. If you're using an ORM this shouldn't be an issue.
Edit:
If you can't find anything useful in the Event Log, you could try this: http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/
We have an ASP.NET application running on a webfarm. When we release a new version and copy it to the production servers, occasionally it happens that after a few hours the application reverts to a an earlier code base.
Have anyone else experienced something like this? Would sharing an application pool between two applications running different versions of the code make this happen?
Additional information:
3 x web servers running w2k3/iis6
ASP.NET 3.5
I've had this happen rarely on non-precompiled sites and the solution was to stop IIS and clear out the temporary cache at:
%WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
Is not a long-term solution, but will address the immediate problem. If not already, it is worth considering deploying the site pre-compiled.
I've a a customer using IIS and an application, developed by us, in ASP.NET 1.1.
Monday, for 4 times in a row the following error has appeared:
A process serving application pool 'xxxx' suffered a fatal communication error with the World Wide Web Publishing Service. The process id was 'yyyy'. The data field contains the error number.
Any idea about how to diagnose this? The only link I've found talks about installing low level debug tools but before proceeding in this kind of low level analysis I would know if someone has a better idea or a suitable alternative.
The problem (from what I can see) is something in the customer environment, because the same application it's installed at other customer sites on at least 20 or 30 different servers and the problem do not happen.
Had the same issue on IIS 7, had few reports all worked except one report that was very long and it never worked on IIS7 (it was fine on low spec server).
on IIS7 in application pool's Advance Setting I set "Enable 32-Bit Application" to true and all worked nicely
I'm getting the same error, here are some more details:
running: Windows Server 2003, IIS 6.0 / ASP 3.0,
2.13 GHz, 1 GB ram
My web site is in Beta, so I hardly have any visitors to the site.
According to the event viewer I'm getting this warning 3 times every 3 minutes,
then it stops for a few hours.
Then sometimes I get the error:
A process serving application pool 'DefaultAppPool' terminated unexpectedly. The process id was '3900'. The process exit code was '0x800703e9'.
which follow by:
Application pool 'DefaultAppPool' is being automatically disabled due to a series of failures in the process(es) serving that application pool.
Which then causes a 'Service Unavailable' message when browsing to the website.
after reading too many post about this issue, I did the following steps:
I read that it might be registry access right, so I installed a monitor and trace all the W3SVC Access Denied errors and grant permition
I read that the 0x800703e9 error means stack over flow which causes a w3wp.exe crash and I should install a Debug tool and try to get a memory dump.
I did that but I didn't get any dump, so I installed a new debugging tool, but didn't got a crash yet.
My web site is doing some data mining which keeps the server busy.
Conclusion:
I don't know what is going on there... but I do know that my server machine is way to slow on resource, so I'm going to upgrade and reinstall it, I'm certain that it will solve the problem...
The problem happens all the time, even when my .net code is idle, therefore it is a problem in the server, and not in my code.
I think that the first warnning “A process serving application pool ..." happens every some time, and every now and then it causes the Application Pool to restart, therefore a attaching a debugger doesn't help - the process keeps restarting and the debugger is not effective any longer...
I think that the 0x800703e9 error (which causes the Service Unavailable) maybe happens when the app pool restart, I guess that it needs a lot of resource and since my machine is too slow it gets the 0x800703e9 ... as said before this is a stack over flow, but I think that it is caused by low resource and not by an endless recursion.
I think that the 'registry access right' which is claimed by Microsoft to be the issue, is nonsense, but I didn't got 'Service Unavailable' since so it might helped (thought I still get the warnning “A process serving application pool ..." ).
Hope this help someone...
I'm sure you already know this, but the App Pool contains 1.1 applications only right? I don't remember the error you get when the pool dies by trying to mix frameworks (something like Server Unavailable), but it's more common then I thought in the wild so I would double check.
While not likely the case, it's somewhere to start.
Edit: This KB article also had the error message you described relating to registry permissions, what version of IIS is the client running?
I had this same problem when a website was deployed to a client's web server. This Microsoft support article says:
"This issue may occur if the NT AUTHORITY\NETWORK SERVICE account does not have the permissions to the required registry keys."
And the resolution is: "set the permissions to the required registry keys, and then restart IIS 6.0."
The linked article has the steps for doing this.
One more popular reason (as in my case) - one of windows logs is full.