Hi Travis,

AutomationPeer stuff usually means some kind of screen reading is going on with the application.  Some program on the users machine is trying to screen read the application.  Programs like Microsoft's Narrator do this.

Did your users provide any steps for reproducing this?  I understand that you are currently not able to reproduce this but I would like to know what exactly your users were doing with the XamDataTree at the time of the exception.  I see that the XamDataTree Unloaded event was fired.  Was the user changing screens or something which caused the XamDataTree to unload?

Hi Travis,

I tried testing on my Windows 7 machine where I opened a window containing the XamDataTree while I had a screen reading program opened.  I then closed the window but no exception occurred so I didn't reproduce the exception.  Since you stated that the issue occurs on Windows Server 2008R2, I will need to test on this OS next.  I've created a VM so I'll test on there next.

The fastest workaround that I can think of would be to keep the automation peer stuff from being instantiated all together.  To do that you will have to tell the window that there are no controls inside that window.  First create this class: 

public class CustomWindowAutomationPeer : FrameworkElementAutomationPeer
{
    public CustomWindowAutomationPeer(FrameworkElement owner) : base(owner) { }

    protected override string GetNameCore()
    {
        return "CustomWindowAutomationPeer";
    }

    protected override AutomationControlType GetAutomationControlTypeCore()
    {
        return AutomationControlType.Window;
    }

    protected override List<AutomationPeer> GetChildrenCore()
    {
        return new List<AutomationPeer>();
    }
}

Then, inside your window where the XamDataTree is located, override the OnCreateAutomationPeer method: 

protected override System.Windows.Automation.Peers.AutomationPeer OnCreateAutomationPeer()
{
    return new CustomWindowAutomationPeer(this);
}

This code will tell anything that is looking for automation peers in the window that there are no controls from which to get the peers from.  You can give this a try as a workaround while I continue to test using the 2008R2 VM.

Ok.  FYI, I am able to reproduce the error using Win 7 IF i start Microsoft Narrator, so you probably don't need to use your VM etc, just start Narrator.

Hi Travis,

Interesting.  I had tried it with Narrator open on my Win7 machine but couldn't reproduce it.  Here is the sample I used for testing.

Can I get you to try running it on your machine to see if it reproduces the issue?  All the sample has is a window with a button.  When the button is clicked a new window is opened which contains the XamDataTree.  When I close the tree window, I'm expecting to see the exception but I don't.  So either I'm missing some extra step or there is some extra code you have that I don't.

Thanks, your sample runs fine for me as well.  I am trying to get you a sample where the issue occurs, but so far, nothing is reproducing it.  My app is extremely complicated, with separate windows, view models etc, helpers, classes etc, so it my take a while (or never!).  The XamDataTree is contained in a user control.   I also have complicated styles for the XamDataTree and items etc, but even when i removed those in the original app, the error still occurs.  Also, I haven't been able to figure out WHAT the users are doing to make the error appear, since they aren't running Microsoft Narrator.  What else would use AuotmationPeers stuff?  This box has Microsoft Great Plains, Quickbooks, Office, etc, but they either aren't running anything 'special' or don't know they are that uses AutomationPeers.

How can i adapt your suggested workaround for a user control?  I'd rather implement in the offending UserControl, instead of every possible window.

I applied your workaround to a window.  Error still occurs.

Hi Michael,

Do you have a private support case already open for this?  If so, you can give me the number and I'll link your case to the dev issue as well.

Following this, as I have also raised a support issue on this, but couldn't reliably reproduce.

Yeah, that was an error on my part.  Sorry about that.  In the excitement of obtaining a reproducible sample I didn't read through what you said clearly enough.  Thanks for setting me straight.

Yes, i will can use my workaround in the meantime.  It is actually commenting out the .Clear of the collection for the workaround.  So the fix is to NOT clear it, I believe you erroneously stated above the fix was to clear it, it is just the opposite.  If you look in the sample i provided, there are comments in the ConfirmClose method in CompareBillingVM.cs, you will find a comment '

//this ClearAll method is the offender, commenting it out fixes the problem'

commenting out that line allows the code to run without the exception. Inside of ClearAll(), the bound collection is cleared inside a dispatcher.

Thanks again, I am looking forward to a resolution.