This repository has been archived by the owner. It is now read-only.

HTTP Error 502.5 - Process Failure" asp.net core 2 error in Azure #406

Closed
CharlBest opened this Issue Aug 16, 2017 · 41 comments

Comments

Projects
None yet
@CharlBest

CharlBest commented Aug 16, 2017

image

I updated my projects from .NET Core 1.1 to .NET Core 2.0.
I then deploy my API app and Web app via Visual Studio 2017 15.3 web deploy and now have these errors when visiting my apps.

I have tried the possible fix mentioned in this Stack Overflow post but it doesn't seem to work. https://stackoverflow.com/questions/45694286/net-core-2-0-azure-app-service-502-5-error/45715420#45715420

This was a problem in the past here: #252
I also spoke to @davidebbo about this in Azure/app-service-announcements-discussions#6 (comment)

Thanks in advance.

@CharlBest CharlBest changed the title from HTTP Error 502.5 - Process Failure" asp.net core error in Azure to HTTP Error 502.5 - Process Failure" asp.net core 2 error in Azure Aug 16, 2017

@pan-wang

This comment has been minimized.

Contributor

pan-wang commented Aug 16, 2017

@CharlBest Could you please turn on logging from web.config and collect Windows event log? Those logs will give the hint on why the failure happens.

@CharlBest

This comment has been minimized.

CharlBest commented Aug 16, 2017

@pan-wang how would I do that? Firstly I don't have a web.config file in my solution and secondly not sure what code to write. Can you please specify?

@CharlBest

This comment has been minimized.

CharlBest commented Aug 16, 2017

@pan-wang I got this from my Log Stream on Azure. Hope it helps
image

@JunTaoLuo

This comment has been minimized.

Contributor

JunTaoLuo commented Aug 16, 2017

The web.config is produced by the publish step if none is provided in the solution. You need to modify the stdoutLogEnabled value in the line line

<aspNetCore processPath="dotnet" arguments=".\App.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

to true and make sure the directory specified in stdoutLogFile exists.

@davidebbo

This comment has been minimized.

davidebbo commented Aug 16, 2017

More specifically, you'll need to use Kudu Console (https://{yourapp}.scm.azurewebsites.net/), go to site\wwwroot, and edit the web.config you see in there.

@CharlBest

This comment has been minimized.

CharlBest commented Aug 16, 2017

Thanks @davidebbo. I used the new awesome App Service Editor (Preview). Really really nice. Feels like VS Code on the web. Very impressed. Anyway got this message in my logs:

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Microsoft.AspNetCore.Hosting.Abstractions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
at Things.Api.Program.Main(String[] args)

@JunTaoLuo

This comment has been minimized.

Contributor

JunTaoLuo commented Aug 16, 2017

This could be potentially a problem with the runtime store containing mismatching binaries. Let me see if I can reproduce the issue.

@CharlBest

This comment has been minimized.

CharlBest commented Aug 16, 2017

Ok cool. Thanks @JunTaoLuo Let me know if I can do something :)

@davidebbo

This comment has been minimized.

davidebbo commented Aug 16, 2017

See https://stackoverflow.com/questions/44550096/asp-net-core-2-0-on-azure-results-in-a-502-5. That issue relates to having old things leftover from previous 1.x deployment. Can you try wiping out wwwroot and deploying clean?

@CharlBest

This comment has been minimized.

CharlBest commented Aug 16, 2017

Yayyyyy @davidebbo Its working. Thank you.

  1. I couldn't understand why you would want me to wipe the wwwroot folder as it only contains static web stuff. Then I saw that all die dll files are also in a folder called WWWROOT.
  2. I removed the wwwroot folder (not emptying it and leaving the empty folder) and got a deployment error. Re-added an empty WWWROOT folder and deployment was happy.
    But it looks like its working now. Tested with my API app and will update this comment if the Web app also works but I think it will.

You guys are awesome. Thank you so much for the quickly replies. 👍

Update:
Web App Service is also up and running after clearing the wwwroot folder. Thanks again.

@davidebbo

This comment has been minimized.

davidebbo commented Aug 16, 2017

Awesome! @pan-wang, we can probably close this, and hopefully others running into it will find the issue.

Unfortunately, it's more an msdeploy issue (leaving dirty files) then an Azure or Core issue.

@JunTaoLuo JunTaoLuo closed this Aug 16, 2017

@fpizarro

This comment has been minimized.

fpizarro commented Aug 23, 2017

Hi guys, today I had the same problem. My approach was specify Release X86 in the settings tab in the publish form in Visual Studio 2017.

I did this because the assemblies for deployment are stored in the local path for x86, you can find them on your machine: cd "%ProgramFiles(x86)%\dotnet\store"
image

@ddobric

This comment has been minimized.

ddobric commented Aug 25, 2017

Hi all,

  1. where is the physical path of '.\logs\stdout' ? Under LogFiles? Where we have to create the folder stdout?

  2. Previously we have used
    UseSetting("detailedErrors", "true")
    CaptureStartupErrors(true)
    to output errors. Now this does not work anymore.

My general feedback on diagnostics:
In general, figuring out of such kind of errors is extremely complex. We have to use advanced tools to find very simple errors. Then, we have to do lot of configuration (enable diagnostics etc.)
At the end we have too many sources like logstream, application logfiles, eventlog files, Detailed Errors (which is nothing that HTML page shown to the user. It means it is not detailed), dumps,..

Last but not least, at the moment of writing of this, I still do not know what is my error. :)

My expectation is following:

  1. Application Fails.
  2. Admin LogsOn to portal and see the error.

No configuration, no web.config changes, no KUDU.

Thanks

@ddobric

This comment has been minimized.

ddobric commented Aug 25, 2017

Thanks.

Where is the physical path of '.\logs\stdout'

@dallancarr

This comment has been minimized.

dallancarr commented Aug 25, 2017

Should be from the approot. stdout-xxx.log is generated automatically.

@bplus0

This comment has been minimized.

bplus0 commented Sep 27, 2017

I have followed all the directions in this thread, and i'm still getting the same error. I enabled the web.config to write out the stdout log, but it never writes anything. Is there a way to force it to write? Does the file name need to be "stdout.log"? or "stdout" or "stdout.txt"? My app runs perfect on local, and I cannot hunt it down

This is what my solution looks like. Does .NET Core work with DLL's? I am used to .NET Standard where I can see my Views and Models, but this is a lot different looking.

2017-09-27_1628
2017-09-27_1629

@Tratcher

This comment has been minimized.

Member

Tratcher commented Sep 28, 2017

@bplus0 can you show that line of your web.config?
Also, what do you get in your event logs?

@bplus0

This comment has been minimized.

bplus0 commented Sep 29, 2017

@Tratcher Hey - here is the entire web.config, This was made completely from my publish, I don't have any web.config in my solution.

<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="dotnet" arguments=".\SecretSantaApp.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

Can you elaborate a little more on what you mean by event logs? I haven't been able to find anything relevant in the folders I submitted in my previous post.

If you want more info in a PM I can provide that - (I don't know the rules on long threads on GitHub)

Edit- Hey @Tratcher, does this make any sense to you? If not I can remove it from this comment. I just want to make sure I provide enough info when posting my issue.

#Software: Microsoft Internet Information Services 8.5
#Version: 1.0
#Date: 2017-09-29 15:47:03
#Fields: date time s-sitename s-computername s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs-version cs(User-Agent) cs(Cookie) cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken
2017-09-29 15:47:03 W3SVC150 asphost164 198.23.81.233 GET / - 80 - 65.162.99.29 HTTP/1.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/61.0.3163.100+Safari/537.36 - - elfbuddies.com 200 0 0 5709 495 359
2017-09-29 15:47:03 W3SVC150 asphost164 198.23.81.233 GET /favicon.ico - 80 - 65.162.99.29 HTTP/1.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/61.0.3163.100+Safari/537.36 - http://elfbuddies.com/ elfbuddies.com 200 0 0 113742 394 328
2017-09-29 15:58:37 W3SVC150 asphost164 198.23.81.233 GET / - 80 - 65.162.99.29 HTTP/1.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/61.0.3163.100+Safari/537.36 - - elfbuddies.com 502 5 0 1657 468 765
#Software: Microsoft Internet Information Services 8.5
#Version: 1.0
#Date: 2017-09-29 16:01:07
#Fields: date time s-sitename s-computername s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs-version cs(User-Agent) cs(Cookie) cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken
2017-09-29 16:01:06 W3SVC150 asphost164 198.23.81.233 GET /index - 80 - 65.162.99.29 HTTP/1.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/61.0.3163.100+Safari/537.36 - - www.elfbuddies.com 502 5 0 1657 392 656
2017-09-29 16:05:14 W3SVC150 asphost164 198.23.81.233 GET / - 80 - 65.162.99.29 HTTP/1.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/61.0.3163.100+Safari/537.36 - - elfbuddies.com 502 5 0 1657 409 593
2017-09-29 16:05:30 W3SVC150 asphost164 198.23.81.233 GET / - 80 - 65.162.99.29 HTTP/1.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/61.0.3163.100+Safari/537.36 - - elfbuddies.com 502 5 0 1657 409 593

@Tratcher

This comment has been minimized.

Member

Tratcher commented Sep 29, 2017

Ok, the .\logs\ seems to exist. I wonder if there's a permissions problem preventing it from writing the logs there.

Those look like FREB logs, and all they tell us is that you got a 502.5 error.

I meant the windows event logs. Though looking at your screen shots I realize that you're on some public hoster? They may not expose those to you. I know Azure copies them to a log folder in your app.

@bplus0

This comment has been minimized.

bplus0 commented Sep 30, 2017

Its a 'cheaper' solution than azure. I'm working with them to see if they are the issue. I do have one thing for you though -

if you see the screen shots above. There are no 'Views', 'refs', or 'runtime' directories. When i publish the 1.1 version of the same app everything goes with. Did something change in core 2.0 regarding publishing all files? Does that make sense?

@Tratcher

This comment has been minimized.

Member

Tratcher commented Oct 2, 2017

2.0 uses pre-compiled views by default so those files no longer need to be published.

@bplus0

This comment has been minimized.

bplus0 commented Oct 3, 2017

@Tratcher Thanks Chris. By the way - I reached out to the hosting service. They had to change something on their end to let .NET Core 2.0 run. I'm good to go, and I think the help listed here had something to do with it. Thanks again!

@nojaf nojaf referenced this issue Oct 13, 2017

Closed

Deploy to IIS #112

@ndreisg

This comment has been minimized.

ndreisg commented Nov 29, 2017

Today I got this error in my Azure Web App but deleting the WWWROOT folder did not help.
The problem was, that the .net Core Runtime of my Azure instance was automatically updated to 2.0.3 and so my 2.0.0 Deployment did not work anymore.

Is it possible to avoid the automatic update??

@davidebbo

This comment has been minimized.

davidebbo commented Nov 29, 2017

@ndreisg the upgrade to 2.0.3 should not be causing any deployment failures. If you think you have a case where it does, please open a separate issue so we can investigate that specifically. And please make it clear whether the problem happened as a result of deploying, or whether the app that was running suddenly broke with no deployments on your end (but not here, in a separate issue please).

@bigo92

This comment has been minimized.

bigo92 commented Dec 9, 2017

azure not suport dotnet 2.0.3 runtime
you fix: open file xxx.csproj
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.3" /> => errror 502 deploy
relapce code
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" /> => done

@davidebbo

This comment has been minimized.

davidebbo commented Dec 9, 2017

azure not suport dotnet 2.0.3 runtime

@bigo92 that is not correct. Azure App Service has had 2.0.3 for several weeks.

@plutosolutions

This comment has been minimized.

plutosolutions commented Dec 14, 2017

Hi,
Have you fixed it ?
Here is the solution https://youtu.be/rAA1FVA0fog

@bigo92

This comment has been minimized.

bigo92 commented Dec 28, 2017

@plutosolutions

This comment has been minimized.

plutosolutions commented Dec 28, 2017

You are welcome.

@arunprasathv

This comment has been minimized.

arunprasathv commented Feb 1, 2018

is there a different command to do Framework Dependent Deployment. Its recommended. @plutosolutions \

@agnimitra

This comment has been minimized.

agnimitra commented Feb 13, 2018

I ran through the same issue today and have fixed by changing web.config file.
https://stackoverflow.com/questions/38624453/asp-net-core-1-0-on-iis-error-502-5/48761913#48761913

@AdrianPT

This comment has been minimized.

AdrianPT commented Mar 5, 2018

I my case was a .Net framework that was not installed in the IIS server.

My project have the .Net Framework 4.6.1 as target... so I install the .Net Framework 4.6.1 in the server and the problem is solved.

@haydenhancock

This comment has been minimized.

haydenhancock commented Mar 16, 2018

Does Azure support Microsoft.AspNetCore.All (2.0.6) yet? I am having the same issue when deploying a newly created project from Visual Studio 2017 15.6.2. Microsoft.AspNetCore.All (2.0.6) is what ships with this version of Visual Studio 2017. The issue can easily be reproduce by following these steps:

  1. Open Visual Studio.
  2. Click File > New > Project.
  3. Select .NET Core and choose ASP.NET Core Web Application.
  4. Leave other defaults and click OK.
  5. Select API, click OK.
  6. Right-click project, select Publish....
  7. Click Publish.
  8. Ensure app service settings are complete, click Create.
  9. The publish succeeded, however, the Site Url throws a 502.5 Error.

Attempting to downgrade to < 2.0.6 doesn't work; publishing will throw an error.

Severity Code Description Project File Line Suppression State Error The command ""dotnet" exec --runtimeconfig "C:\Users\Hayden Hancock\source\repos\WebApplication2\WebApplication2\bin\Release\netcoreapp2.0\WebApplication2.runtimeconfig.json" --depsfile "C:\Users\Hayden Hancock\source\repos\WebApplication2\WebApplication2\bin\Release\netcoreapp2.0\WebApplication2.deps.json" "C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.razor.viewcompilation\2.0.3\build\netstandard2.0\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.dll" @"obj\Release\netcoreapp2.0\microsoft.aspnetcore.mvc.razor.viewcompilation.rsp"" exited with code 1. WebApplication2 0

It won't let me post what my web.config looks like from the App Service Editor.

@Tratcher

This comment has been minimized.

Member

Tratcher commented Mar 16, 2018

The deployment is not complete, see Azure/app-service-announcements#92

@davidebbo

This comment has been minimized.

davidebbo commented Mar 16, 2018

The deployment is now complete.

@haydenhancock

This comment has been minimized.

haydenhancock commented Mar 16, 2018

@davidebbo Thanks for the update. I will attempt another deployment when I am able and let you know the result.

I attempted a deployment using Visual Studio 2017 15.5.7 which ships with Microsoft.AspNetCore.All (2.0.5) and I still have issues (http://webapplication320180316115814.azurewebsites.net/).

Any reason, that you are aware of, that would cause downgrades of Microsoft.AspNetCore.All to cause build issues with Visual Studio 2017 15.6.2?

@davidebbo

This comment has been minimized.

davidebbo commented Mar 16, 2018

@haydenhancock I think it would be best to open a new issue to discuss. This one looks like it's been already used for various unrelated issues (even if they all happen to end up with a Process Failure), and it's been closed for a while. Also, please include a sample repo to make it easier to investigate. Thanks!

@haydenhancock

This comment has been minimized.

haydenhancock commented Mar 16, 2018

@davidebbo Done #681. Thanks!

@JasonKnarr

This comment has been minimized.

JasonKnarr commented Apr 4, 2018

If anyone happens to get this far in the comments and is having the same issue, check to see if the correct .NET SDK is installed on the server you are publishing to.

In my case, all I had to do was install the .NET Core 2 SDK and the API started working after my upgrade.

@enginaar

This comment has been minimized.

enginaar commented May 31, 2018

This just started happening out of nowhere and a quick investigation revealed that it's having trouble finding the Microsoft.AspNetCore.Antiforgery library which I don't use. I don't have any problems on my dev env, this is only happening on the staging server.

I have found a couple of workarounds but what I care about right now if anybody knows why this is happening. I'm about to go live with a project using .net core the first time and I cannot afford this happening on production.

@osca2000

This comment has been minimized.

osca2000 commented Jul 6, 2018

If a project dll name contains space, why will it cause 502 error? For example "my web api.dll" (assembly name in VS) causes the error but "mywebapi.dll" works perfect. I spent millions seconds to figure out a workaround to fix the error. In VS, a dll name with space runs ok but as soon as it is published, it won't work with "HTTP Error 502.5 - Process Failure".

Azure documents may have the naming convention such as "do not have space in assembly name" i don't know.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.