IAccessible on Windows 8.1 and uiautomation reference leaks causing crashes in our applications.

Question

We have started crashing on Windows 8.1 and I have traced the problem to uiautomation.dll and combase.dll. The root cause of the problem is reference counting. It appears that on Windows 8.1 uiautomation is using keyboard hooks and other means to constantly
query for interfaces leading to reference leaks on UI objects. We use MFC and have code that has relied on reference couting to to lead to calls to DestroyWindow. However on Windows 8.1, in cases where we expect, and historically have had, the window get destroyed,
we have windows now hanging around due to elevated reference counts. I can set breaks in the MFC oleunk.cpp and monitor the reference count going up in CCmdTarget::ExternalAddRef for say, a command bar (menu) and after constantly clicking the menu, the reference
count just keeps increasing and increasing. I can quite quickly cause the reference count to zoom into the hundreds. We started getting reports of crashes on Windows 8.1 from customers and at first I didn't duplicate the issue. Then my Windows 8.1 box rebooted
on me (that's another issue as it did so on its own even though I said to defer the restart and I lost data thanks to that nasty Win 8 feature) and after updates installed, I could easily duplicate the crash.
 The version now installed for uiautomation is "7.2.9600.17415 (winblue_r4.141028-1500)" and "6.3.9600.17415 (winblue_r4.141028-1500)" as seen from the Visual Studio debugger's modules window. I do see some release calls coming from
a function named "AccessibleObjectFromWindowTimeOut" and wonder what the "TimeOut" implies. That is because the easiest way for a user to crash our app on Windows 8.1 is to use GoToMeeting on Windows 8.1 and invite a participant to take
control of the application. I can also crash on Windows 8.1 simply by setting various break points and trace points to print messages as I track what is going on. That is, the crashes appear to be dependent on some sort of race condition and the debugger interferes
with the proper functioning of whatever is occurring inside uiautomation and combase. I have never seen the debugger "interfere" with a process in this way. I can run the same app and perform the same tasks on Windows 7 and these calls that cause
the ref count to constantly increase simply are not made (and combase.dll doesn't get injected into our process on Windows 7). I think Microsoft needs to look into what they are doing on Windows 8 and start releasing interfaces they are leaking when obtaining
the IAccessible interface from windows that implement it.
R.D. Holland

Answer 1

A dump file doesn't show the cause of the crash - an ever increasing reference count. I changed an implementation of OnGetObject (MFC API) and and didn't return the IAccessible interface and the reference count remained the same on Windows 8.1 as it does
on Windows 7. I did that after tracing the ever increasing reference count to calls to get IAccessible coming from those MS DLLs. Eventually I made sure we destroy the window when we think it should be destroyed instead of relying on the MFC reference counting
mechanism. We have testing code that relies on UI automation so just refusing to give out IAccessible isn't an option as I don't know the context of the request.
R.D. Holland