UI Automation can cause unbounded memory consumption

• .NET Core Version: 3.1.200

• Have you experienced this same bug with .NET Framework?: Yes

Problem description:

The WinForms control expose UI Automation interfaces through WM_GETOBJECT. They, however, don’t call the UiaDisconnectProvider API when the controls are destroyed (SDK sample). It does call UiaReturnRawElementProvider as specified in the documentation but that does not release any providers that are still held by the UI Automation clients. The clients can still hold on to the COM objects and thus keep the lifetime much longer than the actual lifetime of the controls and forms. This is problematic because it can cause massive memory consumption because the controls and forms cannot get garbage collected.

The old way of handling this was breaking up the references between the automation proxies and the actual controls and returning UIA_E_ELEMENTNOTAVAILABLE error from the COM entry points. This could possibly be implemented in quite transparent way in the InternalAccessibleObject class.

The newer way of handling this is asking UIA to release any references to the interface when the form/control is destroyed using the UiaDisconnectProvider API.

The behavior can be checked by the VisualUIAVerifyNative.exe tool that is part of the Windows SDK.

Examples:

Label control on a live form in UIA Verify:

Label control on a closed form in UIA Verify:

Different control in UIA Verify after the form was closed and UiaDisconnectProvider was called:

Expected behavior:

UI Automation clients should not leak memory through the server-side UIA providers on disposed controls.

[weltkante]

In some cases we saw UIA calls even if the customer claimed not to use any screen reader software.

When I’ve been debugging WinForms going through automation API was the common case not the exception. Windows itself is very happy to use UI automation for various purposes, for example the onscreen keyboard will go through the automation API, there are probably more common tools that use it but I’m not actively aware of them, mostly because I didn’t bother figuring out who is causing the automation API calls. (I’m only aware of the onscreen keyboard because it broke our DevExpress based application once and I had to figure out what happened.)

PS: above statement doesn’t differentiate between individual automation APIs, I’m just talking about automation as a concept being commonly activated these days.

[RussKie]

@merriemcgaw