You receive run-time error 429 when you automate Office applications

When you use the New operator or the CreateObject function in Microsoft Visual Basic to create an instance of a Microsoft Office application, you may receive the following error message: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 applications.

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
  oWordApp.Documents.Add

  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 Office application.
  
  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
   	
   	err_handler:
   	  MsgBox "The code failed at line " & Erl, vbCritical

  Use the MsgBox function and the line number to track the error.
• 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.

Examine the automation server

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:
  1. Click Start, and then click Run.
  2. In the Run dialog box, type the path of the server, and then append /RegServer to the end of the line.
  3. Click OK.
     
     The application 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:
  1. Click Start, and then click Run.
  2. Type regedit, and then click OK.
  3. Move to the HKEY_CLASSES_ROOT\CLSID key.
     
     The CLSIDs for the registered automation servers on the system are under this key.
  4. 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

     Office Server	CLSID key
     Access.Application	{73A4C9C1-D68D-11D0-98BF-00A0C90DC8D9}
     Excel.Application	{00024500-0000-0000-C000-000000000046}
     FrontPage.Application	{04DF1015-7007-11D1-83BC-006097ABE675}
     Outlook.Application	{0006F03A-0000-0000-C000-000000000046}
     PowerPoint.Application	{91493441-5A91-11CF-8700-00AA0060263B}
     Word.Application	{000209FF-0000-0000-C000-000000000046}

  5. Make sure that the path matches the actual location of the file.
  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 C:\PROGRA~1\MICROS~X\ (where 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:
  1. Click Start, and then click Run.
  2. 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 application.
  3. Click OK.
  4. Verify that the application runs correctly.
     
     If 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 Excel.xlb.
  
  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 system.
  
  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 these files.
• 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 are matched.
  
  The automation files are located in the Windows\System32 directory or in the Winnt\System32 directory. Examine the following files.
  Collapse this tableExpand this table

  File name	Version	Date modified
  Asycfilt.dll	3.50.5014	September 04, 2002
  Oleaut32.dll	3.50.5016	September 04, 2002
  Olepro32.dll	5.0.5014	September 04, 2002
  Stdole2.tlb	3.0.5014	September 04, 2002

  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 automation files.
  
  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 be different.
  
  If the files do not match the build numbers or the modified dates, download a self-extracting utility that updates your automation files.
  
  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:
  235420  (http://support.microsoft.com/kb/235420/ ) Vbrun60sp4.exe installs Visual Basic 6.0 SP4 run-time files
• 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:
  310560  (http://support.microsoft.com/kb/310560/ ) 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:
  1. On the Tools menu, click Options.
  2. On the Other tab, click Advanced Options.
  3. In the Advanced Options dialog box, click Add-In Manager.
  4. Click to clear the check box for any third-party add-in.
  5. Restart Outlook.
  If this method resolves the problem, contact the third-party antivirus vendor for more information about an update to the antivirus program.

Reinstall Office

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 installation disks.

For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

For more information about troubleshooting the '429' error message, click the following article number to view the article in the Microsoft Knowledge Base: For more information about Office automation and code samples, visit the following Microsoft Web site: