The problem
IIS ASP.NET Core module is unable to start an ASP.NET Core 2.0 app.
Browser: HTTP Error 502.5 - Process Failure
Windows Event Log: Application ‘MACHINE/WEBROOT/APPHOST/AppSite’ with physical root ‘C:\inetpub\apps\AppFolder\’ failed to start process with commandline ‘C:\inetpub\apps\AppFolder\App.exe’, ErrorCode = ‘0x80004005: 1’.
ASP.NET Core Module Log: Log file is created but is empty.
The setup
App: ASP.NET Core 2.0 targeting .NET Framework 4.6.1.
Server: Windows Server 2012 R2 Standard 6.2.9200 with IIS 8.5.9600.
The story
We've created a blank MVC Web application using the default project templates provided in Visual Studio 2017.
The app is deployed following the official specification: https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/.
The confusion arises mainly from these two points:
Running the app through command-line on Kestrel works.
Running a different app but targeting .NET Core 2.0 and publishing as framework-dependant works flawlessly on IIS.
But between these two apps: the codebase is the same, the IIS website and application pool is the same and we even emptied out the app directory and used the same one.
Due to these points the only difference seems to be the net461 app's executable file.
We do not have full control over the Windows Server where we're trying to deploy but we do have administrator accounts. The current assumption is that the issue lies within permissions - maybe AD group policies, antivirus blocking the file but we're still awaiting response from the client's sysadmins. Meanwhile we haven't been able to replicate the error code ‘0x80004005: 1’ while trying to setup these restrictions on our development machines.
Here's an incomplete list of ideas and points about the issue we've tried while problem solving:
The initial app (targeting net461) works flawlessly on IIS when
deployed to other servers (Windows 10 Enterprise, Windows Server 2012
R2 Datacenter).
Reinstalling different versions of ASP.NET Core/.NET Core: Runtime & Hosting Bundle.
Setting NTFS permissions to the dotnet folder.
Changing IIS application pool identity to an administrator account.
Restarting the server.
Going over local group and security policies.
Going over the antivirus settings and logs.
Trying to deploy on a brand new server (same OS, same bloat).
All ideas/comments are greatly appreciated. The more obscure the better.
EDIT:
Since this got flagged as a possible duplicate of ASP.NET Core 0x80004005 I need to specify why that is not a duplicate.
That referenced project is an older version of ASP.NET Core (last use
of project.json was in 2016)
That referenced project targets .NET Core and not .NET 4.6.1. It is mentioned here as well that targeting .NET Core works on IIS in regard to this issue.
Selected answer points out that they fixed it by:
Turns out that this was result of needing to install some windows
updates and this problem:
api-ms-win-crt-runtime-l1-1-0.dll is missing when opening Microsoft
Office file
Rather than install the version discussed in the above issue I whet
into Programs and Features and ran a repair on Microsoft Visual C++
2015 Redistributable.
but the installation of Microsoft Visual C++ 2015 Redistributable is one of the steps in the official setup guide and it is mentioned here as well that the official guide has been followed during the setup process.
We have gone over that post and tried to repair and reinstall the Microsoft Visual C++ 2015 Redistributable runtime components and this did not fix the issue.
If anyone stumbles upon this post in the future:
The problem was indeed in the server's antivirus. It wasn't directly blocking the app's executable but its call to a class library in the system folder. This termination did not raise any of the usual alarms.
The application "C:\inetpub\apps\AppFolder\App.exe" attempted to load the library "bcrypt.dll" by calling the function "LoadLibraryExW". The operation was blocked and the application terminated.
After switching the MVC blank app to a completely blank Hello-World app it ran successfully.
Related
I have a .NET Core web API that works fine when hosted in IIS on my local Windows 10 desktop OS. However, when I deploy the same code to a Windows Server 2016 machine, the app pool in IIS fails 5 times and then stops the app pool. The error in the event viewer indicates the following:
A process serving application pool 'My API' reported a failure during application preloading or service loading. The process id was '416'. Please ensure that all application preload or service settings in the application pool are configured properly. The data field contains the error number.
I've tried configuring the API to write out to the stdout, but it doesn't ever generate a log file.
This API was originally written in .NET Core 2.2, so I tried upgrading it to .NET Core 6 and have the same issue - it works in Windows 10 with IIS, but not on Windows Server 2016. The hosting bundle for the appropriate version is installed on the server. I found that if I change the app pool that is hosting my API to have a .NET CLR Version of .NET 4 instead of 'No Managed Code', it then works. All documentation indicates 'No Managed Code' is recommended.
I did actually get it to work at one point with the app pool set to 'No Managed Code'. I ran procmon to see if there were any failures accessing registry keys, system files or folders, etc. and did find that if I copied a few files like webengine.dll, webengine4.dll, and aspnet_rc.dll from the folders they were actually in to folders where procmon indicated it was looking for them in, it then worked. Obviously though I don't want to be copying system files to various locations.
My guess is that something isn't installed on the server or I've misconfigured something as I got the same result when creating a test Web API project in Visual Studio and used the sample endpoints included in the default project. Unfortunately I can't figure out what is missing or misconfigured.
I ran the JexusManager ASP.NET Core Diagnostics tool and this is the report:
System Time: 7/20/2022 8:01:35 AM
Processor Architecture: AMD64
OS: Microsoft Windows NT 10.0.14393.0
Server Type: IIS
Scan 35 installed module(s).
ASP.NET Core module version 2 is installed for .NET Core 3.1 and above: C:\Program Files\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll (16.0.22173.7).
Scan 91 registered handler(s).
* Found a valid ASP.NET Core handler as { Name: aspNetCore, Path: *, State: Enabled, Module: AspNetCoreModuleV2, Entry Type: Local }.
Visual C++ runtime is detected (expected: 14.0, detected: 14.12.25810.0 built by: VCTOOLSREL): C:\Windows\system32\msvcp140.dll.
The application pool 'Test API' is used.
Pool identity is NetworkService
Please ensure pool identity has read access to the content folder D:\Program Files (x86)\My Company\Test API.
Pool bitness is 64 bit
Scan aspNetCore section.
"processPath": dotnet.
"arguments": .\TestApi.dll.
"hostingModel": inprocess.
In-process hosting model is detected. To avoid 500.xx errors, make sure that the bitness of published artifacts matches the application pool bitness
Framework dependent deployment is detected. Skip bitness check.
Found runtime config file D:\Program Files (x86)\My Company\Test API\TestApi.runtimeconfig.json.
Runtime is 6.0.0.
I did verify the bitness and the folder permissions. Both were set properly.
I have an asp.net core 2.0 hosted locally on IIS 10. For some reason DefaultAppPool keeps stopping as soon as I hit the hosted website.
And I am getting HTTP Error 503. The service is unavailable.
In event logs I see following error;
The Module DLL C:\WINDOWS\system32\inetsrv\aspnetcore.dll failed to
load. The data is the error.
When I check the path C:\WINDOWS\system32\inetsrv\ I do not see aspnetcore.dll exists. Should it be there? If yes, .net core installation exe shouldn't be copy it?
Here are some information below;
What I tried, and did not worked?
Troubleshooting IIS AppPool crashes
Uninstalled .net core and reinstalled.
Changed App Pool Identity to Network Service etc.
Any idea how I can fix this?
For hosting .Net Core applications in IIS, .Net CLR Version of application pool should be No Managed Code as shown in below screenshot. If you don't see "No Managed Code" option in in dropdown then you need to install .Net Core Hosting Bundle.
Ensure you have .NET Core Hosting Bundle installed as mentioned here:
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/?view=aspnetcore-2.1&tabs=aspnetcore2x
I also had this problem in Windows server 2012 R2
I found this answer:
ASP.NET Core/.NET Core: Runtime & Hosting Bundle (latest versions) depends on Microsoft Visual C++ 2015 Redistributable
Download and install KB2919442
Run windows update, which will download and install KB2919335. Alternatively manually download and install KB2919335
Install Visual Studio 2015 C++ Redistributable
I got this issue one time. Reason was Server OS was x64 base and target run time of installer was win-x86. In the publish wizard, win-x86 is the default option for Target Run time. Theoretically x86 application should work in x64. But after deploying the win-x64 , issue resolved.
I have had webdeploy running for YEARS on a Windows Server 2012 machine with standard MSBuild arguments (like this).
Yesterday I installed the Windows (Server Hosting) version of the .NET Core Installer from the .NET Core downloads page.
Since then my build tasks are running and successfully building my website, but not actually running any web deploy publishing. It is not failing - it is just not being run.
I want to stress I am talking about a 'legacy' .NET application - not a .NET Core application. I just installed .NET Core for somebody else.
I can verify this with the following observations:
There are no errors in any event viewers (except ones that are months old)
There is no message in the msbuild logfile that says Start Web Deploy Publish, however log files from just a couple days ago do have this message.
I can connect to the local server at port 8172 and it makes a connection.
It is happening with multiple projects that nobody else has access to.
_PublishedWebsites does get created with the latest files - it just never gets deployed anywhere.
What could possibly have broken this? Did the Windows Server Hosting package break it - or was it just some other update that came in? I've run out of ideas how to fix it and don't want to revert to xcopy!
Managed to fix it :-) Not sure exactly which of these steps did it, but I suspect it was Visual studio.
I was using TFS Express 2015 and upgraded to Update 3.
I also installed Visual Studio 2015 on the server itself.
I had previously had .NET Core RC2 (or whatever they called it at the time) installed and I uninstalled that before installing .NET Core RTM. Wondering if that removed some component that was required.
Like I said everything was working fine before I installed the .NET Core RTM - but fortunately installing VS and TFS brought everything back to normal.
After migrating TeamCity from one server to another, and also switching to Visual Studio 2013, our build fails when using MSDeploy to push a TC-built .zip package to IIS.
The application pool that you are trying to use has the
'managedRuntimeVersion' property set to 'v4.0'. This application
requires 'v4.5'
This is a strange error since my IIS server has .NET 4.5 installed and has been happily running and being deployed to for weeks, and a 4.0 application pool will run a 4.5 targeted app.
Unfortunately, the waters are muddied by the changes to TC and VS (2013) so what caused the issue I cannot be sure of.
Note: Our TC server only has Visual Studio 2012 on it, since I'm on MSDN and got early access to 2013. This could be the culprit, but doesn't make the issue any less odd.
I'd prefer not to disabled .NET runtime version checking at all (with IgnoreDeployManagedRuntimeVersion), but instead implicit set runtime version via DeployManagedRuntimeVersion:
<DeployManagedRuntimeVersion>v4.0</DeployManagedRuntimeVersion>
Some more details: http://techblog.dorogin.com/2013/11/deploying-45-projects-with-webdeploy.html
Open your .csproj file and set the following element:
<IgnoreDeployManagedRuntimeVersion>True</IgnoreDeployManagedRuntimeVersion>
Adding it just above this element helps readability:
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
Kudos to https://stackoverflow.com/users/1769923/abhishikt-n-jain for answering with this little-known config setting here:
MSBuild deploy failing after upgrade to .NET 4.5
If anyone knows why this happens, please feel free to add an answer.
Update
Disregard my comments below. While it got me past the deploy, I got a 503 Service Unavailable when I actually tried to run the web app. I backed out this change by setting the managedRuntimeVersion property back to v4.0 and added the IgnoreDeployManagedRuntimeVersion to my project. Then the deploy succeeded and the app worked. Dumb...
This happened to me after I installed .NET Framework 4.5.1 on a Windows Server 2008 R2 SP1 machine (as part of upgrading Powershell).
The IIS user interface on Windows Server 2008 doesn't give the option of setting the managedRuntimeVersion property to v4.5 even after that version is installed. However, this can be done on the command line using the appcmd utility as #3boysdad's answer shows.
appcmd is the command-line equivalent of managing IIS sites, apps, apppools, etc. It is located at %systemroot%\system32\inetsrv\appcmd.exe but it is not on the PATH as the following link explains:
http://www.iis.net/learn/get-started/getting-started-with-iis/getting-started-with-appcmdexe#HowToUse
I'm of the opinion that modifying your project (via the IgnoreDeployManagedRuntimeVersion or DeployManagedRuntimeVersion properties) is sub-optimal. The application pool should be set to use v4.5, and the only way to do that on Windows Server 2008 is to use the appcmd utility. #3boysdad's answer should be the accepted answer.
found this gem while hunting around for this same problem.
appcmd set apppool /apppool.name: <your app pool> /managedRuntimeVersion:v4.5
this will need to be executed in your \System32\inetsrv directory.
I'm using IIS 7.5 on Windows Server 2008 R2 x64 Enterprise Edition. In the project we have developed with ASP.NET 4.0 we used WCF Service. But it doesn't run over domain when the software is running from local computer. Otherwise, I am getting the following error:
HTTP Error 404.3-Not Found
The page you are requesting cannot be served because of the extension
configuration. If the page is script, add a handler. If the file should
be downloaded, add a MIME map.
You should install IIS sub components from
Control Panel -> Programs and Features -> Turn Windows features on or off
Internet Information Services has subsection World Wide Web Services / Application Development Features
There you must check ASP.NET (.NET Extensibility, ISAPI Extensions, ISAPI Filters will be selected automatically). Double check that specific versions are checked. Under Windows Server 2012 R2, these options are split into 4 & 4.5.
Run from cmd:
%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ir
Finally check in IIS manager, that your application uses application pool with .NET framework version v4.0.
Also, look at this answer.
In my case, along with Mekanik's suggestions, I was receiving this error in Windows Server 2012 and I had to tick "HTTP Activation" in "Add Role Services".
In windows server 2012, even after installing asp.net you might run into this issue.
Check for "Http activation" feature. This feature is present under Web services as well.
Make sure you add the above and everything should be awesome for you !!!
I was having trouble accessing wcf service hosted locally in IIS. Running aspnet_regiis.exe -i wasn't working.
However, I fortunately came across the following:
Rahul's blog
which informs that servicemodelreg also needs to be run:
Run Visual Studio 2008 Command Prompt as “Administrator”.
Navigate to C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation.
Run this command servicemodelreg –i.