DataGridView: Excessive CPU+memory usage when closing form

[dpmm99]

The root cause seems to be that this enumeration clones every row and cell in the DataGridView.

The result is it takes ~12 minutes and ~8 GB extra memory just to dispose a DataGridView with ~700k rows.

Abbreviated stack trace:
DataGridViewRowCollection.this[int].get(int index) Line 137
DataGridView.ReleaseUiaProvider(HWND handle) Line 25605
Control.WmDestroy(ref Message m) Line 11463

Workaround: setting every DataGridView's DataSource = null in the FormClosing event eliminates the issue. That seems to imply there's another problem with consistency--if ReleaseUiaProvider needs to be called for every single cell during WmDestroy, why wouldn't it be needed when clearing the DataSource?

[merriemcgaw]

@LeafShi1 can you take a first look at this?

[LeafShi1]

The direct cause of this problem is the use of foreach (DataGridViewRow row in Rows) in the DataGridView.ReleaseUiaProvider() method to iterate through all rows and release the UIA provider.

This iteration uses the collection's UnsharingRowEnumerator, which forces each row to be materialized from a shared row to a non-shared row (via the Rows[i] indexer), even if these rows remain shared during runtime.

// Original code
foreach (DataGridViewRow row in Rows) // Here, Rows returns an UnsharingRowEnumerator object with 700,000 rows
{
// Each iteration triggers the following chain:
// 1. IEnumerator.Current is accessed
// 2. UnsharingRowEnumerator.Current → return _owner[_current]
// 3. DataGridViewRowCollection[index] indexer is called
// 4. row.Index == -1 is detected (shared row flag)
// 5. The entire row + all cells are cloned
// 6. The DataGridView is re-associated, and all relationships are set
}

Call stack:

System.Windows.Forms.dll!System.Windows.Forms.DataGridViewRowCollection.this[int].get(int index) Line 137 C#
System.Windows.Forms.dll!System.Windows.Forms.DataGridViewRowCollection.UnsharingRowEnumerator.System.Collections.IEnumerator.Current.get() Line 66 C#
System.Windows.Forms.dll!System.Windows.Forms.DataGridView.ReleaseUiaProvider(Windows.Win32.Foundation.HWND handle) Line 25605 C#

Demo project:

WinFormsApp7.zip

[kirsan31]

The regression was introduced in this commit from this PR.

Iterating over rows/cells of DGW is forbidden, except cases with small data and if you absolutely sure what you are doing. This is the law :)

I don't know the mechanics of AccessibilityObjects here - can we clear them through SharedRows? Or may be clearing needed for unshared rows only? If not, then we need to track each created object...

[kirsan31]

@dpmm99

Workaround: setting every DataGridView's DataSource = null in the FormClosing event eliminates the issue. That seems to imply there's another problem with consistency--if ReleaseUiaProvider needs to be called for every single cell during WmDestroy, why wouldn't it be needed when clearing the DataSource?

Welcome to #6859 😢
And after this workaround (when using accessibility objects of course) you should get a memory leak like in #7349?

[LeafShi1]

This problem is not limited to the ReleaseUiaProvider call itself. When the Form is loaded while Accessibility Insights is running, it automatically walks the entire UIA tree. As a result, the application creates AccessibilityObject instances for all Visible rows during startup. This leads to an unavoidable delay when those objects are released later, as illustrated in the screenshot below.

AccessibilityInsight.mp4

Inspect.mp4

I experimented with several possible approaches to reduce the release overhead:

1. Track rows that created DataGridViewRowAccessibilityObject
   I used a HashSet<DataGridViewRow>? rowsWithAccessibility to record rows when their accessibility objects were created, and then only released those rows in ReleaseUiaProvider instead of iterating over all rows.
   However, when the dataset is large, releasing these objects still takes noticeable time.

2. Deduplicate shared rows (SharedRow) during ReleaseUia
   I applied a HashSet to deduplicate rows with the same index.
   The performance result was essentially the same as approach (1).

After testing, the most effective approach is:

3. Create AccessibilityObject only for Displayed rows, not all Visible rows.
   This significantly reduces both creation and release time.
   However, this means the generated UIA tree is incomplete, and I am not sure whether this behavior complies with UIA requirements.

4. Alternatively, the client must paginate the displayed data.

@KlausLoeffelmann Do you have any good suggestions?

[kirsan31]

Theoretically and ideally AccessibilityObject manipulations must take sharing logic into account:

1. Not trigger unsharring by themself in any case.
2. I'm not sure, but it seems to me that AccessibilityObject should be created only for unshared rows? May be for unshared + Displayed as @LeafShi1 suggested...