IIS Application Pools fail in 32 Bit Mode in Windows 10 - iis

On my development machine, whenever I set an IIS Application pool to run in 32 bit mode, any Web application started will simply hang. When accessed in the browser the app will 'hang' for about 5-10 seconds, before receiving a 503 error. The Application Pool for the app will be stopped at that point and has to be explicitly restarted.
In 64 bit (default) mode everything is fine, but whenever the pool is switched to 32 bit it immediately hangs even on static pages in a new and otherwise empty Web site.
The same applications runs fine when published to my live server in 32 bit mode, so it appears this is some sort of configuration problem. I've enabled Failed Request Tracing but nothing shows up in the logs.
I have several applications that have to run 32 bit due to some old COM dependencies, but I cannot get the server to run.
Any ideas what might be causing this problem?

Ok I found the problem, which was the AspNetCore Module which had the 64 bit version registered without a bitness value in the IIS Module list.
This problem isn't specific to the AspNetCoreModule, except that the module was installed without specifying a bitness64 (for the 64 bit version). Without the bitness value the module loads even in 32 bit mode and causes the server to crash.
An additional point of failure is the IIS Rewrite Module, which gets hosed for similar reasons when Windows is updated. Every Windows update the Rewrite Module breaks IIS for me (32 and 64 bit). This was the initial failure and event log entry. After Reinstalling the Rewrite module the AspNetCoreModule errors started showing up in the event log. I have more info that issue on my blog: https://weblog.west-wind.com/posts/2015/jul/05/windows-10-upgrade-and-iis-503-errors
To fix the bitness of the AspNetCore module I changed the bitness in Applicationhost.config:
<add name="AspNetCoreModule" image="%SystemRoot%\system32\inetsrv\aspnetcore.dll" preCondition="bitness64" />
Notice the precondition=bitness64 which is all that was needed to make the 32 bit AppPools work again as this prevents the module from loading into 32 bit processes. It's possible a reinstall of the AspNet Server runtime might also fix this, but I didn't verify this.
When 503 errors occur on app start up they are usually Application Pool related and won't show up in FREB logs. The EventLog does have more info and in this case pointed first at the Rewrite Module, then at the AspNet Core Module.

Related

IIS App Pool stops when 32-bit is enabled

I have a brand new laptop with Windows 10 Professional. I have installed VS2019. I have also installed IIS. I have the default IIS setup, so just Default Web Site which when browsed goes to the default IIS page. I enable 32-bit mode on my DefaultAppPool. I then try to browse to the website again and I get a 503 error. The app pool has stopped.
I have seen numerous posts on the internet about attaching debuggers, writing log files, looking at the event viewer logs as well - but none of them are helping me. I have noticed that I can enable 32-bit and not assign any web application to it... then the app pool stays running. The second I assign a web application to the app pool it crashes (I set the Start Mode in the app pool advanced settings to Always Running in this instance)
I have created a new App Pool and tried the config again. If I look at event viewer logs, I get this:
I have also tried uninstalling IIS, deleting the inetsrv folder in system32, deleting inetpub and then reinstalling IIS.
I have also tried looking at the applicationHost.config file to try to pick up anything weird in there and everything looks good.
Any assistance would be greatly appreciated!
EDIT:
These are the Friendly views:
Error:
Warning:
I have downloaded the Microsoft Error Lookup tool (https://www.microsoft.com/en-us/download/details.aspx?id=100432)
According to this article I should take the value after the colon (:) and use it as a parameter on the Microsoft Error Tool (http://intelligentsystemsmonitoring.com/knowledgebase/internet-information-services/event-id-iis-worker-process-availability-21961/). I have done this for both values (70050780 and 80070570). Here are the outputs:
Is this anything to go on? If so what can I do to fix these errors? I don't know what file it's trying to access or which directory is corrupt. I have given Everyone and App Pool users access to inetpub to test it out but it doesn't work.

IIS - Service Unavailable

Recently we are facing "Service Unavailable" while opening our web reports url in internet explorer.
Restarting the IIS service resolves the issue but didn't found any logs/errors in event viewer to track what is causing IIS to fail.
Is there any other way to troubleshoot this?
Many thanks...
To actually help you out SO need more information but following is more common cause.
There is no enough memory for application to run when it try to start. If there are multiple application in your IIS then it cause such issue as other application took priority so memory consume by them.
Your application has some un-handle exception that cause your application to shutdown and sometime it cause worker process to stop.
If your application is .NET based ( This is not the case with you because after IIS restart it runs successfully ) then .NET Runtime Version conflict also create such problem.

IIS in Classic Mode ignores Sitecore, does not loads the startItem

I am using Sitecore 8.1, and our IIS crashes quite often in production - on average, 2 times a day.
Following this guide to improve Sitecore stability on 64-bit machines I have set the Enable 32-bit Applications option to True and changed the application pool's Managed Pipeline Mode to Classic.
Sitecore now displays the empty "Default Page" page, and even after deleting its file it attempts to simply list the directory content rather than loading my Sitecore application as it always did in Integrated mode.
Does anyone knows how can I configure IIS in order to have Sitecore to work properly in Classic Mode?
This is not a solution to switch your Application Pool to Classic mode to stable your solution.
In Sitecore 8.1 : Classic mode for IIS has been deprecated, and the httpModules and httpHandlers elements have been removed from the Web.config file.
Informations about classic mode deprecated you can find here
It's very difficult to find exactly your problem, I suggest you to open a support ticket.
What you will want to do it catch the actual crash of the IIS app pool with DebugDiag. You install it and then configure it to watch your app pool until it crashes. Once it does, DebugDuag will dump the memory of the app pool to your hard drive. You can finally analyze that for the exact function and cause of the dump. You most likely have a process that is spinning off into a stack overflow in unmanaged code.
https://blogs.msdn.microsoft.com/chaun/2013/11/12/steps-to-catch-a-simple-crash-dump-of-a-crashing-process/

ASP Error 0223 - TypeLib Not Found, intermittent, resolved after IIS restart

I'm currently in the process of migrating an ASP platform from Windows 2003 R2 IIS 6 web servers to Windows 2012 R2 IIS 8.5 web servers. I'm at the stage where I've migrated a number of sites across to two separate 2012 web servers, all looked great, clients and developers are happy... However the following error has presented itself after a few days hosting on one of the new servers.
Active Server Pages error 'ASP 0223'
TypeLib Not Found
/jobboard/conf/constants.vbs.inc, line 1
METADATA tag contains a Type Library specification that does not match any Registry entry.
The METADATA tag is below:
<!--METADATA TYPE="typelib" NAME="Microsoft ActiveX Data Objects 2.8 Library" UUID="{2A75196C-D9EB-4129-B803-931327F72D5C}" VERSION="2.8"-->
Restarting IIS on this server resolved the issue (albeit temporarily).
Subsequently the other 2012 web server in production presented the same error a couple of days later, again, restarted IIS and works for now.
I've checked the registry and the relevant tag exists with the right UUID and correct permissions.
It doesn't affect all sites on the server, only all sites in a particular application pool.
The application pools use a domain user identity and sites are split up into a number of shared pools.
I've now determined what was causing the above problem...
Our sites on IIS run in a number of shared application pools running as a domain user. We also have a Windows scheduler job which runs a number of scripts over night which also run as the same domain user.
It seems there are cases when this scheduler job runs it interferes with the IIS worker processes. When it completes and ends its user session it unloads the registry file in memory, which the w3wp.exe processes could also using.
This error is presented in the Event log...
Windows detected your registry file is still in use by other
applications or services. The file will be unloaded now. The
applications or services that hold your registry file may not function
properly afterwards. No user action is required.
Along with references to the w3wp.exe processes currently running.
It was replicated when I terminal serviced in as the domain user and logged out again after a period of time. The event log presented the error and the sites all bombed shortly afterwards.
Running the scheduled job as a different user has fixed this issue for us.
I remember having an include file for ADOVBS.inc with all the ADO constants inside and including it as a standard ASP include inside my global include file which is included on every page on the site.
This was before I used the META way of including the file.
So maybe a last resort is to revert to that method of loading in the ADO constants.
It seems like some sort of threshold is being hit, CPU/Memory?, which then prevents IIS caching/loading the file in from the registry. This then causes the error and a recycle of the pool. As no redirect is being done to the 500.100.asp error handler page which hides the error details from the user. It would suggest the error is in IIS and related to the server.
Thanks

Getting Peformace Counter related error on Window Azure

I am facing some critical issue which might be interesting for whom , those who are playing with window azure sdk. I have created on EXE which read performance counter data like CPU, memory, asp.net session from system like
queryCollection = ExecuteWMIQuery("SELECT * FROM win32_perfformatteddata_perfdisk_physicaldisk");
and I have aded this EXE in startup task of simple asp.net application which i have uploaded on window Azure. Now when i connecting to RDP of that I can see following errors in my event log as per below.
Disabled performance counter data collection from the
"ASP.NET_64_2.0.50727" service because the performance counter library
for that service has generated one or more errors. The errors that
forced this action have been written to the application event log.
Correct the errors before enabling the performance counters for this
service.
======================================================================
Windows cannot open the 64-bit extensible counter DLL
ASP.NET_64_2.0.50727 in a 32-bit environment. Contact the file vendor
to obtain a 32-bit version. Alternatively if you are running a 64-bit
native environment, you can open the 64-bit extensible counter DLL by
using the 64-bit version of Performance Monitor. To use this tool,
open the Windows folder, open the System32 folder, and then start
Perfmon.exe.
So i am thinking that my EXE trying to fetch performance counter for 32 bit (win32 indicate that) and that will log above error.
So anyone here came across this type of issue , also if my guess is correct then is there any way to implement my EXE logic such way that it can be run smoothly in any environment(32 or 64 bit)?
Hope that this would remain interesting question here!!!
Thanks In Advance
Arun.
That is correct. IIS running in Azure is running 64-bit unless you change it to run 32-bit in a startup task. You could try building it with the Any CPU setting. But most likely the best way is to do something like what the sysinternal tools does. They will spawn a new process that runs in 64-bit mode when needed. Then you can handle both.
I encountered this error while migrating to a Azure VM.
Solved it by using the InstallUtil which is located in the Framework64 folder instead of the one in the Framework folder

Resources