You receive run-time error 429 when you 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 down to a single action. For example, look for implicit object creation that's used 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 that 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 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 the "429" error message. 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 that 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 when you use CreateObject or New is a problem that affects the server application. Typically, the configuration of the application or the setup of the application causes the problem. To troubleshoot, use following methods:

• 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.

     Office server	CLSID key
     Access.Application	{73A4C9C1-D68D-11D0-98BF-00A0C90DC8D9}
     Excel.Application	{00024500-0000-0000-C000-000000000046}
     Outlook.Application	{0006F03A-0000-0000-C000-000000000046}
     PowerPoint.Application	{91493441-5A91-11CF-8700-00AA0060263B}
     Word.Application	{000209FF-0000-0000-C000-000000000046}

  5. Check the path to make sure that it 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 disks for all instances of Normal.dot or of Excel.xlb.
  
  Note 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 revert these files to their original file names to save any custom settings that are saved in these files.

• 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 for the creation of out-of-process COM servers. To troubleshoot, use the following methods on the system on which 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 occuring in 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 incorrectly configured setup utility can mistakenly install the files separately. This causes the files to be mismatched. To avoid problems in automation, examine the files to make sure that the files builds are matched.
  
  The automation files are located in the Windows\System32 directory. Examine the following files.

  File name	Version	Date modified
  Asycfilt.dll	10.0.16299.15	September 29, 2017
  Ole32.dll	10.0.16299.371	March 29, 2018
  Oleaut32.dll	10.0.16299.431	May 3, 2018
  Olepro32.dll	10.0.16299.15	September 29, 2017
  Stdole2.tlb	3.0.5014	September 29, 2017

  
  To examine the file version, right-click the file in Windows Explorer, and then click Properties. Note 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 following files are for Windows 10 Version 1709, build 16299.431. These numbers and dates are  examples only. Your values may be different.

• 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
  
  Note Disable the antivirus program only temporarily on a test system that is not connected to the network.
  
  Alternatively, follow these steps in Outlook to disable third-party add-ins:
  
  If this method resolves the problem, contact the third-party antivirus vendor for more information about an update to the antivirus program.

  1. On the File menu, click Options, and then click Add-ins.

  2. Click Manage COM add-ins, and then click Go.
     
     Note The COM add-ins dialog box opens.

  3. Clear the check box for any third-party add-in, and then click OK.

  4. Restart Outlook.

Reinstall Office

If none of the previous procedures resolve the problem, remove and then reinstall Office.

For more information, see the following Office article:

Download and install or reinstall Office 365 or Office 2016 on a PC or Mac