Metastorm Designer 9 on x64/64-bit

I’ve seen a few blog posts and have ran into this problem myself.  Metastorm v9 will run fine on an x64 system architecture, but the designer has one problem with this.  When it comes to deploying your Metastorm solution, the deployment fails and doesn’t tell you much about why it has.  For those developers who know anything about Windows, you know to go look in the Application Event Log and read the issue logged.  It probably says something along the lines of :

System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {0E59F1D5-1FBE-11D0-8FF2-00A0D10038BC} failed due to the following error: 80040154

The Metastorm Designer itself runs within a 64-bit process and you can tell this my opening up task manager and noting that it does not have a *32 next to the Designer.exe process (which would indicate it was running in 32-bit).  When the Designer attempts to use a COM object that will only run within a 32-bit process, it fails to instantiate / create an instance of that COM object.  The CLSID (Class ID) shown in the event log error above is the unique ID of the COM component that is unable to be loaded (this ID also stored in the registry as COM components must be registered unlike .NET components).

The offending COM object, is the MSScriptHost / Script Control, which is used to interpret windows scripts written in JScript and VBScript.  .NET Interop is the set of services that allows .NET to easily wrap COM Servers exposing a simple .NET interface (aka a .NET Callable Wrapper) that can be used via .NET applications.  Metastorm v9 is written in .NET and communicates with the required COM components in this way.

You can see from the following stack trace that Metastorm attempts to validate the client side scripts before the issue occurs:

at System.Activator.CreateInstance(Type type, Boolean nonPublic)
at Metastorm.Common.Scripting.Interop.ScriptHost.MSScriptHost..ctor()
at Metastorm.Model.Scripts.Validation.ClientScriptValidator.CompileClientScript()

The quick fix here is to install the designer on a 32-bit machine and reference the 64-bit engines repository service.



  1. Hi,

    I also facing the problem with automating word from metastorm v9, i have referred the Microsoft.Office.Interop.Word assebly as well correctly. Also process deployed successfully.

    But it’s not opening the word document as intended. After i read your tips, I cheked the configuration.

    Metastorm v9 installed in 64bit windows (server), but client machine is in 32 bit.

    This may be the reason?
    Please give some more information to fix this.

    Thanks in advance

    1. Hi,

      It all depends on what you’re doing on the server with the word doc (any kind of processing?). I assume you’re opening the word docs on the client from a shared location on the network (or Metastorm server?). If the client is on 32-bit then the client can easily open the doc from a share (via the active x shell component, but then as ActiveX would be enabled on the client, you may some security risks to deal with here). From what you write, it sounds like you are editing or building a word doc on the server using a .NET callable wrapper (the interop assemblies you mention) with the native office object model / COM objects and doing this from your own custom C# running within the CLR on the Metastorm server? As you have control of how you invoke the office functionality (unlike the issue highlighted in this post) you can always come up with a ‘middle man’ solution. I would assume the C# when it is compiled to MSIL will be compiled to run on the processor detected on the Metastorm server, in your case 64-bit and also be executed on a 64-bit thread within a 64-bit process? (Don’t quote me on this though!). What you could do however is have the C# code within Metastorm server scripts reference a new middle tier assembly that you target as either all processors or 32-bit only and then from this new assembly talk to the interop/COM office objects.


  2. Hi,

    Thanks for the reply.

    I checked the window log file, there is no logs mentioning exception in opening the com object.

    Seems to be configuration is fine, is there any other place we have to check?

    As i said it’s deploying properly, in the time of opening the word its showing the exception like “Object reference not set to an instance of an object”

    Any solution?


    1. Hi Dan,

      The designer will run, but client side script validation and deployment may throw up issues. Also the article relates to v9.0, what version are you on and are you able to deploy ok to the local repository?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s