After upgrading to VS 16.10.0 (and then 16.10.1) Community Edition a React website no longer runs w/in Visual Studio/IIS Express. The exact same code was just deployed to an Azure app service and works correctly.
The home page is blank and the following error is displayed in the Chrome (Version 91.0.4472.77 (Official Build) (64-bit)) debugger console
"Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR"
The solution consists of:
C# class library (.NET Core 3.1)
C# Web API (.NET Core 3.1)
React website
I have tried the following:
Cleaned and rebuilt solution
Cleared browser cache
Uninstalled and re-installed Visual Studio
Upgraded Visual Studio from 16.10.0 to 16.10.1
Ran npm run build which ran with no errors
Additional Note: I was able to restore a virtual machine w/ Visual Studio 2019 v16.9.4 instead of v16.10.1. Then step by step I installed the latest Windows updates and the exact code base. The site runs correctly in v16.9.4. So the problem seems to be in Visual Studio v16.10.0/v16.10.1
Go to the VS Developer Community and up vote this problem
https://developercommunity.visualstudio.com/t/Failed-to-load-resource:-net::ERR_HTTP2_/1446262
This error was driving me nuts too. Windows 10 was updated 2 days ago and I also updated Visual Studio to version 16.10.1. After that, I got the errors, images, CSS not loading correctly.
As SpeedOfSpin mentioned in a comment in a previous post, uninstalling KB5003637 worked instantly for me, no more errors! Everything loads perfectly now.
It wasn't necessary to go back to an earlier version of Visual Studio, it seems it was Windows OS related.
#SpeedOfSpin: Thnx a lot! :)
UPDATE ON ISSUE 1
Today there was a new update KB5004476, I don't see the previous KB5003637 anymore here. KB5004476 is causing the same errors. When installed I get the exact same error "Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR", uninstalling solves it instantly again.
I have asked the Microsoft forum what is going on here:
https://answers.microsoft.com/en-us/windows/forum/windows_10-networking/kb5003637-and-the-new-kb5004476-gives-error-failed/db2f2f73-7f5c-477a-b212-5f13c998a09a
UPDATE ON ISSUE 2
As they couldn't provide a solution in the first MS forum (previous link), the same question has been asked here:
https://learn.microsoft.com/en-us/answers/questions/440339/kb5003637-and-the-new-kb5004476-gives-error-34fail.html
Updating Visual Studio to version 16.10.2. doesn't solve the issue either.
UPDATE ON ISSUE 3
After some more testing, it seems it affects the browser Chrome only (As I only use Chrome, as most people do). In Firefox, Edge, and IE it seems I'm not having this issue. It was confusing as I tried so many things and the only solution I still have is uninstalling the KB5003637 or the new version KB5004476. So I guess something is wrong with Chrome after all. For now, I will keep the updates uninstalled, I don't feel like changing my preferred browser.
UPDATE ON ISSUE 4
It is indeed not a Chrome-only issue, sorry guys. Saw the same error in Edge this morning too. It took a long while to recreate the problem, while in Chrome I have it every single time. :(
UPDATE ON ISSUE 5
As asked in the first post here by ChrisP, go to the VS Developer Community if you experience this issue too, and please upvote this problem.
I asked the question there also, but still no solid solution at this point.
https://developercommunity.visualstudio.com/t/Failed-to-load-resource:-net::ERR_HTTP2_/1446262
UPDATE ON ISSUE 6
Two days ago after 1 single refresh (F5), when testing my web application, aside from the HTTP/2 errors, I also had the same blue screen like people are starting to mention. It showed the error "System Thread Exception not Handled" in file "HTTP.sys" and restarted, amazing!
Also, 2 new updates were installed KB5003690 and KB5003537, but nothing changed, I still have the annoying errors. Previous updates KB5003637 and KB5004476, where it started to go wrong, are gone here.
Uninstalling these updates as a workaround isn't the best solution for me, as they get reinstalled when wanting to update Windows 10 (No option anymore to exclude/hide the updates).
For me the easiest/quickest workaround at this point, to test locally with no “Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR” errors, no "System Thread Exception not Handled" BSoD! error and most important no stress anymore :), is disabling SSL in the debug settings of your project in Visual Studio. (Right-click Project, Properties, Debug, Web Server Settings below).
Hope this gets fixed quickly!
UPDATE ON ISSUE 7 (SOLVED!)
Microsoft finally released a fix that works for me, more information here (last post):
https://developercommunity.visualstudio.com/t/Failed-to-load-resource:-net::ERR_HTTP2_/1446262?viewtype=all
Installing the most recent update KB5004237 solves the problem in my case. No more "Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR" errors, no more “System Thread Exception not Handled” error so far too!
I tried everything including rolling back updates and a full reinstall of Windows. Finally, a Microsoft support rep posted a workaround for this that involves disabling HTTP2. This seems to have worked for me as a temporary solution. In summary:
Start the Windows Registry Editor
Navigate to the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
Add 2 new REG_DWORD values, EnableHttp2Tls and EnableHttp2Cleartext,
to this registry key
Set both values to 0
Reboot the machine
The rep notes:
The registry values disable HTTP/2 on the machine. You can remove those values when the fix to https.sys is published.
We had the same issue on only the machines that had that KB5003637 installed. We uninstalled it and everything was fine. We decided to upgrade to .net 5 in the end which fixes the issue as it was fairly painless for our projects.
If you can't upgrade try disabling HTTP/2
serverOptions.ConfigureEndpointDefaults(lo => lo.Protocols = Microsoft.AspNetCore.Server.Kestrel.Core.HttpProtocols.Http1);
Mine looks like this for .net core 3.1
public static IHostBuilder CreateWebHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.ConfigureKestrel(serverOptions =>
{
serverOptions.Limits.MaxRequestBodySize = int.MaxValue;
serverOptions.Limits.MinResponseDataRate = null;
serverOptions.ConfigureEndpointDefaults(lo => lo.Protocols = Microsoft.AspNetCore.Server.Kestrel.Core.HttpProtocols.Http1);
})
.UseStartup<Startup>();
});
}
Disable the SSL from the project properties it will automatically down to http/1 and then enable the javascript debugger for the browser
Hope this will help
In my case it was ASP.NET Core Identity that caused the trouble: I had too many roles (user claims) which were stored as session cookies in my browser and caused a "HTTP 400 Bad Request - Request header too long" error. This was showing as HTTP2 protocol error in Chrome and SSL certificate error in Firefox since I was using HTTPS redirection.
In my case it was actually a HTTP Error 400 - The size of the request headers is too long, but I kept getting this ERR_HTTP2_PROTOCOL_ERROR message instead.
In order to find out the real error message, I had to disable HTTP/2 in IIS(right click your site in IIS, open Edit Bindings, double click your HTTPS binding and check Disable HTTP/2).
After fixing the HTTP Error 400 I could enable HTTP/2 again and it worked correctly.
I found that disabling SSL (which I think results in IIS Express dropping down to HTTP 1.1) is a workaround.
this issue (on iis express) on only the OS that had that KB5003637 installed.
if you unable delete this update first upgrate windows 10 to last by
https://www.microsoft.com/en-ca/software-download/windows10
then you can delete kb5003637
(don't forget disable windows auto update)
I got this error creating a new blazor app vs2019/windows10 update to latest versions.
After looking at a prior working blazor project Startup.cs I fixed by commenting out //app.UseHttpsRedirection();
I think this maybe a new project template problem
In my case, upgrading the project to .Net core 5.0 (as #SpeedofSpin suggested) did not help - I had the same issue.
Disabling SSL (as #samejeep suggested) for application was demanding, because my projects uses IdentityServer4 and it just stopped authenticating after that - so I didn't continue that path.
But as a workaround I have changed all requests for css, js, and static files via non-SSL http:// requests.
So for example, instead of this
<link rel="stylesheet" href="~/css/site.css">
Which would use the current request's protocol https://, I've used absolute paths, e.g.:
<link rel="stylesheet" href="http://localhost/css/site.css">
Note, that I'm stating "http" (not "https") explicitly.
I did that for css styles and js scripts and that was enough for me.
I didn't have to do it for images though.
For me this is just a dirty workaround (I'll be waiting for MS to release a patch), but at least it allows me to keep doing my work.
Update:
I've found a better way to disable HTTP/2 via registry on my localhost and that solves the problem too.
I've been working on a mixed desktop-and-web based solution for quite some time now. My local development environment was using VS2013-Pro, a recent DNN version (7.3, I think), Webmatrix 3, IIS Express 8.0, and SQL Server 2014 running on Windows 7 on Parallels on my Mac. Everything is up-to-date, all SP's installed, etc.
I developed a couple of REST webservices and a DNN module, and it's all been humming along and working really--shockingly--amazingly(!) well, when very suddenly:
I hit the DNN site and Webmatrix crashes and I get an error that says "IIS Worker process has stopped." And hasn't worked since. The debugger gives me the message "Unhandled exception at 0x762CC42D (KernelBase.dll) in iisexpress.exe: 0xE0434352 (parameters: 0x80131530, 0x00000000, 0x00000000, 0x00000000, 0x72F90000)."
I did not change anything, this started in the middle of a coding session. It worked fine for months, and then it just didn't any more.
I researched a bit and found several suggestions, none worked (delete cache folder, uninstall/reinstall). I find another post that mentions that Webmatrix is a dead product now. I try just to set up same site in IIS (following DNN's own instructions and a couple of other very similar sets I found). Still can't make site load--even the front page.
I download a fresh DNN install package (7.4 now) and try from scratch. Now when I try to load the site I get Visual Studio's Just In Time Debugger telling me an unhandled Win32 exception in w3wp.exe [2648]. I try running the debugger but it doesn't actually give any information.
I feel like other than the Webmatrix/DNN installation I've always had a lot of trouble getting DNN running locally, even following the directions to the letter. I need it running locally because I work disconnected a lot.
Am I missing something big here? Is anyone else having trouble all of a sudden? I've spent the better part of 4 days unistalling, reinstalling, tinkering, and can come up with nothing.
-Tim
OK, so after uninstalling everything (down to the metal, everything to do with SQL server, IIS, Webmatrix, and the recent .net framework updates) and then reinstalling them, I've been up and running for a week or so now. I've disabled Windows update, I think it was something in there that got me in this position in the first place. Not a great long-term solution, but it'll do for now.
Running Windows 10, Visual Studio Community 2015, and SQL Server 2014 Express. I also have .Net 3.5, 4.0, 4.5 installed.
My SqlDataConnection is throwing the compile time error "The type provider 'Microsoft.FSharp...' ... Error reading schema. The .NET SDK 4.0 or 4.5 tools could not be found". Searching for solutions I got directed to some registry keys.
In
HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows
I have two keys: \v8.0A and \v8.1A. (I didn't have a key for any v7.xxx) I got to these keys from one online answer to this issue. Each of those keys has three keys under it: WinSDK-NetFx...Tools. For v8.0A the ellipses are "35" and for v8.1A they are "40". Plus each key is repeated with + "-x64" and + "-x86".
These six keys all have string values of "InstallationFolder" (as well as "ComponentName" and "ProductVersion").
I go to the installation folders, and each one has ResGen.exe and SqlMetal.exe (which are the files other answers said to look for). So it seems like I have the requisite registry keys which point to the requisite exe's.
Next to the installation folders for v7.0A and v8.1A, I also have one for v10.0A. So I tried creating some additional registry keys named v10.0A. In those v10.0A keys I tried putting the v10.0A folder as the InstallationFolder and I also tried putting the v8.1A folder as the installationFolder. (One reason I tried this permutation is because the error message asks for SDK 4.0 or 4.5, whereas the v10.0A folder has NETFX 4.6 Tools. So I tried to resolve possible inconsistency between v4.5 and v4.6 by varying the registry keys under v10.0A and using the path to v4.5 in the v8.1A folder.)
I've probably gone on too long trying to give the pertinent info. But I have the most current software installed and updated, and I"m trying to follow previous solutions given. And I'm stuck. Maybe all the newest versions aren't yet gotten tied together with each other?
Any help appreciated much.
Edit: Doing some more web searching, I'm now finding more fixes with more details. This one in particular looks very promising:
Need clarification regarding Microsoft.FSharp.Data.TypeProviders
But I won't get to work on it until the end of today. So that link may be my answer, but I can't confirm for a bit.
Worth checking you are using the nuget version of the F# type providers. The version bundled with the framework does not have the fix applied that extends the list of registry keys searched to cope with later versions of the SDK (as would be installed on Windows 10)
https://github.com/fsprojects/FSharp.Data.TypeProviders/issues/21#issuecomment-337444919
I have created a simple console test application that works fine with Entity Framework 5 that connect a SqlServer DB.
Than, I tried to convert the project to work with Mono-3.0.10 by replacing the project reference from MS EF5 to Mono EF6, added a reference to mono EntityFramework.SqlServer.dll,
and updated the App.Config file to Entity Framework version 6.0.0.0.
I have managed to build the project with Visual Studio 2012 under Mono 3.0.10 profile without any errors.
Now, when I'm trying to run the project under Mono I get an exception:
System.Data.Entity.Core.ProviderIncompatibleException: The provider did not return a ProviderManifest instance ----> System.UriFormatException: Invalid Uri. The format of the Uri could not be determined: System.Data.Resources.SqlClient.SqlProviderServices.ProviderManifest.xml.
Can anyone help, or at least provide a code sample showing how you do it with Mono?
Thanks
I did the same thing and got the same error. My solution was to compile EntityFramework from the source (Codeplex, version 6.1.0alpha) and change a line of code in SqlProviderManifest.cs
private static XmlReader GetXmlResource(string resourceName)
{
//return XmlReader.Create(typeof(SqlProviderManifest).Assembly().GetManifestResourceStream(resourceName), null, resourceName);
return XmlReader.Create(typeof(SqlProviderManifest).Assembly().GetManifestResourceStream(resourceName), null, String.Empty);
}
Not nice, but solved my problem until I tried some really weird lamba query or tried to write something to the database.
I have been facing a nested exception issue for a while now, see below the log details as given. Tested with both Worklight 5.0.5.x and 5.0.6.x:
Failed deploying application to Worklight Server: The transaction has
been rolled back. See the nested exceptions for details on the errors
that occurred.; nested exception is
org.apache.openjpa.persistence.PersistenceException: The transaction
has been rolled back. See the nested exceptions for details on the
errors that occurred.
It works fine before adding an environment, but as soon as I add one (tested with the Android and iPhone environments), the error happens.
System:
Windows 7
Eclipse Juno
try closing Eclipse and deleting WorklightServerHome folder in your workspace.
In Worklight 5.0.6.1 the application's .wlapp filesize should no longer prevent the deployment process from succeeding. Please upgrade and check again.
If you are using MySQL as your database for Worklight, please follow these instruction: How to change max_allowed_packet size, in order to allow deployment to pass in MySQL.