The recent Adobe Reader 9.4.2 is causing issues with PDFs opening in IE 8 and 9 browsers. Prior to this update our users have had no issues with opening PDFs generated by our website.
Our website generates USPS labels using Siberix ReportWriter software. We have not released any updates for at least a month. Again, before the release of Adobe Reader 9.4.2, there was no issues with our website's PDFs opening in IE browsers.
User System Specs:
Windows XP SP3 and Windows 7 Ultimate
Adobe Reader 9.4.2
Internet Explorer 8 - "File Download" window issue
Internet Explorer 9 - "File Download" window issue
Firefox 3.6.13 - No Issues
Chrome 9.0.597.98 (with Adobe Reader 9.4.2 plugin enabled and Chrome PDF Viewer disabled) - No Issues
The "File Download" window states the following (in addition to a Save and a Cancel button): "The file you are downloading cannot be opened by the default program. It is either corrupt or it has an incorrect file type. As a security precaution, it is recommended that you cancel the download. ..."
We have the following workarounds to address this issue with our customers, but they are not ideal:
Any solutions to this issue would be appriciated.
We have also started to experience the same problem here since people's reader was upgraded to 9.4.2. We need a solution to this ASAP!
Can you please try out the following steps to help isolate the issue:
1. Try opening a PDF on your local system, in Internet Explorer 8/9. What is the behavior.
2. Try opening some other PDF at some other URL on Internet Explorer 8/9 such as:http://kb2.adobe.com/cps/837/cpsid_83708/attachments/Acrobat_Reader_ReleaseNote_9.4.2_8.2.6.pdf
3. If possible, can you share a link currently not working on your customer's system.
Thanks in advance.
Thanks for your reply,
As to your questions:
We investigated further with other PDFs generated by our website (we have pages that create order forms, and other documents), and they all work fine. All the PDFs generated on our site use the same PDF generating software (Siberix ReportWriter) and are all generated from memorystream.
Below is the asp.net/vb.net code we use to post all website generated PDFs to our users:
Response.ContentType = "application/pdf; name=" & randomName & ".pdf"
Response.OutputStream.Write(pdfByteArray, 0, pdfByteArray.Length)
Also seeing this issue. Windows Vista SP2 with IE8 and Windows 7 with IE8. PDF generation is also done on the fly, and streamed back to the client. With Reader 9.4.1, this was working fine. After 9.4.2 upgrade, now we get an IE file download block message. We can click "Download File", but then we get a message to Save the PDF, instead of the PDF opening in the browser window like it always has. After clicking Save, and saving it to the desktop, the PDF can be opened in Adobe Reader standalone. We have the Internet option in Reader set to open in the browser. The text of the Save message is: The file you are downloading cannot be opened by the default program. It is either corrupted or it has an incorrect file type. As a security precaution, it is recommended that you cancel the download.
Ditto for us. We are using a popular 3rd party web-based document management system which creates the PDF files on the fly. It is used internally by our employees and externally by customers. The system worked fine for all until the Adobe Reader 9.4.2 upgrade a few days ago. Please provide a fix/advice or some direction for troubleshooting this problem asap.
Same issue here ... we're creating PDFs on the fly (streaming them) on
our website. Worked with 9.4.1, broken with 9.4.2. Help!!!
We are experiencing the same problem, as I mentioned below. I did some research and experimentation, and have a ... workaround. It's not completely satisfactory, but we will go with it until we have a complete solution. Perhaps the following will help others and spur some research in the right direction.
First, a quick review. The problem does not occur with PDFs located on disk; it only occurs with direct streaming of PDF data. Let's also note that the problem does NOT occur with other browsers, e.g. FireFox. So ... technically the problem is not an Adobe Reader problem and we're all on the wrong forum.
My specialty is databases and I'm certainly no expert in this area, but from what I'm able to gather the problem is instead with how IE is recognizing and responding to the MIME type of the streamed data. We're all setting the contenttype to "application/pdf" (or similar) or we wouldn't even be here. But I'm concluding that something - some windows update - has changed the way IE on clients or (in my case) IIS on the server is handling that data stream. If any of you experiencing this issue have servers other than IIS, then the problem is on the client side, I'd say.
Aaaaaanyway, the following articles are old, but helped me:
To cut to the chase, the workaround we're going with for now is to add the following to the http response header (this is C#/ASP.NET code):
That causes a popup dialog to appear asking the user to open or save the PDF, something that is familiar to most everyone. If the user asks to open the file, it appears in a browser window just as it did before this problem occurred. Again, this is a temporary solution, but at least the user can see the PDF data in a browser with one extra mouse click.
If an Adobe tech support person or anyone with more experience in this area knows the final solution, I'd LOVE to hear it. Please reply here or in email.
Thanks and good luck all.
Thanks for your reply,
Yes, it does look like this is an issue with streaming, but it's not a very consistent one. In my second post, I noted that I tested this with several of our streamed PDFs, and some of them worked, while others did not.
However, I do think this is an Adobe Reader 9.4.2 specific issue. I tested it myself: Before the Reader update, it worked correctly. After I updated to 9.4.2 it stopped working correctly. Also note that there were no corresponding windows or IE updates (I have my windows update service set to download but not install). And, again, this is an issue that isn't consistent... we have some streaming PDFs open correctly, while others do not.
It's good that you found a workaround that works for you for the moment. Unfortunatly, this does not perform in the way our clients expect, so this won't be a solution that we can use. I'm open to anymore suggestions, but we need for the PDFs to open directly, without any prompts, and without the client having to do anything on their end (which my be impossible at this point).
As I suggested in my opening post, we have found several workarounds to the issue, but they are not ideal (they fix the issue, but they require our clients to make the fix on their side, which is something that they shouldn't have to do).
Hopefully Adobe will release an update soon to correct this issue (along with some other issues it seems to be having).
@BillyBeeeeee: Just because it works in Firefox and not in IE doesn't rule out Adobe Reader as the cause of the problem.
Firefox uses the following dll: C:\Program Files\Adobe\Reader 9.0\Reader\Browser\nppdf32.dll
IE uses the files under: C:\Program Files\Common Files\Adobe\Acrobat\ActiveX\
An initial fix for me was to replace the file C:\Program Files\Common Files\Adobe\Acrobat\ActiveX\AcroPDF.dll (version 220.127.116.11) with the version from Adobe Reader 9.4.1 (version 18.104.22.168) and this seemed to solve the problem. This wasn't a realistic solution though as I have no idea what security holes I might introduce by doing this.
After some monitoring of the headers from links with fiddler (http://www.fiddler2.com/fiddler2/) that worked versus the ones that didn't the common problem seemed to be:
Working: Content-Type: application/pdf
Broken: Content-Type: application/pdf;charset=UTF-8
Previously I had been monitoring IE with process monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645) trying the different versions of the AcroPDF.dll loaded to find out what the difference was and I noticed with the new dll was trying to access "HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/pdf;charset=UTF-8". After digging further I've managed to add this registry key:
Windows Registry Editor Version 5.00
This seems to fix it for me.
I know it isn't a solution for most of the issues on this post, and I don't know if your issues are related to the the headers but I thought it might help someone in the right direction or even better help Adobe fix the root cause.
Thanks for posting some other workarounds for this issue. Hopefully this helps Adobe in identifying what the underlying issues are.
Thank you for the detective work. Where does AdobeMimeTreatAs come from? Do you have a reference for this?
Sorry I don't have any references for AdobeMimeTreatAs.
I just ran process monitor trying to work out what changed between the AcroPDF.dll in 9.4.2 and 9.4.1 and noticed it trying to access the key: HKCU\Software\Classes\MIME\Database\Content Type\application/pdf;charset=UTF-8. I then created the key and ran the same test again and as Reader found the key it then looked for the value AdobeMimeTreatAs. I created this value although without setting it as anything it didn't work. Given the name of the value I thought I would assign it "application/pdf" and it seemed to work. All I can guess is that Adobe Reader doesn't know what to do with the content type "application/pdf;charset=UTF-8" so checks the registry to see how it should be displaying the PDF and that key just tells it to use the "application/pdf" mime type.
As browserpdfman mentioned this is all undocumented and probably unsupported from Adobes point of view so I'm only using it as a stop gap until they fix 9.4.2 or we can move to 10.x. I've only tested it on Windows XP SP3 and IE8 so far so highly recommend anyone else considering using it tests it fully in their environment first. If it doesn't work for you then use fiddler or another application to monitor the reponse headers and look at the content type that comes down for the pdfs that work compared to those that don't.
For us upgrading to Adobe Reader 10.0.1 doesn't seem to be an option at the moment as they have managed to break protected mode and folder redirection (http://forums.adobe.com/thread/789500?tstart=0) so I'm very cautious about upgrading.
Thanks again. Interesting. So before 9.4.2, Reader did understand the charset suffix, now it doesn't. We discovered that charsets will vary -- on some sites it could be UTF-8, others ISO-8859-1 etc. The way to determine which charset (like already mentioned) is to capture the http response using a tool like fiddler.
Hi. Referring to the initial post - Why isn't upgrading to Reader X considered a recommended fix? Adobe Updater is indeed keeping me at Acrobat & Reader 9.4.2 without notifying me of the Acrobat/Reader X (v 10) upgrade.
(I did upgrade to Acrobat/Reader X (Ver 10) on a Win XP SP3 system with Creative Suite 3, which seems to fix this problem, but I'm holding off for Adobe's fix on a Win 7 64bit system with CS5 - both systems with IE8). ?
It is one of several workarounds that might be acceptable for some depending on the circumstances. For my company, however, we have thousands of clients, many of which do not have administrative privilages on their machines, and each with their own install/update policies that are managed by their own IT departments. This makes updating to Adobe Reader X a less than ideal solution in our situation.
@RStoddart: wow, impressive workaround... but it is fragile, so users beware. Uninstalling, patching to new dot-releases or upgrading major versions with that registry item in there will have, how do they say "undefined results". Of course, unless something better is found, it's the best so far.
It looks like the new version doesn't handle anything after "application/pdf". Unfortunate, and something that is important to fix.
There are a lot of software that we have to buy but we want us to get that software for free. Now you don't have to go to any website and buy a software.Visit our website activation keys now and download Paid software for free.Our website provides you with free software activation keys. You can download paid software for free and also can enjoy the software's premium features.
In C#, you need the following:
Response.Charset = null;
to make sure the HTTP header looks like:
instead of having a value Adobe Reader v9.4.2 can't handle:
Content-Type: application/pdf; charset=UTF-8
Sorry about the delay in my response.
We tried your suggestion and set the Response.Charset = Nothing (vb.net). Unfortunately, this didn't correct the issue for us.
Thanks for your input, and hopefully it helped someone else.
Even I have faced similar when I have upgraded my adobe to 9.4.2 version. I was creating pdfs on the fly by writing to the response stream directly in the java servlet. Adding the line response.reset() before populating the response headers and content had solved my issue.
Has there been any response from Adobe on this? Upgrading to Adobe Reader X isn't an option for us and we have external customers that were once working (9.4.1) and are now broken (9.4.2). Adobe pushed an update via their automatic updater that broke these clients. Does Adobe intend to fix them?
Internally, we are using the MIME\Database Content reg hack mentioned above and have our internal customers working but, I cannot suggest that to my external customers without Adobe's support. Even moreso, I cannot recommend that my external customers upgrade to Reader X.
Adobe - You broke these machines via Auto-updates. Please address the issue.
We have looked into this issue and have been unable to reproduce this in-house, We've created an internal web server that returns the MIME type "application/pdf;charset=UTF-8" for PDFs, and Reader 9.4.2 on all our machines, all our OS versions and IE versions, works just fine with that server.
Do you have a URL and/or login we can use on your site to try to reproduce this?
@BrowserPDFMan - are you Adobe Support? If not, thanks for taking the time to try to repro it.
We are using a 3rd-party web site which I won't mention on this forum. However, if you'd like to try to repro - our URL uses the following charset:
Internally, we are able to get our AR942 users running the streamed PDFs by applying this reg hit (mentioned above in the forum thx to RStoddart)
For obvious reasons, we don't want to have to ask our customers to apply the above reg hack. It would be better to fix the broken AR942.