VBA Interface error: Unable to load the project - 0x80004002

I am unable to carry out numerous tasks in Microstation V8i Select Series 3 and I am receiving the following errors in the Message Centre:

VBA Interface error: Unable to load the project - 0x80004002

VBA Interface error: Unable to run macro

When I try to access the Visual Basic Editor, an error also appears saying that there are no loaded projects. This has just recently become an issue, the software was working fine across the business up until the past week or so.

Is this a known issue? Any support would be greatly appreciated.

Kind Regards

Zoe Mair

Trainee Engineering Systems Technician

Amec Foster Wheeler

Oil and Gas

Northern Europe and CIS

City Gate, Altens Farm Road, Nigg

Aberdeen AB12 3LB United Kingdom

(01224 838479

+zoe.mair@amecfw.com

þ amecfw.com

  • A good data point to know for troubleshooting this type of issue is:

     - Is the problem affecting: all users, all locations, and all macros?  Or some users, some locations, some macros, some of the times?

    1. Along the lines of Jon's recommendation if you use MS_VBA_OPEN_IN_MEMORY you may want to see if the value was modified.  Most larger organizations will set it to "ALL" to allow 20+ users to open the same macro over a network share and avoid file server quota restrictions.  This has helped at times with VBA Interface errors: 0x80004002, 0x80004003.

    2. Check to see if re-registering the Microsoft VBA engine can help correct the issue.  Simply start MicroStation using Run as Administrator within the current user account.  This action will permit MicroStation to re-register the Microsoft VBA engine and correct any necessary/required registry keys that a restricted user normally would not have permission to set/correct and be somewhat difficult for most to detect the underlying issue(s).

    3. If there is no evidence your configuration was modified I always recommend the following Microsoft Administrative steps be performed as the first step for VBA project Load or Run issues - testing on one client then deploying similar actions once proven to correct the issue:

    1. Run Microsoft Update to ensure the client is current with all Microsoft Windows updates
    2. Similarly, ensure the client is current with all Microsoft Office updates
    3. Lastly, apply the appropriate Microsoft Office Hot fix for your version of Microsoft Office

    MS12-060: Description of the security update for Office 2010, 2007, and 2003 respectively (August 14, 2012)
    https://support.microsoft.com/kb/2597986
    https://support.microsoft.com/kb/2687441
    https://support.microsoft.com/kb/2687323

    4. Lastly though not likely and would only affect a few fringe cases, determine if the Microsoft KB3057839 security patch is installed.  This has been known to affect some GUI applications when started as or through a Microsoft service and the application would appear to almost immediately not start or hang in Windows Task Manager.

    UPDATED NOTE with respect to option #4

     

    A few users having reported MicroStation hanging on startup when running a MicroStation VBA autoload project started through the Windows Task Scheduler (non-interactively) affected by Microsoft security patch KB3057839 have reported after installing Microsoft updates containing Microsoft security patch 3070102 resolved the issue.

    HTH,
    Bob



  • Unknown said:
    This has just recently become an issue, the software was working fine across the business up until the past week or so

    Probably someone reconfigured something, somewhere, that affects MicroStation.  Perhaps IT has changed the network; perhaps a CAD administrator has modified one of your group's MicroStation configuration files.  It's hard to say.

    My guess is that either MicroStation configuration variable MS_VBASEARCHDIRECTORIES has been redefined to an incorrect value, or it may be pointing to an invalid location if the network was reconfigured.  Either way, you (or your CAD administrator) should analyse MicroStation's configuration to find what has changed.

    Use the -msdebug command-line switch to obtain a text list of configuration variables that you can pore over.  Here's an article that explains how to get an msdebug.txt dump.

    You can use this freeware app. Configuration Verifier to test an individual configuration variable such as MS_VBASEARCHDIRECTORIES.  However, since it is itself a VBA project, it can't help you in this situation.

     
    Regards, Jon Summers
    LA Solutions