Element does not exist or it is virtualized; use VirtualizedItem Pattern if it is supported

Question

We have a WPF application. Some of our customer are getting a crash, which I am not able to reproduce on my machine.All information that I can get from their machine is below stack trace, which contains only WPF code so I actually cannot pin point what code in my application is causing this issue.

System.Windows.Automation.ElementNotAvailableException: Element does not exist or it is virtualized; use VirtualizedItem Pattern if it is supported.
at System.Windows.Automation.Peers.ItemAutomationPeer.ThrowElementNotAvailableException()
at System.Windows.Automation.Peers.ItemAutomationPeer.GetItemStatusCore()
at System.Windows.Automation.Peers.AutomationPeer.UpdateSubtree()
at System.Windows.Automation.Peers.AutomationPeer.UpdateSubtree()
at System.Windows.Automation.Peers.AutomationPeer.UpdatePeer(Object arg)
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)

Does anyone facing the same issue? any help is appreciated. This might be related to windows 10 but I am not sure as my machine is also window 10 but I am not getting this error.

Answer 1

MS support has finally figured out that this is a bug introduced in .Net Framework 4.7 and is still there in 4.7.1 (& most likely in 4.7.2). Unfortunately, on certain Windows 10 versions (Creators Update and above) you can't downgrade to e.g. 4.6.2, so you will have to wait for a (hot)fix. (In my other answer (24 Oct, 2017), I stated that Win7 SP1 with 4.6.1 was also affected, however that turned out to be an invalid .Net Framework installation, where the registry showed 4.6.1 in contrast to the file versions being 4.7.xxxx.)

UPDATE 05/18/2018: @user1336827, @Phillip, @Rhom: I have great news for you: this issue was addressed in the May 2018 quality rollup, see this link and look for 555225.

Answer 2

Same issue here with both Win7 SP1 (w/ .NET 4.6.1) & Win10 Creators Update (.NET 4.7) systems. Can't really explain the presence of UI automation in the faulty process as no automation clients seem to be running.

Anyway, the problem is related to TreeView controls. Can you also confirm this? For TreeViewItem instances, TreeViewDataItemAutomationPeer objects are created (deriving from ItemAutomationPeer, see callstack) and due to a large number of UIElement.OnIsEnableChanged() calls we end up calling AutomationPeer.InvalidatePeer() that BeginInvoke(s) the faulting delegate to the dispatcher with low priority. It seems that by the time those delegates get processed from the dispatcher queue, the automation tree already changes and the parent / child relationship for one of the peers gets broken. This is why the exception is thrown.

Based on a comment from the framework reference source (scroll up a bit), I'd try the following app.config setting:

Add an entry to the appSettings section of the app config file:

<add key="IsVirtualizingStackPanel_45Compatible" value="true"/>