This repository was archived by the owner on Apr 8, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 8, 2020. It is now read-only.
WinHttpException: The connection with the server was terminated abnormally #128
Description
This happens on an Angular app in both Win8.1 and Win10. The problem is intermittent and we haven't figured out how to reproduce it but it happens quite often. Here's the error page:
An unhandled exception occurred while processing the request.
WinHttpException: The connection with the server was terminated abnormally
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
HttpRequestException: An error occurred while sending the request.
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
Stack Query Cookies Headers
WinHttpException: The connection with the server was terminated abnormally
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
System.Net.Http.WinHttpHandler.<StartRequest>d__102.MoveNext()
Show raw exception details
HttpRequestException: An error occurred while sending the request.
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
Microsoft.AspNetCore.NodeServices.HttpNodeInstance.<Invoke>d__7`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
Microsoft.AspNetCore.SpaServices.Prerendering.PrerenderTagHelper.<ProcessAsync>d__23.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Razor.Runtime.TagHelpers.TagHelperRunner.<RunAsync>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
System.Runtime.CompilerServices.TaskAwaiter.GetResult()
Asp._Views_Home_Index_cshtml.<ExecuteAsync>d__24.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Mvc.Razor.RazorView.<RenderPageAsync>d__14.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Mvc.Razor.RazorView.<RenderAsync>d__13.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Mvc.ViewFeatures.ViewExecutor.<ExecuteAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Mvc.ViewResult.<ExecuteResultAsync>d__26.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Mvc.Internal.FilterActionInvoker.<InvokeResultAsync>d__44.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Mvc.Internal.FilterActionInvoker.<InvokeResultFilterAsync>d__43.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
Microsoft.AspNetCore.Mvc.Internal.FilterActionInvoker.<InvokeAllResultFiltersAsync>d__42.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Mvc.Internal.FilterActionInvoker.<InvokeResourceFilterAsync>d__37.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
Microsoft.AspNetCore.Mvc.Internal.FilterActionInvoker.<InvokeAsync>d__32.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Mvc.Internal.MvcRouteHandler.<InvokeActionAsync>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Builder.RouterMiddleware.<Invoke>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Builder.Extensions.MapMiddleware.<Invoke>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
System.Runtime.CompilerServices.TaskAwaiter.GetResult()
Microsoft.AspNetCore.SpaServices.Webpack.ConditionalProxyMiddleware.<Invoke>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.<Invoke>d__7.MoveNext()
Show raw exception details
Activity
SteveSandersonMS commentedon Jun 14, 2016
Thanks for reporting this. I haven't personally been able to repro it, so if you are able to provide any repro steps (even if the repro is still intermittent) that would be great.
My best guess is that it looks like this issue: https://github.com/dotnet/corefx/issues/4934
That would be consistent with the error message and stack trace you've posted, and with its intermittent nature. If this is the case, then the problem should get fixed with a Windows 10 update, but there's nothing that .NET or NodeServices can do about it in the meantime.
The good news is that this problem should no longer matter once we change NodeService's default transport from
HttpNodeInstancetoSocketNodeInstance, because that will remove HTTP from the scenario altogether.To try this out now:
Make sure you have the latest version of the
Microsoft.AspNetCore.NodeServicespackage - version1.0.0-beta-000004Add the following to the
ConfigureServicesmethod in yourStartup.csfile:(you'll probably also need to add
using Microsoft.AspNetCore.NodeServices;at the top of the file)Does this issue go away if you do that?
If the error still occurs, please post the updated stack trace, as it will certainly at least be different with this change.
ManuelDeLeon commentedon Jun 14, 2016
It works when I run
dotnet runbut when I run it from Visual Studio 2015 I get:ManuelDeLeon commentedon Jun 14, 2016
Repro for first issue: https://drive.google.com/file/d/0B0xPA49vdefIMk9hUk1FZHFJRjg/view?usp=sharing (it's basically the default Angular 2 app plus karma)
To repro the second one just add
Microsoft.AspNetCore.NodeServicesand updateStartup.cs(as instructed).ManuelDeLeon commentedon Jun 15, 2016
I just got the same
NodeInvocationException: There can be only one platform.error while usingdotnet run=(SteveSandersonMS commentedon Jun 21, 2016
Thanks for posting the repro project. I tried it, and I'm afraid it didn't repro in my environment. I ran it both via
dotnet new, and from VS, with both theSocketandHttphosting models, and refreshed in the browser many times, and it never once produced any of the errors you've listed.As for the intermittent failures (both the
WinHttpExceptionerrors if you're usingHttphosting, and the "socket was broken" errors if you're usingSockethosting), I have a pretty strong suspicion of what's going on. I think you probably have something running in the background on your machine that writes to files in theClientAppfolder, which would causeNodeService's instance ofnode.exeto shut down and restart. If that happens while we're in the middle of server-side rendering, the resulting error will be a failed HTTP request (inHttphosting) or a disconnected socket (inSockethosting), which exactly corresponds to what you've reported. The sort of things that might write to theClientAppfolder could be:Please try this:
You can disable NodeService's file watching by amending the code you added to
Startup.csas follows:Now
NodeServiceswon't restart thenode.exeinstances when the contents ofClientAppchange. Does that stop the intermittent failures?Of course, now, after you've made a change, it won't show up in the server-side rendering results until you restart the app entirely. So this is not really what you want, but at least it helps to diagnose what causes the failures.
If this change does fix it, then the good news is that the intermittent failures will not happen in production. They are just an artifact of how you have set up your dev machine. So you can either disable whatever is running in the background (VS add in, test runner, or whatever), or you can keep it running and just reload the page whenever it triggers a request failure.
That's completely different - that's is an error message coming back from Angular. Please review anything you've put in your Angular startup file (e.g.,
boot-server.ts) and check it against Angular docs. If you continue to get this and think it's a bug in the JavaScriptServices templates, can you file that as a separate issue with repro instructions based on thegenerator-aspnetcore-spaAngular 2 template?SteveSandersonMS commentedon Jun 22, 2016
Update: I figured out how to reproduce this error. It is a problem in the templates. I'll find a fix.
SteveSandersonMS commentedon Jun 22, 2016
The
There can be only one platformerror was because ourboot-server.tswas trying to create a new bootloader - and then dispose it - on each request. If you had two requests at once, then it was possible for there to be two bootloaders active at once, which led to the error. The fixed code retains a bootloader instance for the lifetime of your app, which is how it's meant to work.generator-aspnetcore-spaversion 0.1.9 is now published and contains this fix.The original issue, however, remains open. I'm waiting for feedback on whether disabling the file watcher resolves the intermittent failures. @ManuelDeLeon, please let me know when you have a chance to try it.
ManuelDeLeon commentedon Jun 23, 2016
Adding
WatchFileExtensions = new string[] { }seems to get rid of the pipe broken messages. I have to test with an empty project to see if I get them there (traveling so don't have a lot of time at the moment).Upgrading to 0.1.9 seems to get rid of
There can be only one platformTheoretically, some unrelated Windows software (anti-virus or whatever)I need to test for that.
ManuelDeLeon commentedon Jun 23, 2016
I'm still trying to figure this one out. I set up a file watcher, started the server and got the pipe broken error plus:
I restarted the server and got the same pipe broken message and the following:
The file watcher reported a whole bunch of files changed in the node_modules folder:
I'll probably have to setup some kind of security auditing to see which process is modifying the files.
antmdvs commentedon Jun 23, 2016
You could try https://technet.microsoft.com/en-us/sysinternals/processmonitor
ManuelDeLeon commentedon Jun 25, 2016
It took me a while to get a good log since it doesn't happen always. I created a new Angular 2 project and added
services.AddNodeServices(new NodeServicesOptions { HostingModel = NodeHostingModel.Socket });to the Startup.cs file. I then basically restarted the server and refreshed the web page every now and then until I got:Here's the Process Monitor log file:
ProcessMonitor_Log.xlsx
Only
dotnet.exeandnode.exetouch the files.1 remaining item
gdyrrahitis commentedon Jun 29, 2016
Same issue here. Installed
aspnetcore-spatemplate for Angular2, getting this error:antmdvs commentedon Jun 30, 2016
gdyrrahitis commentedon Jun 30, 2016
System details:
Windows 10, 64-bit OS
Node version: 4.4.5
Visual Studio 2015, Update 3.
No full disk encryption, online backup or endpoint security software.
I've been able to reproduce the error for my case.
Steps:
aspnetcore-spagenerator in directory@Componentdecorator:styles: [require("./home.css")]. This will result in a 404, because home.css does not exist (nor there is a way to get that given that path even if it existed with current configuration)So it seems that 404 causes the problem.
As @SteveSandersonMS stated, probably it is related with this issue: dotnet/corefx#4934
The following is the error I get when updating the app while running.
SteveSandersonMS commentedon Jun 30, 2016
@gdyrrahitis:
Thanks for your repro steps. Do you definitely get the
WinHttpExceptionjust from taking those steps alone? When I tried, your steps do lead to a fault, but the fault I see is that on step 6, instead of getting any error, the request just hangs indefinitely. Eventually you getA task was cancelledwhen the request times out about 100 seconds later.As far as I can tell, you'd only get the
WinHttpExceptionif you also do something else to terminate the Node instance, such as killing it on the command line, or modifying a.js/.tsfile so that it restarts. Can you clarify your repro steps, then? Do you definitely get aWinHttpExceptionerror purely from doing those steps and nothing else?As for the requests hanging if Webpack compilation fails, this is now fixed. Please update your copy of
aspnet-webpackto 1.0.4+ and let me know if you still find any unexpected behaviour.More generally:
Most people on this thread are probably aware, but the
WinHttpExceptionis not really the underlying cause of any error, but rather is just the generic way that .NET finds out that the Node instance is gone while it was waiting for a response from it. The reason the Node instance is gone could be all kinds of things. I'm working to try to make sure that either this never happens, or if it's unavoidable due to an error in your application code, that the error we report into .NET specifies something more useful about the underlying cause, and not justWinHttpExceptionwhich doesn't really provide much insight.ManuelDeLeon commentedon Jun 30, 2016
@SteveSandersonMS
What about
Pipe is broken? (#128 (comment) & #128 (comment))SteveSandersonMS commentedon Jun 30, 2016
That's the
Sockettransport equivalent for the same generic error (the Node instance is gone while .NET was waiting for it). It doesn't indicate what actually caused this to happen. Various people have reported getting this message, but often there will be different underlying causes. As per my comment before, I'm trying to find ways of surfacing the underlying cause rather than this generic message.Right now, I'm aware of the following:
.js/.ts/.json/etc. files is written, it can happen if you (or one of your VS extensions, or some other process on your machine) modify the file while an RPC call is in flight. That's most likely a dev-time-only (not prod) issue. I'm going to look into ways to make the Node restart mechanism more graceful so that in-flight RPC calls are given time to complete. Hopefully this will fix the cases where people report the error as "intermittent".SteveSandersonMS commentedon Jun 30, 2016
@ManuelDeLeon Also, thanks for posting that process monitor log. Unfortunately it doesn't pinpoint a cause, because your console output says that the modified file was
aspnet-prerendering\package.json, but I can't see any way that NodeServices would ever write to that file, or any otherpackage.jsonfile.The spreadsheet you gave shows only two incidents of that file being accessed, and both times it was just being read (not written) by
node.exe. So, I wonder if the process monitor log really includes everything - perhaps there are other processes running (e.g., system processes, not in your user account) that are modifying files.Also, your spreadsheet shows that the last write time for
aspnet-prerendering\package.jsonat 7:59:11AM on 6/23/2016, whereas it appears you were running your app at about 2:59PM on 6/24/2016. So it definitely does not appear that process monitor has seen whatever wrote to that file.Maybe it's possible that nothing is actually writing to that file, and maybe Node's
fs.watchAPI might just be broken and giving false positives. Someone reported false positives on Windows 7 in a VM here: nodejs/node-v0.x-archive#2839, but they never tracked it down and they closed the issue. If it does turn out thatfs.watchhas fundamental problems, then we can consider moving the file-watching logic into the .NET side and having it notify Node when it needs to restart.gdyrrahitis commentedon Jun 30, 2016
@SteveSandersonMS Thanks for the response. Yes, by purely following these steps I can get that error. So if I try to re-run the application (Run with Debugging or without from VS 2015) will get the
WinHttpException.Originally what I did was first time to run the
aspnetcore-spagenerator and test drive the project, check the code etc. I was playing around with the Angular2 Components, and I added a new non-existent style. After that closed my PC without looking what is wrong. Next day tried to run the application and got theWinHttpException. After some time thinking why is this happening, I realized that this change might be the cause, so I tried these steps which lead to this error. If I remove therequirecall to the non-existed style the application runs just fine.Haven't tried any other options/repro steps yet, nor searched more on the issue, will probably look in the upcoming days and come up if something needs to be reported (will give a try to update the
aspnet-webpackand will let you know). CheersSteveSandersonMS commentedon Jul 1, 2016
That's strange - I don't know why that would happen, and I can't repro it. Invoking "Run [with debugging]" from VS doesn't cause such an issue on my machine. Is it possible you have some VS extension installed that writes files when you invoke "run"? Maybe something that tries to compile TypeScript or run Webpack?
What happens once you've updated to the latest
aspnet-webpackpackage and do the same?Toxicable commentedon Jul 3, 2016
So I just had this issue and noticed it happened when I change main: './App/main.ts' to app: './App/main.ts' in webpack.config.js in the angular 2 template project, this dosn't line up with what you guys are describing but it might be a possible reason for it happening
Move file-watching logic into .NET to avoid Node's fs.watch issues on…
SteveSandersonMS commentedon Jul 7, 2016
Based on all the comments here, I've completely rewritten how the Node instance lifetimes are managed, how processes are restarted, and how file changes are watched for:
fs.watch.Hopefully, the combination of these two enhancements will avoid the Node processes getting killed prematurely (if an RPC call is still in flight) or unexpectedly (if
fs.watchreports false positives on Windows 7 VMs), and hence minimise aborted HTTP requests (which causeWinHttpException) inHttphosting, or "socket is broken" situations inSockethosting. Also I've done a bunch of other work to catch possible errors in extra places (e.g., during webpack compilation) and ensuring they are correctly routed back to .NET rather than leading to timeouts or uselessWinHttpExceptionerrors.To get the update:
Upgrade to
1.0.0-beta-000007or later of whichever JavaScriptServices NuGet packages you're using (that includesMicrosoft.AspNetCore.NodeServices,Microsoft.AspNetCore.SpaServices,Microsoft.AspNetCore.AngularServices,Microsoft.AspNetCore.ReactServices). You don't need to create a new project - it's enough to update to the latest packages in your existing projects.Note that a lot of low-level stuff has changed, so consider beta-000007 to be very much a "preview", so if you hit trouble please downgrade to
beta-000006and post a new issue describing what was broken.About this thread:
This is a long thread, and basically all of it is now obsolete, because so much has now changed. If you're just arriving here, please disregard all the comments above as they probably don't apply in your situation.
To minimise confusion, I'll close this issue now. For any further connection troubles now, please post a new issue describing the problem and how to reproduce it. Any similarity with events or error messages described above is purely coincidental :)
SteveSandersonMS commentedon Jul 7, 2016
@antmdvs Hope you don't mind that I removed your comment. Trying to keep the last item in this thread the one I posted above, to avoid confusion. As per above, please file a new issue if there's still a problem after you update.