We have an MFC 8 compiled with / CLR that contains more Windows Forms UserControls, which again contain WPF user controls using ElementHost. Due to the architecture of our software, we cannot use HwndHost directly. We have observed here extremely strange behavior that we cannot understand:
When the processor load is very high during application startup, and there are many instances of ElementHost, the entire property engine completely stops working. For example, an animation that usually just works fine now never updates the values of related properties, they just stay at some random value after starting. When I set a property that is not tied to anything, the value is correctly stored in the dependency property (calling getter returns a new value), but the visual representation never reflects this. I set the background to red, but the background color does not change.
We tested this on many different machines running Windows XP SP2, and this is pretty reproducible.
The funny thing is that in fact there is one situation where the related properties actually capture a new value from the animation, and the visual is updated based on the values of the properties. This is when I resize the ElementHost element or when I hide and revise my own parent control. As soon as I do this, the properties associated with the animation will get a new value and rerender visualization based on the new property values - but only once - if I want to see another update, I need to resize the ElementHost element.
Do you have any explanation of what might be happening here, or how could I approach this problem to find out? What can I do to debug this? Is there a way to get more information on what WPF actually does or where WPF may crash? For me, this currently seems like a bug in WPF itself, as it only happens when the CPU load is high at startup.
source
share