This error occurs when the Component Object Model
(COM) cannot create the requested Automation object, and the Automation object is therefore unavailable to Visual Basic. This error does
not occur on all computers.
This article describes how to diagnose and
resolve common problems that may cause this error.
In Visual Basic, there are several causes of error 429. The
error occurs any of the following conditions is true:
There is a mistake in the application.
There is a mistake in the system configuration.
There is a missing component.
There is a damaged component.
To find the cause of the error, isolate the problem. If you
receive error 429 on a client computer, use the following information to
isolate and to resolve the error in Microsoft Office applications.
Note Some of the following information may also apply to non-Office
COM servers. However, this article assumes that you want to automate Office
Examine the code
Before you troubleshoot the error, try to isolate a single line of
code that may be causing the problem.
If you discover that a single
line of code may be causing the problem, complete these procedures:
Make sure that the code uses explicit object creation.
Problems are easier to identify if they are narrowed to a single
action. For example, look for the use of implicit object creation as one of the following.
Code sample 1
Application.Documents.Add 'DON'T USE THIS!!
Code sample 2
Dim oWordApp As New Word.Application 'DON'T USE THIS!!
'... some other code
Both of these code samples use implicit object creation. Microsoft
Office Word 2003 does not start until the variable is called at least one time.
Because the variable may be called in different parts of the program, the
problem may be difficult to locate. It may be difficult to verify whether the
problem is caused when the Application object is created or
when the Document object is created.
Instead, you can
make explicit calls to create each object separately, as follows.
Dim oWordApp As Word.Application
Dim oDoc As Word.Document
Set oWordApp = CreateObject("Word.Application")
'... some other code
Set oDoc = oWordApp.Documents.Add
When you make explicit calls to create each object separately, the
problem is easier to isolate. This may also make the code easier to read.
Use the CreateObject function instead of
using the New operator when you create an instance of an
The CreateObject function
closely maps the creation process that most Microsoft Visual C++ clients use.
The CreateObject function also permits changes in the CLSID of
the server between versions. You can use the CreateObject
function with early-bound objects and with late-bound objects.
Verify that the "ProgID" string that is passed to
CreateObject is correct, and then verify that the "ProgID"
string is version independent. For example, use the "Excel.Application" string
instead of using the "Excel.Application.8" string. The system that fails may
have an older version of Microsoft Office or a newer version of Microsoft
Office than the version that you specified in the "ProgID" string.
Use the Erl command to report the line
number of the line of code that does not succeed. This may help you debug
applications that cannot run in the IDE. The following code tells you which
Automation object cannot be created (Microsoft Word or
Microsoft Office Excel 2003):
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
MsgBox "The code failed at line " & Erl, vbCritical
Use the MsgBox function and the line number to track
Use late-binding as follows:
Dim oWordApp As Object
Early-bound objects require their custom interfaces to be marshaled
across process boundaries. If the custom interface cannot be marshaled during
CreateObject or during New, you receive error
429. A late-bound object uses the IDispatch system-defined interface that does
not require a custom proxy to be marshaled. Use a late-bound object to verify
whether this procedure works correctly.
If the problem occurs only
when the object is early-bound, the problem is in the server application.
Typically, you can reinstall the application as described in the "Examine the
Automation Server" section of this article to correct the problem.
The most common reason for an error to occur with CreateObject or with New is a problem with the server application. Typically, the
configuration of the application or the setup of the application causes the
problem. To troubleshoot, use following procedures:
Verify that the Office application that you want to
automate is installed on the local computer. Make sure that you can run the
application. To do this, click Start, click
Run, and then try to run the application. If you cannot run
the application manually, the application will not work through automation.
Re-register the application as follows:
Click Start, and then click
In the Run dialog box, type the path
of the server, and then append /RegServer to the end of
runs silently. The application is re-registered as a COM server.
If the problem occurs because a registry key is missing,
these steps typically correct the problem.
Examine the LocalServer32 key under the CLSID for the
application that you want to automate. Make sure that the LocalServer32 key
points to the correct location for the application. Make sure that the path
name is in a short path (DOS 8.3) format. You do not have to register a server
by using a short path name. However, long path names that include embedded
spaces may cause problems on some systems.
To examine the path key
that is stored for the server, start the Windows Registry Editor, as follows:
Click Start, and then click
Type regedit, and then click
Move to the HKEY_CLASSES_ROOT\CLSID key.
CLSIDs for the registered automation servers on the system are under this
Use the following values of the CLSID key to find the
key that represents the Office application that you want to automate. Examine
the LocalServer32 key of the CLSID key for the path.
Collapse this tableExpand this table
Make sure that the path matches the actual location of
Note Short path names may seem correct when they are not correct. For
example, both Office and Microsoft Internet Explorer (if they are installed in
their default locations) have a short path that is similar to
X is a number). This name may not initially appear
to be a short path name.
To determine whether the path is correct,
follow these steps:
Click Start, and then click
Copy the value from the registry, and then paste the
value in the Run dialog box.
Note Remove the /automation switch before you run the
Verify that the application runs correctly.
the application runs after you click OK, the server is
registered correctly. If the application does not run after you click
OK, replace the value of the LocalServer32 key with the
correct path. Use a short path name if you can.
Test for possible corruption of the Normal.dot template or
of the Excel.xlb resource file. Problems may occur when you automate Microsoft
Word or Microsoft Excel if either the Normal.dot template in Word or the
Excel.xlb resource file in Excel is corrupted. To test these files, search the
local hard drives for all the instances of Normal.dot or of
Note For systems that run Microsoft Windows 2000 or for systems that
run Microsoft Windows XP, you may find multiple copies of these files. There is
one copy of each of these files for each user profile that is installed on the
Temporarily rename the Normal.dot files or the Excel.xlb
files, and then rerun your automation test. Word and Excel both create these
files if they cannot find them. Verify that the code works. If the code works
when a new Normal.dot file is created, delete the files that you renamed. These
files are corrupted. If the code does not work, you must rename these files
back to their original file names to save any custom settings that are saved in
If your system runs Windows 2000, run the application under
the Administrator account. Office servers require read/write access to the
registry and to the disk drive. Office servers may not load correctly if your
current security settings deny read/write access.
Examine the system
System configuration may also cause problems with the
out-of-process COM servers creation. To troubleshoot, use the following
procedures on the system where the error occurs:
Determine whether the problem occurs with any
out-of-process server. If you have an application that uses a particular COM
server (such as Word), test a different out-of-process server to make sure that
the problem is not with the COM layer itself. If you cannot create an
out-of-process COM server on the computer, reinstall the OLE system files as
described in the "Reinstalling Microsoft Office" section of this article or
reinstall the operating system to resolve the problem.
Examine the version numbers for the OLE system files that
manage automation. These files are typically installed as a set. These files
must match build numbers. An improperly configured setup utility can mistakenly
install the files separately. This causes the files to be mismatched. To avoid
problems with automation, examine the files to make sure that the files builds
The automation files are located in the Windows\System32
directory or in the Winnt\System32 directory. Examine the following
Collapse this tableExpand this table
To examine the file version, right-click the file
in Windows Explorer, and then click Properties. Notice the
last four digits of the file version (the build number) and the date that the
file was last modified. Make sure that these values are the same for all the
Note The earlier version numbers and the earlier dates are retrieved
from a computer that uses a Windows Server 2003 computer with Office 2003
installed. These numbers and dates are just used as examples. Your values may
If the files do not match the build numbers or the
modified dates, download a self-extracting utility that updates your automation
For more information about how to access the run-time files, click the following article number to view the article in the Microsoft Knowledge Base:
Use the System Configuration utility (Msconfig.exe) to examine the services and system startup for third-party applications that might restrict running code in the Office application.
For more information about Msconfig.exe, click the following article number to view the article in the Microsoft Knowledge Base:
How to troubleshoot configuration errors by using the System Configuration utility in Windows XP
For example, Outlook Automation applications may fail because you are running an antivirus program that has "script blocker" features.
Note Only disable the antivirus program temporarily on a test system that is not connected to the network.
Alternatively, follow these steps in Outlook to disable third-party add-ins:
On the Tools menu, click Options.
On the Other tab, click Advanced Options.
In the Advanced Options dialog box, click Add-In Manager.
Click to clear the check box for any third-party add-in.
If this method resolves the problem, contact the third-party antivirus vendor for more information about an update to the antivirus program.
If none of the previous procedures resolve the problem, remove
Office and then reinstall Office. Microsoft recommends that you remove the
existing version first, and then reinstall Office by using the original
For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base: