When you use an out-of-process client application that uses early binding to Automate Microsoft Word 97 or later versions of Word, the application may crash with an access violation or you may receive one of the following error messages:
From Microsoft Visual Basic:
Run-time error '-2147023113 (800706f7)':
The method '~' of object '~' failed
Run-time error '-2147023113 (800706f7)':
Method 'Execute' of object 'Find' failed
Run-time error 430:
Class does not support automation or does not support expected interface.
From Microsoft Visual C++:
HRESULT = 0x800706F7
RPC_X_BAD_STUB_DATA - The stub received bad data.
Note In debug builds, you receive a corrupt stack warning message from an
Assert dialog box, and the value of EAX is that listed above. In release builds, the stack corruption likely crashes the application soon after this point. However, the HRESULT value is likely to be similar to the above.
The problem occurs consistently on some computers, but may never occur on others. Installing a new application or a Microsoft Excel service pack can cause a computer that was working previously to experience the problem.
Several globally unique identifiers (GUIDs) that are used by Word for its interface identifiers were used by Excel 5.0 for an older object model that is now obsolete.
When the Excel 5.0 type library is reregistered on a system, the interface GUIDs in the registry that should point to the Word type library point to the Excel 5.0 library, and COM can mistakenly construct the wrong proxy v-table for an out-of-process client using early binding to Word. Calls that are made to this proxy return errors or crash because the proxy is configured for a dispinterface for Excel instead of for a dispinterface for the expected Word interface.
The following GUIDs are duplicated in the Excel 5.0 type library and the Word 8.0, 8.1, 10.0 and 11.0 type libraries.
Interface ID (GUID)
Excel 5.0 dispinterface
If the Word type library is properly registered, COM constructs the correct proxy and the out-of-process calls function normally.
To resolve this problem, use one of the following methods.
Modify your code to use late binding when you call methods or properties on any of the above listed Word interfaces.
Reregister the Word type library on the system on which the problem occurs.
The recommended solution is to use late binding. Because both type libraries describe interfaces that implement the IDispatch interface, calls to any of the IDispatch methods work regardless of which library was last registered on the system. This is the only way to be sure that your code does not encounter this error on systems that you do not administer.
For customers who use client applications that cannot be recompiled to use late binding, you can reregister the Word type library to resolve the problem in most cases. Because the problem returns if the Excel 5.0 library is reregistered again, this method is not an ideal resolution. However, the chances of the Excel 5.0 library being reregistered are low. Therefore, this method should work for most users.
To reregister the Word type library, find the appropriate type library for the version of Word that is installed on the system.
Then, from the command line, use Regtlib.exe together with the full path to the type library to reregister the library for COM. Regtlib.exe calls the LoadTypeLib and RegisterTypeLib application program interfaces (APIs) on the type library (.tlb or .olb) file that is passed in. COM repairs the misconfigured registry keys.
Regtlib.exe is included in the Windows Libraries Update.
For more information about the Libraries Update, click the following article number to view the article in the Microsoft Knowledge Base:
197298 Microsoft Libraries Update: what, where, why
Microsoft has confirmed that this is a bug in the Microsoft products that are listed in the "Applies to" section.
The Excel 5.0 type library (Xl5en32.olb) is provided for backward compatibility, and is used by clients that were written before Excel 97. The type libraries for Excel 97 and later do not conflict with the Word type library. The Excel 5.0 library is not normally registered. Therefore, most clients do not encounter this problem. Clients that encounter this issue have probably installed a specific product that uses the library and has registered it after Office setup.
Steps to reproduce the problem
Find the Excel 5.0 type library (Xl5en32.olb), and then register it by typing Regtlib at a command prompt.
In Visual Basic, create a Standard EXE project. Form1 is created by default.
Add a button to Form1, and then paste the following code example in the code section for Form1.
Private Sub Command1_Click()
Dim oApp As Word.Application
Dim oDoc As Word.Document
Dim oSel As Word.Selection
Set oApp = New Word.Application
oApp.Visible = True
Set oDoc = oApp.Documents.Add
Set oSel = oApp.Selection
oSel.TypeText "This is a test. You too can automate Word."
oSel.Start = 0
oSel.Find.Execute "Word", , , , , , True, _
wdFindContinue, , "Microsoft Word 2000", wdReplaceAll
MsgBox "Did it work?"
Set oSel = Nothing
oDoc.Saved = True
Set oDoc = Nothing
Set oApp = Nothing
On the Project menu, click References.
In the References dialog box, select Microsoft Word 8.0 Object Library (or select the Word 9.0 Object Library, the Word 10.0 Object Library, or the Word 11.0 Object Library), and then click OK.
Compile and run the code, or press F5 to run the code in the debugger. Click the command button. You receive the error message that is described in the "Symptoms" section.
Fix the issue by reregistering the Word type library as described in the "Resolution" section. Or, replace the early-bound declaration of the Selection object to use late binding with the following code example.
Dim oSel As Object