Failed to load resource ERR_CACHE_READ_FAILURE

[paul6850]

Hello,

I sometimes (not reproducible) get a half loaded page. Looking at the devtools console I get the following message: Failed to load resource: net::ERR_CACHE_READ_FAILURE

I did some searching, and found this to be happening with other chrome/chromium systems also. Advise was to set the enable-simple-cache-backend to true. Can I do this in webview2?

Another interesting option / workaround I read could be found on the essential objects, in there webviewEO product:

void webViewEO_ConsoleMessage(object sender, ConsoleMessageEventArgs e){ if (e.Type == ConsoleMessageType.Network && e.Message.Contains("ERR_CACHE_READ_FAILURE")) { this.webViewEO.StopLoad(); this.webViewEO.Reload(true); //force reload cache } }

Does webview2 has something similar: an event for looking at the console messages, so I could load the page again?

Finally, why does this happen?

Thanks Paul

AB#41945464

[LiangTheDev]

I believe that enable-simple-cache-backend is not available any more, for Chromium based browsers and WebView2.

For the workaround, you can use CDP to exam the console logs, something like

 webView2->CallDevToolsProtocolMethod(L"Log.enable", L"{}", nullptr);
 webView2->GetDevToolsProtocolEventReceiver(L"Log.entryAdded", &receiver);
 receiver->add_DevToolsProtocolEventReceived(callback);

and example the log entry in callback. See https://chromedevtools.github.io/devtools-protocol/tot/Log/#event-entryAdded for more info about CDP entryAdded event.

In the future, WebView2 should provide better error status for navigation complete, and then it would be easy for the apps to detect cache problems and do a reload.

[Yannouu]

Hello you can do something like that (minified version) :

this.w2WebView.CoreWebView2.CallDevToolsProtocolMethodAsync("Network.enable", "{}");
this.w2WebView.CoreWebView2.GetDevToolsProtocolEventReceiver("Network.loadingFailed").DevToolsProtocolEventReceived += NetworkFailed;                

private void NetworkFailed(object sender, CoreWebView2DevToolsProtocolEventReceivedEventArgs e)
{            
        if (e.ParameterObjectAsJson.ToLower().Contains("err_cache_read_failure"))
        {
            this.w2WebView.CoreWebView2.CallDevToolsProtocolMethodAsync("Network.clearBrowserCache", "{}").ContinueWith(t1 =>  
                {
                    this.w2WebView.Dispatcher.Invoke(() =>
                    {
                        this.w2WebView.CoreWebView2.Reload();
                    });
                });       
        }

    }
}

But beware, NetworkFailed may trigger multiple time.

[paul6850]

Thanks,

Could I use something like this (in vb):

  Private datLastNetworkFailedRefreshed As Date
  Private Async Sub NetworkFailed(ByVal sender As Object, ByVal e As CoreWebView2DevToolsProtocolEventReceivedEventArgs)
      If mEdge.CoreWebView2 IsNot Nothing Then
          If e.ParameterObjectAsJson.ToLower().Contains("err_cache_read_failure") Then
              If datLastNetworkFailedRefreshed = Nothing OrElse datLastNetworkFailedRefreshed.AddSeconds(5) < Now Then
                  datLastNetworkFailedRefreshed = Now 

                  Await mEdge.CoreWebView2.CallDevToolsProtocolMethodAsync("Network.clearBrowserCache", "{}")
                  mEdge.Reload()
              End If
          End If
      End If
  End Sub

Where the datLastNetworkFailedRefreshed should prevent it from continually triggering it. I cannot get the dispatcher as option in my webview2, so should the await/reload option above work?

It is difficult to test this, being unable to simulate the problem. So I rather be sure..

Thanks Paul

[hisenberg1]

This is a general issue that occurs on both Chrome and Edge. I know many people that have this issue. One theory is that AntiVirus software is cleaning out the cache without the browser's awareness. I'm not buying that theory because this doesn't sound like a new issue. It is hard to reproduce because a simple reload of the page resolves the issue. However, this happens too often to be ignore.

[stewartbeck]

We are also tracking this issue, and see it sporadically across our user base. For some users it seems to occur more frequently and some never receive this at all. We have not been able to isolate a common factor among users who experience this. It does cause major disruptions, and coding in problem detection and auto reloads can be problematic - as the user just sees a flash reload and doesn't understand the reason why.

WorkWebView2.LogReceiver_DevToolsProtocolEventReceived : <form> {"entry":{"level":"error","networkRequestId":"3504.2","source":"network","text":"Failed to load resource: net::ERR_CACHE_READ_FAILURE","timestamp":1.655132949858346e+12,"url":""}

These always put the component in a state that is non recoverable without a full refresh.

[erik-anderson]

Ideally we'd get a netlog of a repro to get a bit more context, but I understand with the unpredictability that may be difficult.

I see the note that there isn't an isolated, common factor among users who experience this. Are the hits truly one-offs for users or do some users encounter it more frequently?

If some users encounter it more frequently, do you have a way of checking with them on if they frequently turn off their computers without a regular shutdown? The only current theory is that there's on-disk corruption, perhaps due to files not getting flushed properly, but we really don't have a lot of info to go on right now.

[stewartbeck]

Hard to say for certain. I have definitely seen instances in our logs where this occurs after long periods of inactivity, which could very well be laptops getting closed, or someone commuting, or even going home for the evening and starting again the next day.

We occasionally get api calls for a resource with a cache life (translation strings), where the client logs will indicate that a server call was made but that the server returned a status code of 0. I was theorizing that this was another type of cache read failure as we never see those calls make it to our server - and 0 is a nonsense code for a server response.

[stewartbeck]

We are seeing a correlation in these events with their first event of the day. We're looking to solidify this, as well as trying to ask the users directly what methods they use to shut down. Hopefully we'll have stronger data by the end of the week.

[bommas12]

We are facing the same issue. We are trying to load a com addin in Excel which is causing the issue.

Although I tried to clear cache from %LOCALAPPDATA%/Microsoft/Office/16.0/Wef

We observed the webview2 not being deleted when the cache is cleared(probably due to the webview2 instance running). Closing all the office applications and clearing cache deleted the webview2 folder.

[champnic]

Ideally a netlog would be captured to help identify what's going wrong here: https://textslashplain.com/2020/01/17/capture-network-logs-from-edge-and-chrome/

Without that and without a repro, it's difficult to investigate this further.

As a workaround, if you are able to detect these failures, you may be able to have you app clear the cache and then retry using the ClearBrowsingData API (either deleting all data, or specifically the CoreWebView2BrowsingDataKinds.DiskCache data). CoreWebView2BrowsingDataKinds.DiskCache

[ahafnr]

We also had this problem, in our case it was an Outlook Addin that would generate the cache miss. Here's what we found out.

The addin cache data directory was located somewhere underneath the %temp% path. I guess the path to this location is under the control of the addin developer. Now there's a standard Microsoft planned task (Microsoft/Windows/DiskCleanup/SilentCleanup) deleting files from this directory. So in the cache lookup table ("index") there's the information that a certain cache file exists, while this file actually doesn't exist any more.

The solution would be to change the path to somewhere else where the data is left alone. If the developer is no longer available, a workaround might be to clean the complete cache dir (including index file) at every user logon. This helped for us.

[valentinstt]

I had the same issue happening to me with my company laptop. Tried to empty cache and it was better but after a few days the problem came back. Also deleted all my browser extensions but I didn't changed anything.

My last try was to go the cache folder of Edge C:\Users[username]\AppData\Local\Microsoft\Edge\User Data\Default\Cache and delete everything there. There was some Edge processes that were still running in the background even with Edge being closed so I had to kill these processes to be able to delete all Cache files.

I've seen that this issue might be linked to these few cached files that are not deleted when you clear the cache from browser's settings.

For the moment I don't have this issue anymore, hope it'll not come back

[thephoton]

This happens in our app as well - we're storing the profile folder in the user's temp directory. Win 10 22H2.

I haven't been able to figure out a cause, but you can definitely reproduce it by deleting files from EBWebView/Default/Cache/Cache_Data while the app is running, the reload the webview.

Workaround by @Yannouu does the trick for now however - just annoying for users!

[LiangTheDev]

If WebView2's user data folder is under temp folder, when Windows decides to clean up temp files and delete some cache files, it would definitely not an expected scenario for Edge/Chromium code.

[danantal]

We are also having this issue in our office add-ins. We also store the WebView2 profile in a temp folder - and we've seen this problem frequently. Would be nice if we can get a proper solution without having to deal with reloads.

[champnic]

@danantal Can you move the user data folder to a non-temp location?

[danantal]

Technically we can - and we are rolling that change now - but it does take a significant amount of time until it this change propagates to all our customers since it's a change in the binaries not just a web app change.

We have an enterprise solution which involves the IT department for any change related to deployments of software on client machines - hence why we use WebView and a web based application that we can easily update without having to deal with that flow.

Also, the benefit of storing it in the temp folder is that we don't have to handle it when unininstalling the add-ins (that is handled by a different tool), as it will eventually be cleaned up.

Any reason why that is now a bad idea (besides the obvious issue at hand)? Do you consider this a bug or something we should just move away from? I consider this a work-around - at least to some extent.

[champnic]

The temp folder is designed to be temporary, and potentially get cleaned up by Windows, deleting your user data folder. You will lose info like cache, website storage, cookies, stored autofill info, etc. It's up to you to decide whether that's acceptable or not.

[dejudicibus]

As a user I have the same problem. I have usually to reload the page TWICE to avoid it. The first time the page reload the style, the second time all resources involved in styles. For example, images. If there are not resources in style (CSS), a single reload is enough. Once there was a Chrome setting option to avoid that. I would like to have it back. The browser should be enough smart to reload from server whatever is no more available from cache.