OLE Link to Word 97-2003 File May Fail with OLE_E_CLASSDIFF Error on Open

Symptoms

You may encounter an OLE_E_CLASSDIFF (0x80040008) error on calls to OleRun or IOleObject::DoVerb when attempting to bind to a Word document saved as an OLE link.  This occurs when the following conditions are true:

  • The document linked to is a Word 97-2003 document (*.doc).
  • Word 2007 was used to create the link.
  • The OLE link was made from an IDataObject pointer obtained from the clipbaord or a drag/drop operation.
  • You get the error when attempting to bind to the linked document again when it is no longer running (i.e., it is not in the Running Object Table).

Cause

The problem can occur because when using the clipboard to obtain link data from Word 2007, the CLSID of the data return can be for a Word 2007 (*.docx) file type.  This occurs regardless of the actual file format type that the document is saved in.  The CLSID is persisted by the OLE link handler when the link is saved.  At some point later when you attempt to reopen the link, if the file specified by the link is not already running, OLE32 will attempt to start the object anew.  Before it does this, it compares the CLSID obtained from the binding to the moniker path to the CLSID saved from the OLE link. In this case, the moniker will return the CLSID {00020906-0000-0000-c000-000000000046} for a Word.Document.8 file type, but the CLSID saved in the link {F4754C9B-64F5-4B40-8AF4-679732AC0607} is for a Word.Document.12 type.  OLE considers these different object types and will return the OLE_E_CLASSDIFF error on binding.

Workaround

The OLE client can override the CLSID check made by OLE32 when binding, which can thereby avoid the problem.  To do this, check if the CLSID associated with the link is for the Word.Document.12 object type, and if it is, you can call IOleLink::BindToSource (before calling OleRun or IOleObject::DoVerb) and pass the OLELINKBIND_EVENIFCLASSDIFF flag.  This flag will tell OLE to ignore the CLSID differences and allow the CLSID specified by the moniker to open the link.  Since Word implements both objects the same in regards to links, this would work fine.

Status

This problem is a confirmed bug reported for Word 2007.