Logo
My Account |  Site Map | Contact Us  
Welcome Guest Search | Active Topics | Sign In | Register

Failed to create child process, Win32 Error: 87 Options
Lari
Posted: Monday, May 6, 2019 9:29:41 AM
Rank: Newbie
Groups: Member

Joined: 5/6/2019
Posts: 5
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
...
eo_support
Posted: Monday, May 6, 2019 10:00:21 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 21,360
Hi,

This appears to indicate that Windows API CreateProcessEx has failed. The error indicates that either the lpCommandLine argument or the lpCurrentDirectory is invalid. The lpCommandLine is affected by InitWorkerProcessExecutable. Where as lpCurrentDirectory is derived from the location of EO.Base.dll. So you can try to change things that may affect these to see if you can void the problem:

1. Try not use DLL from GAC. Uses a local copy instead;
2. Make sure you contain version information in the path when you call InitWorkerProcessExecutable since different version of EO DLLs can not use the same eowp.exe (If you use EnableEOWP instead of InitWorkerProcessExecutable, then the automatically created eowp.exe file name will already include version information);
3. Try to run each plugin in their own AppDomain;

Please let us know if this resolves the issue for you.

Thanks!
Lari
Posted: Thursday, May 16, 2019 4:07:49 AM
Rank: Newbie
Groups: Member

Joined: 5/6/2019
Posts: 5
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
eo_support
Posted: Thursday, May 16, 2019 8:26:55 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 21,360
Hi,

We did make some internal change on the internal communication mechanism between the processes but the net result you are seeing is still the same: it can not start child process properly. Is it possible for you to make a test system available to us? We will need to debug on the system in order to get to the bottom of this.

Thanks!
Lari
Posted: Thursday, May 16, 2019 11:16:20 AM
Rank: Newbie
Groups: Member

Joined: 5/6/2019
Posts: 5
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
eo_support
Posted: Thursday, May 16, 2019 6:11:17 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 21,360
Hi,

Thanks for the test app. We were able to identify a problem where one of the inter process communication pipe name did not include version numbers. This would cause one version tries to connect to pipe created by another version and because the data exchanged through the pipe changes from version to version, this would cause serious issues. This issue will be fixed in our next build. Obviously this will not address issues between two past builds, but it should avoid the issue between pass builds and the new builds.

We will post here again once the new build becomes available. In the mean time you can try to run different versions in different AppDomain if that's possible for you. The pipe name does include AppDomain ID. So using them different AppDomain should avoid this issue.

Thanks!
Lari
Posted: Friday, May 17, 2019 2:31:32 AM
Rank: Newbie
Groups: Member

Joined: 5/6/2019
Posts: 5
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.
eo_support
Posted: Friday, May 17, 2019 1:41:06 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 21,360
Hi,

Yes. The fix will prevent any cross version connection as long as one party has the fix. So for example:

1. It will prevent connection between 19.1.25 to 19.2.x because one party (19.2.x) has the fix;
2. It will prevent connection between 19.2.1 and 19.2.2 because at least one party (in fact both parties in this case) has the fix;
3. It will NOT prevent connection between 19.1.25 and 19.1.40 because neither party has the fix;

It doesn't matter which way. Older version incorrectly makes cross version connection because the pipe name in question did not include version numbers. After the fix that includes the version numbers, only the same version can connect. After the fix we tested between older versions and fixed version (not publicly posted yet) and we do not see any issues. So we are assuming the 87 error is related and is fixed unless further test indicates otherwise.

Thanks!
eo_support
Posted: Wednesday, June 19, 2019 12:33:47 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 21,360
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!
Lari
Posted: Monday, June 24, 2019 4:10:37 AM
Rank: Newbie
Groups: Member

Joined: 5/6/2019
Posts: 5
Everything seems to be working now as you promised. Thanks!

EO Launch Order Test Results 2.png
eo_support
Posted: Monday, June 24, 2019 8:32:10 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 21,360
Great. Thanks for confirming!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.