INFO: Troubleshooting Error 429 When Automating Office Applications
ID: Q244264
|
The information in this article applies to:
-
Microsoft Visual Basic Professional and Enterprise Editions for Windows, versions 5.0, 6.0
-
Microsoft Access versions 2000, 97
-
Microsoft Excel 2000
-
Microsoft FrontPage 2000
-
Microsoft Outlook, versions 2000, 97, 98
-
Microsoft PowerPoint versions 2000, 97 For Windows
-
Microsoft Word 2000
-
Microsoft Excel 97 for Windows
-
Microsoft Word 97 for Windows
SUMMARY
When using the New operator or CreateObject function in Visual Basic to create an instance of an Office application, you may get the following error:
Run-time error '429': ActiveX component can't create object
This error occurs when the requested Automation object could not be created by COM, and is therefore unavailable to Visual Basic. The error is typically seen on certain computers but not others.
This article provides some troubleshooting tips to help you diagnose and resolve common problems that are known to cause this error.
MORE INFORMATION
Unlike some errors in Visual Basic, there is no one cause to an error 429. The problem happens because of an error in the application or system configuration, or a missing or damaged component. Finding the exact cause is a matter of eliminating possibilities. If you encounter this error on a client computer, there are a number of things you will need to check to isolate and resolve the error.
The items later give you some practical suggestions for debugging this error when working with Office Applications. Some of this information may also apply to non-Office COM servers as well, but this article assumes you are trying to Automate Microsoft Office.
Checking the Code
The first place to begin looking for the problem is in the code. Before you can troubleshoot the error, you need to know where the error occurs. Try to narrow it down to a single line of code.
When you find the code that is failing, try to do the following:
- Make sure the code uses explicit object creation. Any problem will be easier to spot and identify if the problem is narrowed to a single action. For example, don't do the following:
Application.Documents.Add 'DON'T USE THIS!!
or:
Dim oWordApp As New Word.Application 'DON'T USE THIS!!
'... some other code
oWordApp.Documents.Add
Both of these methods use implicit object creation -- Word is not started until the variable is called at least once. Since the variable could be called in different parts of the program, this could make the problem hard to localize. Also, it is not clear whether the problem is with creating the Application object or the Document object.
Instead, make explicit calls to create each object separately:
Dim oWordApp As Word.Application
Dim oDoc As Word.Document
Set oWordApp = CreateObject("Word.Application")
'... some other code
Set oDoc = oWordApp.Documents.Add
This makes the problem easier to isolate and makes the code more readable.
- When creating an instance of an Microsoft Office application, use CreateObject instead of New. CreateObject more closely maps to the creation process used by most Visual C++ clients, and allows for possible changes in the server's CLSID between versions. CreateObject can be used with both early-bound and late-bound objects.
- Verify that the ProgID string passed to CreateObject is correct and that it is version independent (that is,, use "Excel.Application" rather than "Excel.Application.8"). It could be that the system that is failing has an older or newer version of Microsoft Office than the version you specified in the ProgID.
- To aid in debugging applications that cannot be run in the IDE, use the Erl command to report the line number of the line that fails. For example, the following code will tell you which Automation object cannot be created (Word or Excel):
Dim oWord As Word.Application
Dim oExcel As Excel.Application
On Error Goto err_handler
1: Set oWord = CreateObject("Word.Application")
2: Set oExcel = CreateObject("Excel.Application")
' ... some other code
err_handler:
MsgBox "The code failed at line " & Erl, vbCritical
Use a combination of message boxes and line numbers to track down the error.
- Try using late binding (that is,, Dim oWordApp As Object). Early bound objects require their custom interfaces to be marshaled across process boundaries. If there is a problem marshaling a custom interface during CreateObject or New, you will get an error 429. A late bound object uses a system-defined interface (IDispatch) that does not require a custom proxy in order to be marshaled. Try using a late bound object to see if this makes a difference.
If the problem occurs only when the object is early-bound, the problem is with the server application, and can typically be corrected by reinstalling the application (see later).
- If you are automating from ASP or an MTS component, use CreateObject instead of Server.CreateObject(). Using Server.CreateObject will instantiate the Office application under the identity of an MTS package which is known to cause problems with Microsoft Office.
Checking the Automation Server
The most common reasons for an error with CreateObject or New are problems with the server application itself. Typically, these problems are with the configuration or setup of the application. Here are some items to check:
Checking the System
System configuration can also cause problems with the creation of out-of-process COM servers. The following are some things to check on systems where the error occurs:
- Does the problem happen with any out-of-process server? If you have an application that just uses a particular COM server (for example,, Word), you'll want to test a different out-of-process server to make sure the problem is not with COM layer itself. If no out-of-process COM server can be created on that system, then a reinstallation of the OLE system files (see below) or a reinstallation of the operating system will be required to resolve the issue.
- Check the version numbers for the OLE system files that manage Automation. These files are typically installed as a set, and should match build numbers. An improperly configured setup utility can mistakenly install the files separately, causing them to become mismatched. To avoid problems with Automation, you should check the files to make sure the files match builds.
You will find the Automation files in the Windows\System or Winnt\System32 directory. The following is the list of files to check:
+---------------+-------------+----------------+
| File Name | Version | Date Modified |
+---------------+-------------+----------------+
| Asycfilt.dll | 2.40.4275 | March 08, 1999 |
| Oleaut32.dll | 2.40.4275 | March 08, 1999 |
| Olepro32.dll | 5.0.4275 | March 08, 1999 |
| Stdole2.tlb | 2.40.4275 | March 08, 1999 |
+---------------+-------------+----------------+
Check the file version by right-clicking on the file in Explorer and selecting Properties from the popup menu. The values most important are the last four digits of the file version (the build number) and the date last modified. You want to make sure these values are the same for all the Automation files.
Please note that the version numbers and dates given above are for example purposes only. Your values may differ. The important thing is that these values match each other, rather than this table.
If the files don't match build numbers or modified dates, you can download a self-extracting utility that will update your Automation files. Please see the following Knowledge Base article:
Q235420 FILE: VBRun60sp3.exe Installs Visual Basic 6.0 Run-Time Files
- Windows NT 4.0 has a known problem with starting Automation servers that live in a folder that contains an embedded space in the name, and/or resembles another folder whose first 8 characters are identical. For example, a server living in C:\Program Files\SomeFolder may fail to start during a call to CreateObject if there is another folder on the system called C:\Program Stuff\SomeFolder. For more information on this problem and steps to workaround it, see the following Knowledge Base article:
Q185126 BUG: Error 429 "ActiveX Component Can't Create Object" on NT
Reinstalling Microsoft Office
If none of the above steps helps to resolve the problem, consider uninstalling and reinstalling Microsoft Office. It is recommended that you uninstall the existing version first, run a registry clean utility (such as RegClean 4.1) to remove any orphaned registry keys, and then reinstall from the original installation disks.
For a complete list of the items to be removed, please see the following Knowledge Base articles:
Q219423 OFF2000: How to Completely Remove Microsoft Office 2000
Q158658 OFF97: How to Completely Remove Microsoft Office 97
Also, you can download a copy of RegClean 4.1 from Microsoft. See the following Knowledge Base article for more information:
Q147769 INFO: RegClean 4.1a Description and General Issues
REFERENCES
For the latest information and sample code regarding Microsoft Office Automation, please see the Microsoft online support site at:
http://support.microsoft.com/support/officedev/ © Microsoft Corporation 1999, All Rights Reserved.
Contributions by Richard R. Taylor, Microsoft Corporation
Additional query words:
kbAccess kbAutomation kbExcel kbFrontPage kbOutlook kbVBp500 kbVBp600 kbPowerPt kbWord
Keywords : kbGrpDSO kbDSupport
Version : WINDOWS:2000,5.0,6.0,97,98
Platform : WINDOWS
Issue type : kbinfo
|