3rd party DLL crashes the Metastorm Process Engine...

Hi,

I am trying to get a 3rd party DLL working within a server side script in version 9.2.0.

The DLL has been put in all the relevant directories (Engine/DotNetBin, Designer/Custom, Deployment/Custom) and although intellisense does not bring up the properties and methods, the process deploys.

The problem comes when it runs the code. I have logged each part of the server side code and can see that the object is created and properties set. However, when the method is run, the Metastorm process crashes, bringing down the entire server.

Specifically, the dllhost.exe portion of the system dies, which although this does not terminate the service (which it should, really) does mean that the 'process engine is not available' and the only way to recover is to restart the service.

There are no entries in the eLog table but I get one or other of the following errors in the Event Log:

Faulting application name: dllhost.exe, version: 6.1.7600.1****, time stamp: 0x4a5bc6b7
Faulting module name: ntdll.dll, version: 6.1.7601.1****, time stamp: 0x4ec49b8f
Exception code: 0xc0000005
Fault offset: 0x0003a6c7
Faulting process id: 0xe68
Faulting application start time: 0x01ce400980e43043
Faulting application path: C:\Windows\SysWOW64\dllhost.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll
Report Id: c6506a60-abfc-11e2-8f6a-005056b4332b

Faulting application name: dllhost.exe, version: 6.1.7600.1****, time stamp: 0x4a5bc6b7
Faulting module name: ole32.dll, version: 6.1.7601.1****, time stamp: 0x4ce7b96f
Exception code: 0xc0000005
Fault offset: 0x0004a1f0
Faulting process id: 0xc84
Faulting application start time: 0x01ce4009fa8852a0
Faulting application path: C:\Windows\SysWOW64\dllhost.exe
Faulting module path: C:\Windows\syswow64\ole32.dll
Report Id: 3fe89a74-abfd-11e2-8f6a-005056b4332b

Now, a bit of background on the DLL. This is an interop DLL written in .Net 3.5 that creates and overloads the methods of an ActiveX object, which has been registered on the same server (or another server, it doesnt seem to matter).

Has anyone else come across this issue? Any little bits of advice on how to get this working. We have wasted quite a number of days trying to get this to work all to no avail.

Any suggestions gratefully accepted.

Nils.

---
Note: Some information in this post has been hidden to protect privacy.

Tagged:

Comments

  • Hi Nils,

     

    Have you tried getting this DLL to work outside of BPM?  i.e. reference the DLL in a Visual Studio project and calling it from within there.

     

    Presumming that this DLL is a release version from the 3rd Party and isn't broken, if you can get it to work within Visual Studio then it "should" work fine in BPM, however you could try creating a sort of wrapper DLL of your own in VS, then reference the 3rd party DLL within there.  That is on the basis that it is working within VS.

     

    It's not ideal, but should be a workaround solution for you.

  • Phil,

    Thank you for your response.

    The DLL that I am using in Metastorm is a wrapper DLL for the ActiveX DLL. We had to do this as Metastorm does not support ActiveX objects and it was Support that suggested we create this wrapper / proxy DLL and reference that.

    I have created a stub program within Visual Studio 2010 which contains the same code as in Metastorm and that works without issue.

  • Hi,

     

    Well it sounds like you are on the right track.

    Have you stepped through the code in Visual Studio to make sure it is working fine in isolation? as in outside of Metastorm using VS Unit Test.

     

    Also, you could try wrapping the ActiveX DLL call in a try/catch and write out the error to a local log file.

    As in:

     

    try

    {

      Call();

    }

    catch (Exception ex)

    {

      //File IO stuff to write out ex.Message

    }

     

     

    I've seen in the past .NET 2.0 overflow exceptions crash the engine without logging errors, so it sounds similar to that scenario, but that was ultamitely a data related issue.

     

    Let me know how you get on.

  • This issue has now been resolved. It would seem that there were supporting DLLs missing that were required for the 3rd Party component. They were present in the development environment but not UAT.

    Once we added the DLLs, everything started working.

    Would have been nice to have had more helpful logging and the environment crash being more elegant though!

    Thanks for you help!