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?

to my knowledge, the user simply clicked the "OK" button which closes the window with the XamDataTree in it, so, yes, the XamDataTree would be unloaded.  don't know about any screen reading stuff...

The screen reading would most likely be a background process.  Your users might not even know it's running.  I'm building a simple sample with a XamDataTree in a separate window and I'll test it by having a screen reading application such as Microsoft Narrator open in the background to see if that reproduces this when I close the window.  I will keep you updated.

ok thanks Rob!  my only fear is, if the user doens't even know this background process is running, how can i avoid this error cropping up?

Any update on this?  The error occurs every time when the application is run in Windows Server 2008R2 Standard ,but not in Win7 on my development machine.  I need a workaround or resolution FAST!

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.

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.