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 have not been using Azure Machine Learning service (preview) for too long. To my knowledge it only has been released since the last Microsoft Ignite conference. That's why I think I can not find my question on StackOverflow or any other forum for that matter.
It is as follows:
With help of the Azure Machine Learning service SDK in Python I created my experiment in a Jupyter Notebook locally.
I then configured it to run a Hyper Drive config,
The results came in one by one (as I had a total of 50 runs and 4 simultaneously). It took 7 hours to complete the Hyper Drive run in total.
The next day I went to portal.azure.com to view the results and that worked. I was able to see every run of the hyperdrive and could even compare results.
But then....
I have no clue to as what could have happened, but when I tried to navigate to the experiment again I got a blank white screen. When opening the dev console via F12 I got so see a lot of red errors. All from react. I have zero experience with react, but I am quiet sure that this is the error. React errors when viewing experiment
Hope someone can help. Thanks in advance.
Thanks for reporting this! It's a known issue and a fix is being rolled out.
When clicking on a table and then selecting 'Query tool' results in an error.
I also couldn't find the log folder of pgAdmin.
It doesn't matter where I open the editor it always shows this editor.
I have re-installed multiple times, version: 10.4 and 9.6.9 search on stackoverflow for a lot of different solutions like resetting the layout or changing the local ip from 127.0.0.1 to localhost.
My teacher also never saw this before, so he couldn't help me either.
If anyone has had this problem before I would really know what the solution is. Apart from re-installing windows.
EDIT:
I have re-installed windows... And stept away from pgAdmin now. I use another tool (HeidiSQL).
This problem has plagued me for months. Finally, I stumbled across a fix that worked for me. I hope it helps you.
In the Internet Explorer browser that is running pgAdmin4 I turned off SmartScreen Filter under Settings -> Safety, and this instantly fixed the problem.
I've been working on a small Google App Engine (standard environment) project that uses Cloud Endpoints v2. My code is largely based on the quickstart provided by Google.
Everything was working fine, but I re-deployed today after having not looked at it for a few weeks, and I'm getting the following error when I attempt to call the endpoint:
error: An error occured while connecting to the server: DNS lookup failed for URL: metadata.google.internal
This wasn't happening before. It seems to be happening when the endpoints package is being imported by Python.
My endpoint doesn't do anything fancy - I haven't changed the source from the sample EchoApi. The error ends up in the GCP Logging console no matter if I try to access the API through the API Explorer or via Curl.
I don't get any errors during deployment.
Edit #1
Some further information:
The error originates from within Google's code that is included with the google-endpoints package which I've included in my lib folder, per
the documentation. Specifically, the error occurs on line 54 of google/api/control/wsgi.py.
Basically, it's making a request to metadata.google.internal using urllib2.
I'm guessing this address is only available from within the Google Cloud, and that for whatever reason, the instance that's hosting my app can't do a DNS lookup on it.
Edit: #2
Dug a bit further.
It seems that the error originates in the google-endpoints-api-management package. Changes committed to that package on October 19th seem to have introduced additional platform reporting. metadata.google.internal is queried to check if the code is running within the Google Container Engine, then it blows up, because the metadata address doesn't resolve.
Here's the commit:
https://github.com/cloudendpoints/endpoints-management-python/commit/0a37d0e443091053ed03e455e06d3a0ae770999f
The google-endpoints package only requires google-endpoints-api-management >=1.0.0b1. On my end, things were working fine on version 1.0.0b2, but then I built a new lib folder, which brought down 1.0.0b5, and things went sideways. Required packages haven't changed between b2 and b5, so I'm thinking I may be able to just downgrade back to b2 for the time being. Haven't tried it yet.
Sent the Google Dev an email. Perhaps he'll chime in with further tips.
Edit: 2016-11-07
Tested downgrading the google-endpoints-api-management package to 1.0.0b2. Seems to be working, kludgy a fix as it is. If you're using the lib folder, the following will scrub the newer error-prone wsgi.py file and put back the older one:
pip install -t lib google-endpoints-api-management==1.0.0b2 --upgrade
Not pretty, but it may just get you back in business.
On a side note, the Google engineer promptly replied saying that he would take a look at this issue soon. With luck, endpoints v2 will eventually come out of beta, 'cause I'm really liking it so far.
This will be fixed in an upcoming patch to the google-endpoints-api-management package (which will be 1.0.0b6). It will probably be released sometime on Monday, 11/6.
If you'd like to continue testing right away and this error is blocking you, you can go back to 1.0.0b4 until 1.0.0b6 comes out. Everything should still work as normal with that version.
Thanks for bringing this to our attention! We're doing our best to iron out all of these wrinkles now during beta in preparation for our first general release.
EDIT: 1.0.0b6 has been released and resolves this issue. Thanks for your patience during our beta phase!
(Posted solution on behalf of the OP).
Google has released version 1.0.0b6 of the google-endpoints-api-management package to address this issue. It solved the problem for me. For anyone who is encountering this problem, clean out your lib folder and re-install the google-endpoints package. This will bring down the new google-endpoints-api-management package with it.
Thanks to Brad at Google for really quick action on this.
I had a Drupal website in drupal 6.x When i wanted to upgrade it to 7.x, the custom theme i was using was absolutely outdated, so i imported my Zen subtheme from another website. For doing that, i just copied the folders "zen" and "mytheme" from the other installation to this one. Then i selected "mytheme" as the current theme and changed some little things to adapt it.
The fact is now i'm experiencing the following problems:
I can't auto-update nothing. It downloads the files but then it stacks (and leaves the site in Maintenance Mode).
I can't run update.php. I can go on until i reach the "Run updates" step, which shows a blank screen. This is the main issue, i think, as it evidences -in my oppinion- a problem of communication between the site and the database.
In the Webform module i can't select "File" as a Field Type. This one is not that important, but it may be relevant for someone who knows more than me.
Edit:
Recently i migrated from a Shared to a VPS server. When i migrated, the subdomain in which i was experiencing the issue threw an incompatibility related to the lenght of the password of the database. I changed the password and it started to work again. This may help somebody for helping me. Thanks!