There are number of posts on this and I have tried many a things by now. But to no avail. Myself a Winforms Developer basically, started working on this Web stuff few days back as my company is taking Web initiatives.
I have a ASP.Net project and I want to host it on local IIS. In Project properties -> Web settings I chose Use Local IIS Server and gave a url as localhost/MyApp. I tried accessing it on my firefox browser and received error as HTTP Error 503. The service is unavailable.
Previously I got many other errors and I one by one fixed them all. But struck with this one. These are the settings I have in my project
Application Pool set to ASP.Net v4.0 Classic
App Pool Enable 32 bit Application property is true
App Pool is started
Project build property set to Any CPU for Target framework
But I would like to mention a weird behavior. Following is something that I am facing
Application Pool is Started
I try to access my local website (by giving url as localhost/MyApp)
I receive the error as HTTP Error 503. The service is unavailable
Application Pool is Stopped
I have seen following link and I have already tried it. For the above behavior I reached here. According to this link, Computer name should not have . in it. I don't have any . in my Computer name but do have - in it. Also my domain name contains . in it. Moreover I can't change these settings as its my office laptop and our TFS settings are bound to our Domain and Computer Names.
Can anyone help me to understand whats happening? Please guide me. Thanks.
Edit
I have following code in Global.asax. Application_BeginRequest method is empty in same file.
protected override void Application_Start(object sender, EventArgs e)
{
base.Application_Start(sender, e);
String _path = String.Concat(System.AppDomain.CurrentDomain.RelativeSearchPath, ";",
System.Environment.GetEnvironmentVariable("PATH"));
System.Environment.SetEnvironmentVariable("PATH", _path, EnvironmentVariableTarget.Process);
MyAppLog.Initialize();
MyAppLog.WriteMessage("Application Started");
}
Update
As per the suggestions in Comment, I am able to run the website from Cassini.
One possible reason this might happen is that the Application Pool in IIS is configured to run under some custom account and this account either doesn't exist or a wrong password has been provided, or the password has been changed. Look at the advanced properties of the Application Pool in IIS for which account it uses.
Also the Event Log might contain more information as to why the Application Pool is stopping immediately on the first request.
Ok, I have another solution for one specific case: if you use WINDOWS 10, and you updated it recently (with Anniversary Update package) you need to follow the steps below:
Check your Windows Event Viewer - press Win+R and type: eventvwr, then press ENTER.
On the left side of Windows Event Viewer click on Windows Logs -> Application.
Now you need to find some ERRORS for source IIS-W3SVC-WP in middle window.
Probably you will see message like:
The Module DLL >>path-to-DLL<< failed to load. The data is the error.
You have to go to Control Panel -> Program and Features and depending on which dll cannot be load you need to repair another module:
for rewrite.dll - find IIS URL Rewrite Module 2 and click Change->Repair
for aspnetcore.dll - find Microsoft .NET Core 1.0.0 - VS 2015 Tooling ... and click Change->Repair.
Restart your computer.
For my situation is that my login password changed, while the application pool still uses the old one. So just click the "Advanced Settings" of your application pool and reset your "Identity".
I was facing the same problem, and debugged it using the event logs. First it said that : "The description for Event ID 5059 from source Microsoft-Windows-WAS cannot be found".
I then turned on WAS using turn windows features on/off. Then i saw this in eventvwr
"Microsoft-Windows-DistributedCOM cannot be found".
Finally I gave up and deleted the App Pool (that used to stop on accessing the website) and created it again, as it is. This resolved the problem.
Most of Time, it was occured due to AppPool Setting.
Check the following to resolve this
Check Apppool service is running.
Check Identity of AppPool.
Enter the new password if it has changed for that identity.
The following Images show these setting in IIS
For anyone coming here with Windows 10 and after updating them to Anniversary update, please check this link, it helped me:
https://orcharddojo.net/blog/troubleshooting-iis-apppool-crashes-status-503-after-windows-10-anniversary-update
In case link goes down:
If your Event log shows that aspnetcore.dll, rewrite.dll (most often, but could be others as well) failed to load, you have to repair the missing items.
Here are two specific issues we've experienced so far and how to fix them, but you may bump into completely different ones:
"C:\WINDOWS\system32\inetsrv\rewrite.dll" (reference)
Go to "Programs and Features" (Win+X, F) and repair "IIS URL Rewrite Module 2".
"C:\WINDOWS\system32\inetsrv\aspnetcore.dll" (reference)
Go to "Programs and Features" (Win+X, F) and repair "Microsoft .NET Core 1.0.0 - VS 2015 Tooling ...".
If you have McAfee HIPS and if you see the following error in event viewer application log:
The Module DLL C:\Windows\System32\inetsrv\HipIISEngineStub.dll failed to load.
The data is the error.
Then the following resolved the issue in my case:
https://kc.mcafee.com/corporate/index?page=content&id=KB72677&actp=LIST
Quote from the page:
Click Start, Run, type explorer and click OK.
Navigate to: %windir%\system32\inetsrv\config
Open the file applicationHost.config as Administrator for editing in Notepad.
Edit the <globalModules> section and remove the following line:
<add name="MfeEngine" image="%windir%\System32\inetsrv\HipIISEngineStub.dll" />
Edit the <modules> section and remove the following line:
<add name="MfeEngine" />
After you have finished editing the applicationHost.config file, save the file, then restart the IIS server using iisreset or by restarting the system.
In my case I checked event logs and found error was
Cannot read configuration file ' trying to read configuration data from file '\\?\', line number '0'. The data field contains the error code.
The error code was 2307.
I deleted all files in C:\inetpub\temp\appPools and restarted the iis. It fixed the issue.
I had a similar issue. I solved it by adding my user to the "Log on as a batch job" policy under "Local Security Policy" > "Local Policies" > "User Rights Assignment".
When I first time add the service and created the app pool for it.
I did "iisreset" from command prompt, and it worked.
I was experiencing this error and in my case the cause was that some time ago I modified the user password, and the 503 error didn't appears till I restarted the application pool.
So I fixed it setting the new password on Applications Pools / Advanced Settings / Identity / [...] / Set... / Password / Confirm Password
If you can run the website in Visual Studio debugger, then might be able to see where in your code the application pool is crashing. In my case, it was a function being called recursively an unlimited number of times, and that caused a stack overflow. Note: the Windows event log and the IIS logs were not helpful to diagnose the problem.
I had the same issue with iis 8.5. After searching the eventViewer under windows Logs-->applications, I realized that I'm having a permission error for the machine.config file of the .net framework located at "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config".
Giving it a permission for IIS_IUSRS solved my problem (right click the file-->properties-->security-->edit-->add-->IIS_IUSRS)
Just to add to these Anniversary Update issues (thanks Microsoft) if the file you are missing is cgi.dll, ie your Event Viewer has
The Module DLL C:\WINDOWS\System32\inetsrv\cgi.dll failed to load. The data is the error.
Then to fix this:
Go to IIS Manager
Select the very top row in the Connections panel (typically your PC name)
At the very bottom of the right panel, under Management, you should have Web Platform Installer
Once that loads, select Products
In the search type in cgi then hit <Enter>
Select IIS: CGI then click Add on the right and finally Install on the bottom
After installing it should force you to restart your PC and you should be fixed.
To Fix the problem, Follow the steps as I faced the same issue and below solution worked for me
1- Give full Rights or at least read access rights of Folder "C:\inetpub\temp" to IIS_IUSRS
2- also check same rights given to User IIS_IUSRS of folder "C:\inetpub\wwwroot".
hope this solution works!
I had a similar issue, all my app pools were stopping whenever a web request was made to them. Although I was getting the following error in the Event Viewer:
The worker process for application pool 'appPoolName' encountered an
error 'Configuration file is not well-formed XML ' trying to read
configuration data from file
'\?\C:\inetpub\temp\apppools\appPoolName\appPoolName.config', line
number '3'. The data field contains the error code.
Which told me that there were errors in the application.config at:
C:\Windows\System32\inetsrv\config\applicationHost.config
In my scenario, I edited the web.config on deploy with an element IIS clearly dislikes, the applicationHost.config scraped the web.config and inserted this bad element and wouldn't resolve until I manually removed it
In addition to the steps outlined at this link from Orhan's answer, you may need to additionally remove the native module by going to IIS Manager > Server Root > Modules > Configure Native Modules. Select MfeEngine and then select Remove.
Changing "Managed Pipeline Mode" from "Classic" to "Integrated" worked for me.
It can be changed at Application Pools -> Basic Settings
One possible reason this might happen is that you don't have enough disk space in your server machine. You can find more information in event viewer.
if such thing happen, just stop the IIS, clean some free disk space and restart the IIS and then start the App Poll.
Such 503 errors were encountered on our side on Windows Server 2019 while setting up a fresh new Classic ASP website.
In fact, in the App Pool, setting ".NET CLR Version" to "No Managed code" caused the App Pool to stops 2 seconds after being started, thus generating WAS 5002 and 5021 errors in the Windows Event Log.
The solution was to put "v4.0", even if no .NET is used.
I'm late to the party, but the solution that worked for me isn't listed.
The solution for me was simply to delete the web site and application pool within IIS, and re-create them.
This is because originally I had create the site/folder first, then installed the dotnet core runtime. For some reason this failed to allow the site to start up.
Once re-created, the site came to life with none of the other suggestions being required.
In my case, the web sites displayed "503 Service unavailable" and the application event log showed "...\aspnetcorev2.dll failed to load. The data is the error." This only happened for IIS sites where where the IIS setting "Enable 32-Bit Applications" was True. The system was stopping the app pools for these sites, which is what generated the "503 Service unavailable" message when trying to retrieve the site.
It turns out the path specified in this application event log didn't even exist. Trying to repair the two "Microsoft.NET Core SDK 2.1.50x" versions installed on the system didn't resolve the issue, nor did installing the latest and only aspnetcorev2.dll that Microsoft seems to have available, nor did uninstalling these SDKs.
NOTE: Microsoft doesn't even seem to have the installers available anymore for the original v2 ASP.NET Core versions that had been installed on my system.
What worked:
Since I don't have any ASP.NET Core sites on this system, the solution that worked for me was to uninstall all the related DLLs from my system and to remove them from the IIS applicationhost.config file by commenting them out (see aspnetcore.dll failed to load and applicationhost.config file path in IIS 7, 7.5, 8, 8.5 and IIS 10?). If you do use a later version of ASP.NET Core, I'd think you could just as well update the references in applicationhost.config [I haven't tried that].
In my case this application pool automatically stopped due to error log folder I created in local which is not exist in server. Check the web.config file whether any key path you added which is exist in server or not.
Will this answer Help you?
If you are receiving the following message in the EventViewer
The Module DLL aspnetcorev2.dll failed to load. The data is the error.
Then yes this will solve your problem
To check your event Viewer
press Win+R and type: eventvwr, then press ENTER.
On the left side of Windows Event Viewer click on Windows Logs -> Application.
Now you need to find some ERRORS for source IIS-W3SVC-WP in the middle window.
if you receiving the previous message error then solution is :
Install Microsoft Visual C++ 2015 Redistributable 86x AND 64X (both of them)
Source
In my case error message displaed in Windows Event Viewer -> Windows Logs -> Application was "The Module DLL C:\Windows\system32\inetsrv\rewrite.dll failed to load. The data is the error."
Uninstalling rewrite module via installer solved the problem. I wasn't using any rewrite rules so I uninstalled rewrite module. Reinstalling the module may help the problem as well.
I just had this issue on some legacy servers running Windows 2008 R2. 32bit applications would crash the app pool and return a 503 without hitting the app code. The problem seems to be related to .net core module erroneously trying to load the 64bit version of the module even though the 32bit application in question was not a .net core app.
It seems that IIS still loads the module when figuring out which module to load to service the request and trying to load a 64bit version into a 32bit process is no bueno.
In the end, I had to uninstall all versions of .net core from the server and reinstall the latest (at this time 3.1.15- we're not using 5 yet). After that my 32bit apps and .net core apps could coexist on the same server.
This is the blog post that helped me resolve this after days of banging my head on it. Hopefully it helps someone out.
Blog post with the solution
Give full Rights rights to Folder "C:\inetpub"
Work for me!
Check the log written to [event viewer\Windows Logs\System] node.
Source is 'WAS'.
I am facing a problem for running my website.
I have developed the website and when i hit F5 to view the results i am presented with this error
Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.
Exception Details: System.Security.SecurityException: Request for the permission of type 'System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
How can i solve this problem.
This error usually happens if you Map your application folder on Network Drive or open Solution file from UNC Path. somthing like this:
Invalid Example: \\my-server\my-project
Try to open your solution from direct path
Valid Example: C:\Project\MyProject
You can also make change to your privilege of App Pool Identity but it's not recommanded:
Web Server (IIS) > App Pool Identity > Advance Settings > Set Identity as Network Service
the one shot solution worked for me was to set the App Pool Identity(Advance Settings) to Network Service
Try to set "Load User Profile" value of your application pool to "True".
It worked for me.
For what its worth, I found that the AjaxControlKit.dll on the deployed server was blocked. To resolve this, I copied over the dll to a new folder then copied and pasted in the bin folder. I guess .net doesn't like a dll being copied over directly to the web folder
you can run the following command to Grant FullTrust to remote share:
C:\Windows\Microsoft.NET\Framework\v2.0.50727>caspol.exe -m -ag 1 -url
"file:////\yourcomputername\yoursharename*" FullTrust -exclusive on
Hope this helps.
I tried all of the solutions posted here and a number of other places and nothing worked for me. I had my project located on a network drive which worked until I tried to use the AjaxControlToolkit 2.0 in my project. Apparently, something about permissions on the network drive would not allow the controls in the toolkit to run. I moved my project back to my local hard drive and it all started working.
I had this problem as well but have not seen this particular solution mentioned anywhere.
After checking permissions for the IIS user, the user for Impersonation, and granting Full Trust to the application, and still getting the error, I installed Procmon.exe on the server running IIS and noticed that IIS was attempting to access some Framework64 files for the offending website. I inspected the application pool advanced settings and discovered that "enable 32-bit applications" was set to false. Changing this setting to true proved to be the correct action. Life is good.
I face the same problem, then I realised that I was running the solution from a remote folder. Copy the necessary file to the local folder will solve the issue. But make sure that your folder have the full permission
While all of the other answers on this page may be the cause of anyone's problem, the most common one is due to OS security changes in Windows Server 2012 and above. Any file downloaded from the internet is flagged as suspicious by Windows and needs to be manually unblocked before using it in IIS. So if you FTP your code, email it, or transfer it through a cloud provider, it will be flagged and blocked.
The best solution is to use the web publishing facilities built in to Visual Studio or transfer through a network share if you're on a domain, each of which avoid this problem. However, if you must copy your code to another server by one of the means I described above, you should zip everything prior to transfer so you are only left with a single file to unblock. If you unzip before you unblock, then each file will be blocked and multi-selection will not give you the option to unblock.
So finally... to unblock: Right click the file and select Properties. Right there on the first page near the bottom you'll see an Unblock button along with the warning that the file was downloaded from the internet!
If the dll is compiled using this option (Do not merge. Create a separate assembly for each page and control), please make sure the dll is up to date. I faced the error due to aspx file is new one, but dll still using old one.
I found a potential solution that worked on my system and did not require changing to Network Service.
Go to Application Pool -> Advanced Settings -> Process Model -> Load User Profile: True
Source of this answer.
The best way to resolve this issue is Run the Visual Studio as "Administator". Right click on the Visual Studio icon and select "Run as Administrator".
Once you open Visual Studio with Full admin rights, you will be able access the page without any issues.
I have had this error and it seems to be a generic error. As there are several answers to this issue, I am going to add mine. Republishing the website on the remote server seems to fix it for me.
Recently we migrated our development environment from VS2008 to VS2010 (Ultimate).
For one solution (for now all C#, .NET Framework 3.5 and ASP.NET 2.0) which contains 6 projects VS auto-upgraded it without any problems.
The solution projects are:
ASP.NET website
VS2010 Web Deployment project for above site
Web Services Application
VS2010 Web Deployment project for above WSA
A class library.
Another class library.
However, when we build we have 1 error:
Could not load file or assembly 'ClassLibrary1BLL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An API call exited abnormally. (Exception from HRESULT: 0x800300FA (STG_E_ABNORMALAPIEXIT))
After research I finally tracked this to one entry in the ASP.NET website config:
If I build with this line the problem occurs:
<identity impersonate="true" userName="DOMAIN\user" password="password"/>
However, if I comment out and build with the following line (without the supplied credentials) the solution builds fine AND then amend the web.config back to the above (with the credentials) the site runs fine - the credentials only cause a problem for the build.
<identity impersonate="true"/>
Now here is the strangest issue - the Web Services Application builds fine with the supplied credentials - the build error ONLY occurs for the ASP.NET website. This all holds true whether the projects are built individually or the solution rebuilt.
Any pointers how I can successfully build with the supplied credentials will be greatly appreciated.
Check the permissions of the impersonation user.
After just setting the flag to false, <identity impersonate="false"/>, it also came to life for me.
However, once setting it back to true, it built fine, but when I loaded the site, I got:
The current identity (XN-DTDEV\Fusion)
does not have write access to
'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary
ASP.NET Files'.
Now this machine is on a domain, and that user is local, which should have administrative privileges. When I checked back, it didn't. It looks like there is a policy re-setting the local administrators each reboot.
I realize there's already an accepted answer, but for anyone else coming to this page via a search on the error code....
Review the permissions of the user that you're trying to impersonate.
In my situation, I was only getting the error on my development machine, rather then on our staging or deployment servers. (For a while I got around this by removing the 'identity' node from config in my dev environment and just adding the line in post-build so it wasn't a problem anyone other than me..
In my environment we have a specific user that all our web apps impersonate when running. I had created the user account, but hadn't explicitly set its account permissions. When I added the user as an Adminstrator on my dev machine, this problem went away completely. (Not ideal, I know, but it "works for me", and has minimal harm since that user account is locked down on our 'real' servers anyways..)
after changing permissions on "Temporary ASP.NET Files" you need to delete its contents and allow the new files to inherit the new security permissions
If any of the solutions mentioned before didn't work, and you're using impersonation.
The answer is to give permission for the user that you're impersonating access to the following folders :
C:\Windows\Microsoft.NET\Framework[v4.0.30319 or the version that you're using]\Temporary ASP.NET Files
Your site directory.
also you might need to create folder as the following :
C:\Windows\Microsoft.NET\Framework\[v4.0.30319 or the version that you're using]\Temporary ASP.NET Files\[Application-Name-Goes-Here]
But try the previous first, it worked for me.
Those two changes for granting the impersonated user permission to be able to save the temp data, and pull the dll files, and any needed files from the directories
Thanks for the reply mattdwen - unfortunately your suggestion never worked (the 'Temporary ASP.NET Files' folder permissions were correct) but did provide the hint that lead to me (HACK) resolving the problem. After reading your answer I tried the following which led me in a different direction:
(1) I successfully rebuilt the solution 3 times using <impersonate="true"/>, <identity impersonate="false"/> and <identity impersonate="true" userName="DOMAIN\different-user" password="password"/> (here "different-user" is a local admin).
(2) I then amended the web.config back to the original <identity impersonate="true" userName="DOMAIN\user" password="password"/> and ONLY rebuilt the ASP.NET website project - success.
This has led me to conclude (strongly hinted at by the original error message) that VS when rebuilding the solution is unable (for as yet unknown reason) to build one of the Class Libraries or its dependencies with <identity impersonate="true" userName="DOMAIN\user" password="password"/> in the ASP.NET website project.
The Class Library in question has a number of references to 3rd party components, Office interops, etc. which for now would be too time consuming to attempt to eliminate one by one and discover the real underlying reason.
Therefore, I have temporarily implemented the hack (cringe) to add the original user to local admins.