1

We have a bigger software running on Win CE6 without problems. The core functionality is implemented in a COM server DLL that provides connection points. The COM client program registers event handlers for the connection points on program startup to get status notifications etc. On program exit it unregisters the handlers by calling the corresponding IConnectionPointImpl::Unadvise methods.

Now, we are porting the program to run on Win EC 7. The new Board Support Package (BSP) for Win EC 7 works well. There are also different versions with different options, created at different times with different sources from Microsoft, but our software always show the same issue.

On program startup, ~10s after launch, IConnectionPointImpl::Unadvise is called unexpectedly on all registered event handlers. We only have one method in our source code that calls IConnectionPointImpl::Unadvise and this is definitely not executed.

The issue appears ~95%, but sometimes the program starts and runs without problems. We cannot use the Debugger because of the size of the program, the performance is very poor.

We guess, that the COM runtime calls the IConnectionPointImpl::Unadvise methods for some reasons. But we have no idea, how to prevent this.

Has anybody observed the same issue? Is there a solution/workaround available? Thanks.

KBO
  • 653
  • 7
  • 17
  • I have almost the same problem on Win10... Did you find a solution to this ? – David Aug 04 '20 at 12:36
  • @David: As a workaround, we replaced the COM connection points by ordinary callbacks, that works fine on CE 6, EC 7 and 2013. For the connection point issue itself we did not found a solution. – KBO Aug 05 '20 at 05:16
  • Arf, I'm not able to do that... So we will continue to search. If we found a solution, I will put it here ;) – David Aug 05 '20 at 09:25
  • Thanks und good luck! – KBO Aug 05 '20 at 12:28
  • We finally found the source of this problem. It come from an inheritance of `MarshalByReObject` on a class when we use this class inside a custom AppDomain. We still search for a workarround. – David Aug 11 '20 at 08:23

1 Answers1

0

So we finally found how solve this problem.

We remove our dependency on MarshalByReObject and replace it by a proper implementation of ISerializable.

That allow us to load properly inside custom AppDomain our assembly and events are not loose anymore.

But this has a side effect on path where assembly a configuration file are loaded. To solve this we also implement an AppDomain.AssemblyResolve event which allow us to redirect the loading in a proper place.

I hope this can help you ;)

David
  • 1,177
  • 3
  • 11
  • 26