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