.NET Core Web api call ERR_CONNECTION_RESET only on IIS - other calls working

Question

I'm now at a complete loss...

I have a .NET Core web app, and running locally everything is working. There's a number of WebAPI end points, again all working as intended with GET and returning JSON correctly.

When I publish to IIS, one, and only one of these end points stop working and throw (failed) net:ERR_CONNECTION_RESET (in Chrome - other browsers throw their own errors).

What is peculiar is that all the other Web API calls are working, all in the same environment and calling the same database, using the same context and EF data service.

What I can't figure out, is how to get detailed logs from Kestrel into some other logging services, either Windows Event Viewer, a text file, emails or anything else! I've not used much of the logging middleware, with the intention to hook that up as we get closer to production.

What's the best way to try and troubleshoot this in IIS 8 on Windows 2012 R2 with the .NET core Kestrel web server?

Solution 1

Just edit your web.config and set stdoutLogEnabled="true"to true, as well as set the path where the logfile will be written to.

<?xml version="1.0" encoding="utf-8"?>
<configuration>

  <!--
    Configure your application settings in appsettings.json. Learn more at http://go.microsoft.com/fwlink/?LinkId=786380
  -->

  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/>
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false"/>
  </system.webServer>
</configuration>

But you need to enable at least the console logger, as it basically dumbs the console output to a file.

public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
    loggerFactory.AddConsole(Configuration.GetSection("Logging"));
    loggerFactory.AddDebug();
    ...
}

The "Logging" section is configured in appsettings.json, such as

  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Debug",
      "System": "Information",
      "Microsoft": "Information"
    }
  }

Solution 2

I had a similar problem. I am using Entity Framework Core 1.1, which does not allow Lazy Loading. My error was caused from an object graph loop in a many-to-many relationship.

As EFCore 1.1 does not support many-to-many out of the box, my models had looping references. My JSON Serializer became stuck in an infinite loop as it attempted to serialize the data returned from my controller class.

If you have this problem and none of the other solutions work, I suggest changing your Startup.cs file ConfigureServices() method. The line services.AddMvc(); should be changed to this:

services.AddMvc()
    .AddJsonOptions(options => options.SerializerSettings.ReferenceLoopHandling = Newtonsoft.Json.ReferenceLoopHandling.Ignore);

Solution 3

You can log Kestrel with the build-in logging middleware. Make sure logging is enabled in web.config via stdoutLogEnabled like so:

<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false">

And your startup.cs contains the the following code:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    loggerFactory.AddConsole(LogLevel.Trace);
}

Comments

[RemarkLima]

And the .\logs\stdout path is the root directory then logs\stdout? And this logs all the errors?

[Tseng]

Yea, depends on what you configure in AddConsole. Also you can use AddDebug which will logs the stuff into Visual Studio's Output Tab (during debugging only of course, means when the debugger is attached)

[Ross]

@RemarlLima - see my answer, loggerFactory.AddConsole(LogLevel.Trace); will show you ALL logged messages from Kestrel not just errors

[Tseng]

With the IConfiguration override you can filter it and disable messages from namespaces you are not interested into

[NickG]

If this answer actually fixes it for you, check the method causing the problem is returning the correct type of object (eg a simple DTO of some sort and not DbSet itself!).