Issue 714187  has been merged into this issue.

Actually, scratch what I said about only four workstations exhibiting the issue. More PCs are affected, but not all of them. I'm not aware of any correlation between configuration / driver versions and the issue. 

Here are the hardware specs for the other machines: 
- OptiPlex 7040 Micro Form Facto r XCTO
- Windows 10 Pro (64bit) English
- Intel Core i5-6600T (QC/6MB/4T /2.7GHz/35W)
- M.2 256GB PCIe NVMe Class 40 Solid State Drive
- 370-ACHS : 8GB (1x8G) 2133MHz DDR4 Memory

josephluhn@, I am having trouble reproducing it. For any workstation affected, could you pls check whether updating to Chrome version 58 solve the problem?

Just trying to think what could be causing this on some machines, but not others. The behavior for loading a PDF should be consistent across machines. Looking at the code paths that can trigger this error dialog, one possibility is something is modifying the data that gets fed into the PDF plugin, such that the PDF plugin decides the PDF being loaded is invalid in some way.

Can you see if all the workstations have the same Chrome extensions / AV software? Also check for malware as best as you can.

All machines should be using Chrome version 58.0.3029.81 (64-bit). I can confirm the problem persists with this version. 

Every machine here is behind a Sonic Wall and has Trend Micro as AV. The problem persists if all Chrome extensions are disabled or enabled. 

This morning I was able to open PDF files in Chrome for about twenty minutes after starting up my PC, but now they've stopped displaying. I get an error page 'ERR_Connection_Reset' when trying to open the same PDFs that worked half an hour ago. 

Is there some sort of diagnostic log that I can give you that would be helpful? I tried to get some data exports but they wound up having 10,000 items on it; there must be a way to narrow it down that I'm missing. 

Thank you for providing more feedback. Adding requester "weili@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to reproduce this issue on Windows 10 with chrome #58.0.3029.81 with the provided pdf in comment #0.

josephluhn@ could you re-try the same scenario on clean profile with no apps/extensions and let us know your observations.  

Deleted: Issue 714184.PNG 200 KB

	Issue 714184.PNG 200 KB View Download

Today I'm able to access the PDF in my original post, but I couldn't do so yesterday. 

Would a guest profile suffice as a clean profile? I tried loading a PDF from a site I hadn't tried before and got the same error on my Chrome and a guest profile. 

Deleted: PDFError.jpg 28.7 KB

	PDFError.jpg 28.7 KB View Download

Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

josephluhn@,

We are unable to reproduce the issue on Windows 10 ,Mac 10.12.4 & Ubuntu 14.04 using chrome reported version-57.0.2987.133 , stable-58.0.3029.81 & Canary-60.0.3080.0 as per the pdf provided in comment#0.

Able to load and view the pdf successfully without any issue as normal user and guest user.

Please check the issue by upgrading chrome to latest stable/Canary and let us know your observations on the same.

Please find the attached screencast for reference .
Thank you..!!

Deleted: 714184.mp4 1.5 MB

	714184.mp4 1.5 MB View Download

I believe you when you say you're having trouble replicating the issue. That's part of the reason why the issue is so frustrating here. I've got 26 users with varying degrees of the problem - and I have no leads to help solve why there's a problem in the first place. Nobody has mentioned having the problem with other browsers here on site, and nobody has mentioned having issues at home with their personal devices. 

There is some kind of conflict that is present only on company machines. I've tried disabling A/V, I've used Chrome with no user profile, I've used Chrome with no extensions... and nothing is fixing the PDF loading issue. 

This morning I updated Canary to the latest version and tried to pull up the original PDF, and once again I get the error message. 

Loading that same PDF in Chrome Version 58.0.3029.81 (64-bit), appears to be working fine at the moment, but there have been days when the PDF loader stops working partway through the day. 

Deleted: Canary.jpg 102 KB

	Canary.jpg 102 KB View Download

Thank you for providing more feedback. Adding requester "jmukthavaram@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I suspect this is related to your environment somehow. Do you run virtual desktop, or document server/cache in your network? or check whether your firewall blocks some of those connections?

But would that explain why we have the issue in Chrome alone? I'll reiterate that Chrome is the only browser that presents the problem. IE, Edge and Firefox are fine. 

I understand you can't really do anything without being able to replicate the problem. So if you want to let this fade away, that's fine with me. We'll just hope that a future update solves the problem. 

One idea is to use chrome://net-export/ to log the network traffic. Try it on a good machine and a bad machine. Then play spot the difference.

Here are two logs which show a successful load in Chrome and an unsuccessful attempt in Canary. Understanding what these say is a few levels above me. 

Deleted: Canary Fail Log.json 106 KB

Canary Fail Log.json 106 KB View Download

Deleted: Chrome Successful Log.json 289 KB

Chrome Successful Log.json 289 KB View Download

Unable to reproduce the issue from chrome-TE end .Could some one from Plugins dev team please look in to this issue.

Thank You!

Adding "TE-NeedsTriageHelp" label, since we are unable to reproduce the issue on Windows 10 with chrome stable #58.0.3029.96, Canary #60.0.3089.0

thestig@ could you please look into the logs attached in comment #18 and update the latest info.

Thank You...

mattm: Can you help take a look at the network logs in comment 18, or help us find someone who can?

The last entry in the failure case is an entry for a DISK_CACHE_ENTRY event. It's not obvious why the log abruptly ended there. I don't see any errors in the event details either.

In the success case, the events continue and records the fact that the resources for the PDF Viewer itself loaded. In the failure case, there are no such events in the log. I don't see how that's possible given the failure screenshot in comment 13 has the PDF Viewer loaded and displaying an error message.

The logs appear to show that the PDF is already in the browser cache in both cases. Doesn't seem to be enough info here to say much else..

I'm also not sure why the fail case stops abruptly there. 

josephluhn: was there any difference to how the two logs were recorded? 
To make sure there is no pre-existing state interfering, could you try making sure no existing incognito windows are open(or just fully quitting and restarting the browser), starting the net-export recording, then open an incognito window and opening the pdf in the incognito window, wait for it to fully load (or the error to show), then save the log. (And do that same procedure for both the successful and failure cases.) 
Thanks!

It's been a while since I recorded those logs, so I honestly can't remember if there was a difference in how they were generated. 

Here are two more recorded this morning. Oddly enough, I'm able to successfully view the PDF in the link from my original post, but "new" PDFs fail to load. 

In both cases I started an incognito Canary window (vanilla Chrome may have already been open), started the net-export record, and attempted to view the files. For the successful log, I had the direct URL to the PDF. For the failure log I had to navigate a few pages to get to it. 

Deleted: PDF success.json 1.0 MB

PDF success.json 1.0 MB View Download

Deleted: PDF failure.json 1.9 MB

PDF failure.json 1.9 MB View Download

Thank you for providing more feedback. Adding requester "mattm@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks,

Notes about the success log:
1. URL_REQUEST for the pdf, reads a bunch of it before being cancelled
2. pdf viewer resources are loaded
3. three more URL_REQUESTs for the pdf, with partially overlapping byte ranges: 43368-485162,  419627-485162, 169884-419626 (the first two get cancelled after reading some data, the 3rd finishes successfully)

about the failure log:
1. URL_REQUEST for the pdf, reads a bunch of it before being cancelled
2. pdf viewer resources are loaded
3. new URL_REQUEST for the pdf with byte range 35106-129219, but it keeps failing instantly (1-2ms after trying each request) with ERR_CONNECTION_RESET and then retrying, eventually gives up after 6 times.
The first 5 times all get bound to existing idle sockets (All of which are alive for around 15 seconds at the time of failure, with various amounts of idle time ranging from almost 15 seconds to only ~300ms). Once the new job gets bound and data sent, they fail within 2 ms.
The 6th retry gets a new socket. It takes 101ms to connect, then fails 4ms after sending data.

I also noticed that socket id 145 in the log is closed without error at t=19721, which is immediately before all the connection reset failures start.

Not really sure what's going on here, but is there some some sort of transparent proxy, NAT, anti-virus connection interception, etc in use that may be getting confused by the socket pooling / simultaneous connections?

Thanks for taking the time to look at the logs. Our IT person doesn't think this is a bug in Chrome, but related to a firewall setting on our end. If we wind up discovering the root cause, I'll be certain to pop back here and share what it is. 

Thank you for providing more feedback. Adding requester "mattm@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Going to go ahead and WontFix this - if you come to the conclusion the issue is on our side of things, we can reopen (Though if that's more than a month or so from now, probably best to file a new bug).

I think that's fine. My IT guy has gone back and forth on it because he can't reproduce the issue. I still get the error but am at a loss what to do about it. 

You guys do what you need to. 

I'm having the same issue.
Chrome on Ubuntu.

Almost systematically get "failed to load PDF document" with some files both with <embed>ed pdfs and by loading pdfs directly in chrome the first time. Always works on reload (sometimes it works the first time already).

The headers received are identical on fail and on success. This is DEFINITELY an issue in Chrome.


Also note the error message "Failed to load" is ridiculously vague; even if there was a real problem with the file, the server, the network or whatever, the very fact that you don't tell me what exactly the problem is, is a bug in itself.

I forgot: as I mentioned I'm reproducing on Ubuntu, but I have observed the same on Windows.

re: comment 30 + comment 31 - please open a new bug report for your issue. Similar symptoms does not imply same underlying cause.