Winforms: Call to ParkingWindow.RemoveReflectChild() causes Cross-thread exception under load

Created on 4 Mar 2020  路  6Comments  路  Source: dotnet/winforms

  • .NET Core Version:

    Version: 5.0.0-alpha.1.20072.3

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

Problem description:


Call to ParkingWindow.RemoveReflectChild() causes Cross-thread exception under load

Expected behavior:
There should be no error when GC frees the resources.

Minimal repro:
Run WinForms app under load and trigger GC to free resources.

System.InvalidOperationException: 'Cross-thread operation not valid: Control '' accessed from a thread other than the thread it was created on.'
>   System.Windows.Forms.dll!System.Windows.Forms.Control.Handle.get() Line 2502    C#
    System.Windows.Forms.Primitives.dll!Interop.User32.GetWindowThreadProcessId(IHandle hWnd, out uint lpdwProcessId) Line 17   C#
    System.Windows.Forms.dll!System.Windows.Forms.Application.ParkingWindow.RemoveReflectChild() Line 81    C#
    System.Windows.Forms.dll!System.Windows.Forms.Control.ReflectParent.set(System.Windows.Forms.Control value) Line 3137   C#
    System.Windows.Forms.dll!System.Windows.Forms.Control.UpdateReflectParent(bool findNewParent) Line 11630    C#
    System.Windows.Forms.dll!System.Windows.Forms.Control.Dispose(bool disposing) Line 5188 C#
    System.ComponentModel.Primitives.dll!System.ComponentModel.Component.~Component() Line 22   C#
    [Native to Managed Transition]  
bug regression

Most helpful comment

PR #2304 changed more calls in the same way, no idea how many of those can cause regressions though.

All 6 comments

We regressed in https://github.com/dotnet/winforms/commit/e0c9b4bbc7b4096a187f01e85a49af0b02cf387f?file-filters%5B%5D=.cs&hide-deleted-files=true&w=1#diff-94d9dca766d028c738c6c3989035f87c
image
And there is a similar change few lines below. We need to revert these back to new HandleRef(this, HandleInternal).

I checked v3.x are unaffected, which is good.

PR #2304 changed more calls in the same way, no idea how many of those can cause regressions though.

We will have to check and compare against v3.1 to see how may similar changes we made, and reconcile each one.

#2961 may be another case of this regression, this time not from finalizer but from Dispose calls.

2961 seems to be not another case of this refactoring regression as it apparently also repros in Desktop Framework.

QA passed: issue is fixed and no regression is found: #2951.

Was this page helpful?
0 / 5 - 0 ratings