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

Applies to: Office 365Office 2016Office 2013

Summary


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:
Run-time error '429': ActiveX component can't create object
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.

More Information


In Visual Basic, there are several causes of error 429. The error occurs if 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 the "429" error message on a client computer, use the following information to isolate and 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 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 codeoWordApp.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.ApplicationDim oDoc As Word.DocumentSet oWordApp = CreateObject("Word.Application")'... some other codeSet 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. For more information about Msconfig.exe, see the following Microsoft Knowledge Base article:
    181966 System Configuration Utility Advanced Troubleshooting Settings
    For example, Outlook Automation applications may fail because you are running an antivirus program that has "script blocker" features.

    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:

References


For more information about Office automation and code samples, go to the following Microsoft website: