Backgroud: We are developing AutoCAD and Revit plugins which connect web applications to the host software. In these plugins we use EO Web Browser component for displaying the web content. There can be multiple plugins with different EO versions on the same AutoCAD/Revit runtime, therefore we are using a specific EO versions directly from GAC.

Issue: However there seems to be a (new?) issue on the AutoCAD side. Which causes the EO Web Browser component to fail worker process initialization. This happens only if a plugin with newer EO DLLs is loaded before the plugin with older EO DLLs. If the older is loaded first then both versions are loaded successfully and they work as expected within the application session like in the picture below (see link). This issue cannot be reproduced on Revit side, with similar test setup. For some reason EO DLL behave differently in these environments.

AutoCAD two EO versions sucessful.png

Additional Info: We are currently creating eowp.exe on the fly with InitWorkerProcessExecutable but this also occurs if O.Base.Runtime.EnableEOWP=true is used (or any combo of the two).


Please help us solve this issue. This is now preventing us from updating the EO component on the AutoCAD side and causes many unnecessary support cases. What does Error code 87 mean?


HW and SW Info:
- Windows 10, 1803 (can be reproduced with other as well)
- AutoCAD 2019 (P.46.0.0) (can be reproduced with other AutoCAD versions like 2020 as well)
- New EO 2019.1.25.0
- Old EO 19.0.83.0

Error occurred! ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Exception: Failed to create child process, Win32 Error: 87
at EO.Internal.js.a(Exception A_0, Boolean A_1)
at EO.Internal.js.b(String A_0, Boolean A_1)
at EO.Internal.js.g..ctor(js A_0, String A_1, String A_2, String A_3)
at EO.Internal.js.a(k A_0, a0b A_1, String A_2, String A_3)
at EO.Internal.js.a(Boolean& A_0, bal[] A_1, String A_2, String A_3)
at EO.Internal.js.a(bal[] A_0, String A_1, String A_2)
at EO.Internal.js.p.c()
at EO.Internal.js.p.f()
at EO.Internal.js.o()
at EO.Internal.js.a(Boolean& A_0, bal[] A_1, String A_2, String A_3)
at EO.Internal.js.a(bal[] A_0, String A_1, String A_2)
at EO.Internal.av8.b()
at EO.Internal.av8.a(WindowsIdentity A_0)
at EO.WebEngine.Engine.Start(WindowsIdentity user)
at EO.Internal.av8.c()
at EO.Internal.cv..ctor(WebView A_0)
at EO.WebBrowser.WebView.u()
at EO.WebBrowser.WebView.a(IntPtr A_0, Boolean A_1)
at EO.Wpf.WebViewHost.b.a()
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Delegate.DynamicInvokeImpl(Object[] args)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.DispatcherOperation.InvokeImpl()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at MS.Internal.CulturePreservingExecutionContext.Run(CulturePreservingExecutionContext executionContext, ContextCallback callback, Object state)
at System.Windows.Threading.DispatcherOperation.Invoke()
at System.Windows.Threading.Dispatcher.ProcessQueue()
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
at System.Windows.Window.ShowHelper(Object booleanBox)
at System.Windows.Window.ShowDialog()
at MyProject.MyBrowser.ShowDialog(params string[] list) in D:\MyProjects\MyProject\MyBrowser.xaml.cs:line 200
...

1. How would this help? This would cause issues when loading the different versions of EO DLLs into the host process. I'm confident that using GAC is not an issue here and in our case it is pretty much mandatory. If using GAC would be the issue then loading the EO DLLs even once from GAC would be a problem right? We can also use the same EO version and some times even different versions at the same runtime without any issues. (Please see our test results below)

2. We are creating eowp.exes in separate folders at plugin startup and with different names. We have now also added the EO version number to the names just to be safe. This has had no effect.

3. Insulating either the "entire plugin" or just the module that utilizes EO web browser using new AppDomain would require huge changes to application architecture which would beat the point. It would be much easier for us to switch to different web browser than do this for all of our products utilizing EO web browser. We need to access the Host application (AutoCAD/Revit) APIs and we need to utilize quite many EO DLL features in synchronicity. Creating a marshalled interface in between is huge undertaking and we are not keen on doing that.

We commenced more tests and we noticed that something has changed regarding the eowp.exe use in the 2019.1.25 version. It seems that you might have inadvertently (since no mention in the change logs) fixed this issue, at least partly. See the picture below for our test results.

EO Launch Order Test Results.png

Here are all the error messages from different versions:
- Error from EO 17.2.43
- Error from EO 18.1.31
- Error from EO 18.3.46
- Error from EO 19.0.83
- Error from EO 19.1.25
- Error from EO 19.1.40

We are now able to reproduce this issue even when utilizing EO DLLs from different applications / processes.

EO Cross App Test Results.png

EO Test Rig Git-Repo
git clone https://LariAtMagiCAD@bitbucket.org/LariAtMagiCAD/eotestrig.git

I'm glad that the issue will be fixed. Just be sure, does this fix also prevent version 19.1.25 (or .40) from connecting to new 2019.2.x pipe?

Here is some additional information that I hope will be helpful:
- The errors I listed in my previous post for 19.1.25 and 19.1.40 didn't contain "Win32 Error: 87". Are these errors still related to this same issue or is it a separate one?
- I was eventually able to get the Win32 Error: 87 on the latest versions as well. When performing the cross-app testing.

Hi,

We have posted a new build that should resolve this issue. You can download the new build from our download page. Please take a look and let us know how it goes.

Thanks!

Great. Thanks for confirming!