Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 7715
  • Last Modified:

Where does mime type application/pdf.A520491B_3BF7_494D_8855_7FAC2C6C0608 come from?

We observed on a number of PCs in our company that the mime type application/pdf.A520491B_3BF7_494D_8855_7FAC2C6C0608 is defined in the registry. It's linked to .doc files. As a result, when uploading ms-word files to a web site, they are sometimes (not always) received with this incorrect mime type.

When I google for this strange mime type, I can see we're not alone.

I can delete that registry key of course, but I'd like to understand where it comes from, so we can avoid that it's being created in the first place.

Thanks in advance for your help.

Details from the registry:
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/pdf.A520491B_3BF7_494D_8855_7FAC2C6C0608]

  • 4
  • 3
  • 3
  • +1
1 Solution
That is a legitimate entry for Adobe Acrobat readers pdf.ocx.

clearly it is associated with application/pdf, which is correct, but the extension entry should be .pdf not .doc.

You should not remove the entry but correct the extension, export that registry entry to a reg file, then use the reg file to correct the other machines.  Or save the below snippet as fixpdf.reg and merge it into the registry of the affected machines.
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/pdf]
@="Adobe Acrobat Document"

Open in new window

BTW pdf.ocx is what allows pdf files to open within IE.  If Adobe Acrobat reader was not loaded on a machine and the user attempted to open a pdf file in IE, Word might have been suggested as a reader. When the user selected that you got the errant registry entry.  There are other ways that could happen, that's just one scenario.
jefdebackerAuthor Commented:
Don't know if this is th right way to react to an expert comment, but anyway...

To rdivilbiss:
Looks like you are referring to mime type applicat/pdf. That mime type is properly defined on our PCs.
However we have ANOTHER strange mime type, next to it, called application/pdf.A520491B_3BF7_494D_8855_7FAC2C6C0608
My question is about that one.
Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to and use offer code ‘EXPERTS’ to get 10% off your first purchase.

b0lsc0ttIT ManagerCommented:

I have been interested in this almost from the start and noticed your efforts to get help.  It does not seem like this is something other experts have a quick answer for or have seen.  I have search Adobe's forum and have not seen this specifically mentioned.  That forum isn't necessarily the best for searching for issues but is pretty good.  It hasn't helped to find a known cause or solution for this.

Since you still seem interested in help and the quick solution/answer hasn't worked then I can offer some tools and steps to hopefully help you find the cause.  With some more info then we may even help to explain it and provide a fix if it isn't obvious to you after using these tools.

First, remove the subkey again from your registry.  You can back it up first if you want.  Do you notice any errors, etc after removing it, especially if you go into Acrobat programs or try to view the files in various readers you have installed?  If so that could be a clue to the source of the entry and why it is important.

Use the program Regmon ( or Process Monitor ( to monitor your computer.  I believe they both have the option to filter results.  You will need that to narrow down what you see and can use something like application/pdf to find just what you need.  You can leave the program running if you aren't sure what causes the entry and check it occasionally.  If you have an idea of some possible causes then start the program just before testing so your log is smaller.  The programs (you only need to use one and choose it based on your OS) can remain running in the background but create a large log file so you don't want to just let them run forever. :)

This will hopefully show us when the change is made.  The entry itself or those at the same time should point to the process or program that makes the entry.  This will be important info to try to find an explanation and way to prevent this entry.

Let me know if you have a question about this.  I don't use those programs a lot myself but they are great tools for troubleshooting and very powerful.

I've watched this one since the help request was posted and, like b0lsc0tt, did some web searches.

This registry setting does not exist in my WinXP SP2 system.  I have Office 2003 and Adobe Acrobat Reader 5.5 installed on this system.

At first glance I had wondered if this was perhaps a cross-reference to a CLSID (Class Identifier) that would be found elsewhere in the registry as {long-hex-number-here}, but it doesn't follow the correct pattern.

I did a web search on the numeric part of the registry value only, and wasn't surprised to see a few results:

From that it is apparent that you are not alone, as you already know, and that this doesn't seem to be a rogue value tacked onto the file type association.

Observe the hyperlink to the *.bin attachment that was disallowed in this posting to a Mailing List:

A non-text attachment was scrubbed...
Name: Discipline Plan.doc
Type: application/pdf.a520491b_3bf7_494d_8855_7fac2c6c0608
Size: 20992 bytes
Desc: not available
Url :

Save that *.bin file and you have a standard Word version 9 *.doc with a .bin extension.  I can't see anything strange in it, but the MIME Content Type is being rejected as unrecognised or non-standard.

I am curious to see the details of the keys and values cross-referenced by the other value you have under that key, ie. the Class Identifier:


Could you please export the following registry keys to  *.reg files and paste the contents here as one or more "code snippets" or rename them as a *.txt files and upload them as attachments to your comment:



(If it exists. Maybe the "5" reflects the installed version of Adobe Acrobat Reader and yours may be PDF.PdfCtrl.6, PDF.PdfCtrl.7, or PDF.PdfCtrl.8)

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{CA8A9780-280D-11CF-A24D-444553540000}]

The "InProcServer" in the first *.reg export is set as:

C:\Program Files\Adobe\Acrobat 5.0\Reader\ActiveX\pdf.ocx

This IS NOT the Internet Explorer Browser Helper Object that allows *.pdf files to open in IE.  That is served by:

C:\Program Files\Adobe\Acrobat 5.0\Reader\ActiveX\AcroIEHelper.ocx

and you can enable or disable this in IE's Tools menu > manage Add-Ons.  I'm quite sure that PDF.OCX is heavily integrated with the functionality of the BHO though, so it would be worthwhile disabling the Acrobat Reader BHO and uploading another test document to a website.

I am also curious to know HOW you are uploading the *.doc files to

I have attached my 3 Registry exports as renamed *.txt files for you to compare.


b0lsc0ttIT ManagerCommented:
From what you have provided to us it seems like your experience and knowledge will help you know this but just in case I would suggest working on BillDL's comment first.  His seems to have a better or quicker chance of solving this.  You can always try what I suggested after if we need to.

jefdebackerAuthor Commented:
To BillDL

Thanks a lot for your reaction. I already learned that this entry IS related to the adobe reader after all. A quick check in the registry of my own PC revealed this:

Key [HKEY_CLASSES_ROOT\CLSID\{CA8A9780-280D-11CF-A24D-444553540000}]
This key is not present at all. So I can't check for the "InProcServer" either.

Mine has number 1 instead of 5. Otherwise it's identical to yours.
That number does not relate to the version, as I run Adobe reader 8.

Key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{CA8A9780-280D-11CF-A24D-444553540000}]
Identical to yours.

Sorry, but I don't know what BHO means.

I remember another issue I had originally with Adobe reader, which may or may not be relevant, but anyway, here it goes:
Like all new PCs in our company, my own PC came with Adobe reader 7 installed. This particular release came with a very annoying bug: I had it set to display PDF files in a reader instance, and not in the browser window. Every time I followed a URL to a PDF, my browser timed out. After clicking away the error message, the file opened properly in Adobe reader.

This issue was known to our internal support team. Those guys advised me to change the setting to display PDF files in a browser, then reboot the PC, then change it back to what it was. (Don't remeber if I had to reboot a second time.) That solved the issue.

These actions have definitely made some updates in the registry, maybe even to the keys we are looking at. Meanwhile I've update to Adobe reader 8, which will have made even more changes...
I'll probably need to track down a PC in it's original configurartion, that still has that strange mime type association, then check again there.

On your question HOW we upload:
We are uploading files to a web-based document management system called Livelink. In a browser page we specify the path to a file on local disk, then click on a Upload button. The Javascript behind this button results in  HTTP POST request.
The headers of this request look like this (example when uploading a MS-word file):

(Request-Line):      POST /Livelink/livelink.exe HTTP/1.1
Accept:            image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/, application/, application/msword, application/x-ms-application, application/x-ms-xbap, application/, application/xaml+xml, application/x-silverlight, application/x-shockwave-flash, */*
Accept-Encoding:      gzip, deflate
Accept-Language:      en-us
Cache-Control:      no-cache
Connection:            Keep-Alive
Content-Length:      81453
Content-Type:      multipart/form-data; boundary=---------------------------7d81cf37c0668
Cookie:            <Removed for privacy reasons.>
User-Agent:            Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; MS-RTC LM 8)

The posted data consists of 28 name/value pairs. I'll list only the relevant one. Note that the mime type is correct in this example.

versionFile      filename="D:\Profiles\ameqs\My Documents\Enable recommender.doc" Content-Type: application/msword

jefdebackerAuthor Commented:
To b0lsc0tt:

I know (some of) the tools of systinternals. I don't use them often either.
I considered your suggestion, but we'll have to do so during installation of software packages then. A huge task.
From BillDL's reaction I already learned we'll have to concentrate on the installation / configuration of Adobe Reader.
But thanks anyway.
OK, I think Live Link is doing its job the way it is set to do it.  Looking at the header created, it is clear that the "Accept: " section of the header reflects what kind of perceived file types it will accept.  Although it doesn't specify the standard "application/pdf" MIME type, from my reading of it the very last  */*  seems to imply that the *'s are used as wildcards in the same way that a search for files at the command line with *.* will find files named anything with any file extension.

If my reading of this is correct, then the "Accept: " section of the header reflects a setting where it will accept all files regardless of whether the "whatever/ext" is previously specified in the list, or even a recognised one.

Going back to the google search on:
it is notable that all the results tend to show that the Word documents perceived as this Content Type were not accepted when uploaded, but were archived as unknowns.

If I am correct in my interpretation of the Livelink header with regard to the */* part, then that would explain why your Word documents are sneaking by without a recognised and standard Content Type.

This said, however, there is no getting past the fact that this key is present in your registry and there is no valid explanation.  I have done a lot of searching to try and get an explanation, but in the end I can only assume that it has either been added by Adobe Acrobat, crobat Reader, or some other program that is able to create, edit, or "print to" *.pdf files.

In addition to the unusual registry key:

[HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/pdf.A520491B_3BF7_494D_8855_7FAC2C6C0608]

you have the standard one that is exactly as follows, correct?:

[HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/pdf]
@="Adobe Acrobat Document"

Note the different and correct "CLSID" value.  That is correct for the actual document file type ie. "Adobe Acrobat Document".  A quick check of the registry key:


would confirm that it relates to normal *.pdf files and also to the program associated with the "Open" action.  I can't give you a good registry export from that key because the "LocalServer" sub-key on my system has the [Default] value set to Foxit Reader's executable.  Yours should be:

C:\Program Files\Adobe\Acrobat x.x\Reader\AcroRd32.exe

If any of the values in this registry key and sub-keys was wrong, I'm quite sure that *.pdf files would not open properly in Acrobat Reader, but it would be worthwhile just double-checking for any values that cross-relate to MS Word or to the odd Content Type numeric value you have in the key you are asking about.

Check the key:
to ensure that the [Default] value does not contain any file extensions other than ".pdf, PDF Files(*.pdf)".  Inclusion of *.doc would clearly be wrong.

It's beginning to look more and more like the weird Content Type is the product of a buggy installer.  I have to correct myself on something I said in my fiorst comment about the long numeric part not matching the format of unique CLSID's.  It does, ie.
8-4-4-4-12 (dashes, not underscores).  I was thinking of something else at the time, but that presents the logical question, do you have such a CLSID number elsewhere in your registry?

Perhaps as:


I don't have any beginning with "A", and don't think I have ever seen any that do, but it's worth checking in case it would yield clues as to how it was created.

I have a recollection of seeing files with a similar or the same naming convention (using underscores) in the setup files of a large application like MS Office, but I cannot recall accurately enough to locate the CD and see if such a number exists in the file names.

I think we are really right back to b0lsc0tt's suggestions to back up and delete the out of place sub-key and then try to monitor registry writes using RegMon.

It's the logical way to go, and I'm sure you would have been doing this anyway, but if you delete the sub-key and find that everything functions normally and the key is not created again, then at least the uploaded MS Word *.doc files are going to be standard even though nothing has yet explained HOW that registry key was created.

I found this that may be useful:

Another thing you could probably do is leave the key in place, but delete both the Values under it, then use RegEdt32.exe to change the "Permissions" for the remaining key so that in normal use it could not be written to without showing an error.  This should be logged in Event Viewer and may reveal the culprit.

Oh yes, "BHO" means "Browser Helper Object.  Generally it's an ActiveX Control plugin (eg. *.ocx)such as you described where Acrobat Reader opens within the browser window.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects

and IE Tools > "Manage Add-ons" menu.

I'm sorry I haven't been able to discover anything more useful to follow.
jefdebackerAuthor Commented:
Since it became clear that this problem was cuased by the installation process of some software package, I escalated it to my colleagues who mind themselves about the PC had and software. They found that these invalid registry keys were created by the installation of the "MCI access manager", an ancient piece of software that is installed on our laptops. It turned out to be a bug in the original package, which has been fixed now by deleting these invalid keys. Case can  be closed.

BillDL, your contribution significantly helped us to understand what was happening, and you provided the crucial hints of where to look. I'll grant you the points.

Thanks to all other contibutors too.
Thank you jefdebacker.  Glad my comments were of some assistance.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 4
  • 3
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now