1
votes

I am having difficulty getting an ASP.NET Core 2.2 app running behind IIS 7.5 on Windows Server 2008 R2.

I am able to run the app manually (with dotnet .\WebApp.dll), so I believe the framework/runtime is correctly installed, but there seems to be an issue with the AspNetCore Module when trying to run with IIS. I receive an HTTP 502.5 - Process Failure response from IIS, and in Event Viewer I have found the following error:

Application 'APP_NAME' with physical root 'C:\path\to\app' failed to start process with commandline 'dotnet .\WebApp.dll', ErrorCode = '0x80004005' : 80008082.

I am unable to find information on the error code '0x80004005' : 80008082. Anyone know where I can find the specific meaning of this code?

EDIT: I have seen posts regarding error code '0x80004005' : 80008083, but this does not seem to be the same issue. With that error code, it seems that the app can not be run manually, which I am able to do with no problems.

1
Is the .NET CLR version in the app pool set to No Managed Code? Has the Identity been set correctly for the app pool. Have you checked the Windows Event Log to see if any errors are being logged on process start?Stuart Frankish
Enable stdout logging in your app's web.config file to see the error details.Uwe Keim
App pool is set to No Managed Code and the identity is set to an account with access to the path. Stdout has been enabled and only creates empty log files upon each request.jraf
Windows Event Log does show errors, but nothing more specific than the one posted: Application 'APP_NAME' with physical root 'C:\path\to\app' failed to start process with commandline 'dotnet .\WebApp.dll', ErrorCode = '0x80004005' : 80008082.jraf

1 Answers

1
votes

I now have the app running successfully, and I believe the cause to have been that the app was published as a standalone app instead of framework dependent. I had originally published the app as a self-contained win-x86 app, and neither the default processPath="App.exe" nor processPath="dotnet" arguments=".\WebApplication3.dll" worked.

After publishing as a framework-dependent portable app, things are now working correctly.