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
Related
I am having problems accesing the session after upgrading a web project to .net 4.5
firstly, I had a functional .net 3.5 web forms project which I upgraded to .net 4.5 on my dev machine. This compiled and worked well locally
Secondly I modified the application pools on my dev iis server to use .net 4.0 in preparation for running the new code deployment
Finally I deployed my upgraded project to the dev web server.
The problem is that I am getting an error straight away where I am being told I need to enable session state to access the session variables.
Background:
I have a master page which checks for the existance of a session variable. I have put this code in the page_init event of the master page to ensure it runs before the page_load of the content pages etc.
This technique worked fine under .net 3.5 and works well under 4.5 on the local dev machine. But does not work on the iis server.
I have followed various threads telling me to set enablesessionstate=true in the config all to no avail.
Could it be that there is either a problem with .net sites runnning .net 4.5 on iis with regards to sessions, or am I missing something more obvious.
Please help as this is very frustrating
Well, I have no idea what was causing this?
I have fixed the problem by creating a brand new .net 4.5 project and importing assets / pages from my preexisting site.
Remarkably doing it this way caused no issue with the session after deployment to the web server, Very odd indeed. I can only assume that the project upgrade process that I initially used left some odd configuration in place which upset the server ???
Anyhow, have invested enough time in this now, thanks for taking the time to comment.
I have a similar question to this one;
IIS 7.5
Server 2008
ASP.Net 4.0 web site
The error I get when trying to run the site is this:
HTTP Error 404.17 - Not Found
The requested content appears to be script and will not be served by the static file handler.
...
Most likely causes:
The request matched a wildcard mime map. The request is mapped to the static file handler. If there were different pre-conditions, the request will map to a different hander.
Now here comes the weird part:
THE WEIRD PART
The weird part is that on the develop server -- which is similar in every aspect to the production server -- everything runs smoothly.
Here's a list of things I cannot try, because I don't want to mess with the sever (it hosts many other sites):
Reinstalling .Net
Reinstalling IIS
Reinstalling anything
Running aspnet_regiis
Here's what I did try:
Republishing the site
Restarting the application pool
Changing the application pool to .Net 2.0 and back to .Net 4.0
Switching around between Integrated and Classic pipeline mode
Enabling 32-bit mode
Taking a look at Handler Mappings
Eventually I created a new application pool, and it sort of started working.
Q) "Sort of"?
A) Yes, sort of.
Now the site only works when the (new) app pool is set to .Net 4.0, Integrated,
and the site's Authentication has ASP.NET Impersonation set to Disabled.
Any change to these settings sets the server yelping "404.17" all over again.
Q) What's wrong with that?
A) What's wrong with that is that I NEED ASP.NET Impersonation for the site to function properly.
As always, your guidance is most needed.
HTTP Error 404.17 - Not Found
The requested content appears to be script and will not be served by the static file handler.
Usually this error occurs when you have the right IIS version installed to the respective .net framework. If it was a version (not installed) issue then you would have got a different error message. Anyways, I think by now you have resolved your matter, but I like to share some words with anyone else having this problem. These error messages gave me so much headache all last week and I had tried everything.
Best remedy is always to re install the latest .net in latest visual studio. And the important thing to do is uninstall the existing IIS(express or whichever you have) and re install it first. Then download the latest visual studio. This way visual studio installation can easily access you IIS and add the necessary application pool.
As for the error 404.17, it could simply be because the right application pool has not been assigned for the appropriate dot net version. If the right version is not there re installing visual studio is the only way I know. Also, I think you can try downloading another version of the Visual Studio too. For eg, download the ultimate if you have professional or vice versa. Hope this helps someone with similar problem.
Installing this windows server feature http activation is, what was missing for me.
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/
I've been trying to migrate a fairly large web application from IIS6 to IIS7 the past few days, but every time it seems like we're about done, IIS7 fails to load aspx pages.
The application is a .net 3.5 webapp that makes heavy use of reflection and web services. We use 2 main components (each with their own web site in IIS7 although they share an application pool): the web UI (aspx pages), and the webAPI (asmx pages).
The webAPI portion runs perfectly (as far as we can tell; there are a few things we can't test from the browser), and the web UI pages load static HTM pages just fine. The problem is that once we attempt to view an aspx page (any aspx page), the whole thing just comes to a halt; no error is logged in the event viewer until a few minutes later when we get an IIS 5010 warning (worker process ignoring ping).
We've attempted to migrate the app in two different ways:
Manually: we moved all the necessary files and set up the virtual directories then converted them to Web Sites. Result: the worker process took up 100% of a single core and spun forever (until terminated manually)
Automatically: Utilizing the MSDeploy application from www.iis.net we archived the entire IIS6 web server and unpacked it into a blank IIS7 install. We had to turn off Forms Auth to get rid of a 401.2 error, but after that the result here was that the webAPI component still works just fine, but instead of the web UI worker process taking up 100% of a single core, it grew to about a third of the required memory then hung out doing nothing.
Either way, what happened from the user's point of view was the same.
Unfortunately, we can't even attach a debugger to the worker process because it doesn't seem to be loading managed code.
Details:
.net framework: v3.5
CLR version: v2.0
IIS Authorization mode: Anonymous
OS arch: x64
App arch: x86
Happens with both classic and integrated pipelines
Notes:
New web projects seem to work just fine in IIS7 and, of course, xml web services are also fine
temporary DLLs are created and stored in the temporary ASP.net DLLs folder, even though the worker process never seems to contain managed code.
New pages added to the web UI project also show the same behavior (Didn't hurt to try)
Updates:
We've narrowed down the problem to a single assembly. It's a wrapper for a third party web control. I'm looking into replacing it, we'll see if it fixes the problem.
http://support.softartisans.com/kbview.aspx?ID=1318
Turns out it was an issue with the vendor control. Wish their solution actually worked though...
Try to re-register ASP.NET:
http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
The typical command line syntax would be to command line to the ASP.NET 2.0 version of your framework and type:
aspnet_regiis -i
Are you using the "Classic" Pipeline Mode for your Application Pool. The "Integrated" one is the default in IIS7 and it introduced changes in terms of configuration. (One example is HttpHandlers that need a different configuration in web.config).
The "Classic" one mimics the IIS6 application pool, and should work with the same configuration as for IIS6.
If you prefer to use the Integrated Pipeline, there are some tools that will automatically try to convert you configuration files.
Scott Hanselman covers some of these tools in his blog post.
We're seeing an odd pattern in our QA Lab. We have two ASP.NET applications, each deployed on the same Windows 2008 SP2+ box. We have our App Pool running in a Domain Account, and set to never re-cycle. The same 1 App Pool is used by both applications.
After several hours of running fine, new users surfing to a page in our application get the IIS7 Error Page, with a 500.21 error.
If we do nothing but:
1) IISRESET
2) Change folder to c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files and "rd" the 2 applications.
And then surf to our web applications, all is fine.
Then several hours later, however, the 500.21 errors return.
What strikes me as odd is the seeming relationship between clearing the "Temporary ASP.NET Files" folders and the problem going away. I've a practice of clearing the "Temporary ASP.NET Files" folders when installing a new version of our application(s), but not otherwise.
Does this relationship ring familiar to anyone? Is there some new-ish IIS7 feature at work here?
Text of Error:
Server Error in Application "DEFAULT WEB SITE/PAIS"
Internet Information Services 7.0
Error Summary
HTTP Error 500.21 - Internal Server Error
Handler "PageHandlerFactory-Integrated" has a bad module "ManagedPipelineHandler" in its module list
Detailed Error Information
Module IIS Web Core
Notification ExecuteRequestHandler
Handler PageHandlerFactory-Integrated
Error Code 0x8007000d
Requested URL http://localhost:80/PAIS/Admin.aspx
Physical Path C:\0_Georgia\GA_IS_100142\PortfolioArchiveImageServer\Admin.aspx
Logon Method Anonymous
Logon User Anonymous
Most likely causes:
• ASP.NET is not installed or incompletely installed.
• A configuration typographical error occured.
• Unfavourable pre-condition evaluation exists.
Things you can try:
• If ManagedPipelineHandler is missing, ensure that:
o ManagedEngine is in .
o ManagedPipelineHandler is in , with correct pre-conditions.
• Install ASP.NET.
• Ensure all system.webServer/handlers#modules are in system.webServer/modules#name.
• Review pre-conditions in the and sections.
Links and More Information IIS core does not recognize the module.
View more information »
Thanks in advance,
Howard Hoffman
Faced the same problem and the fix was easy.
1) Open visual studio 2010 command prompt.
2) Run the command aspnet_regiis.exe -i
We found the actual problem, with MS ASP.NET support's help. It's pretty subtle. I think MS has said they will fix the issue in a follow on to the App Fabric release (which is now RTM). Fingers crossed.
The problem consistently occurs in this scenario:
1) ASP.NET web application not yet running. It includes WCF Net.Pipe and / or Net.Tcp bindings. I think the same would occur for NetMsmq but did not try it.
2) An inbound NetPipe or NetTcp WCF Windows Activation Service request is the initial request that starts the App Domain.
3) Application uses an 'Integrated' IIS App Pool (IIS7 or IIS 7.5)
4) The application uses HttpServerUtility.Execute during that 1st request.
It turns out that our application was firing an ASP.NET Health Monitoring event during the very 1st WCF operation -- the very operation that caused Windows Activation Service (WAS) to start our application. Our Health Monitoring configuration includes the TemplatedMailWebEventProvider.
Our application is using an 'Integrated' IIS App Pool.
The TemplatedMailWebEventProvider is implemented to create an email message body as HTML. It uses the System.Web.HttpServerUtility.Execute(string, TextWriter, Boolean) overload.
For this use case that overload does the wrong thing -- it initializes a 'Classic' IIS App Pool based HTTP pipeline. Because that's the wrong pipeline for an 'Integrated' IIS App Pool the pipeline gets corrupted with the next HTTP request -- which is actually the first inbound HTTP request.
So you get the 500.21 error for all future HTTP requests until the application is re-cycled. You don't need to perform the relatively drastic steps of IISRESET, clearing Temporary ASP.NET cache to clear up the error -- just restart the app via saving web.config and avoid the particular startup path that causes the error.
MS suggested a workaround for us -- use the SimpleMailWebEventProvider instead of the TemplatedMailWebEventProvider. That does work, since it takes HttpServerUtility.Execute out of the code path for the first request.
I'd suggested that MS introduce a new web.config <system.web> boolean setting -- UseIntegrated -- that let's the application specify the typeof App Pool to initialize with. Evidently IIS does not forward the App Pool type to ASP.NET, so my sugggestion is a work-around to that.
The TemplatedMailWebEvent provider is much more user friendly than the SimpleMailWebEventProvider, and we do hope MS addresses the issue.
Thanks all for reading,
Howard Hoffman
1. IIS 7 throws an exception as shown in below
2. Open visual studio 2010 command prompt in Administrator mode and execute aspnet_regiis.exe -i
3. Problem fixed, as shown below ASP.Net Application and ASP.Net MCV Application are running smoothly.
The problem more likely is in the application code. The Temporary ASP.NET Files folder contains pre-compiled copies of your app and will be refreshed every time the applications files are accessed. You can pre-compile these files with aspnet_compiler.exe in the \Windows\Microsoft.NET\Framework\v2.0.50727\ folder. Use the -errorstack option allow for more information to be generated about the error you are getting. Long running applications that don't recycle will run into problems if they use a lot of memory or retain large amounts of data in an inproc session state. if your sessions contain large amounts of information, consider using a sqlserver-based session manager.