Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix for #1198 - fixes potential crashes in high-DPI applications #1515

Merged

Conversation

vatsan-madhavan
Copy link
Member

@vatsan-madhavan vatsan-madhavan commented Aug 2, 2019

Addresses #1198.

[Watson] clr20r3: CLR_EXCEPTION_System.Collections.Generic.KeyNotFoundException_80131577_PresentationCore.dll!MS.Internal.DpiUtil+DpiAwarenessScope..ctor

--

When a caller passes in dpiAwarenessContextValue==Invalid, new DpiAwarenessContextHandle(dpiAwarenssContextValue) throws KeyNotFoundException.

This happens because we do not have a pre-created pseudo-HANDLE corresponding to Invalid in our internal map of pseudo-handles in DpiAwarenessContextHandle.WellKnownContextValues. Such a pseudo-handle cannot be created either.

When dpiAwarenessContextValue=Invalid is passed, the correct behavior is to treat it as a no-op and simply return. The corresponding Dispose() will also run benignly and the caller will get the correct behavior - which is that no changes will be made to the thread-state.

[Watson] clr20r3: CLR_EXCEPTION_System.Collections.Generic.KeyNotFoundException_80131577_PresentationCore.dll!MS.Internal.DpiUtil+DpiAwarenessScope..ctor
--

When a caller passes in `dpiAwarenessContextValue==Invalid`, `new DpiAwarenessContextHandle(dpiAwarenssContextValue)` throws `KeyNotFoundException`.

This happens because we do not have a pre-created pseudo-_HANDLE_  corresponding to `Invalid` in our internal map of pseudo-handles in `DpiAwarenessContextHandle.WellKnownContextValues`. Such a pseudo-handle cannot be created either.

When `dpiAwarenessContextValue=Invalid` is passed, the correct behavior is to treat it as a no-op and simply `return`. The corresponding `Dispose()` will also run benignly and the caller will get the correct behavior - which is that no changes will be made to the thread-state.
@ghost ghost requested review from rladuca, ryalanms and stevenbrix August 2, 2019 23:41
@ghost ghost added the PR metadata: Label to tag PRs, to facilitate with triage label Aug 2, 2019
@ghost ghost requested a review from SamBent August 2, 2019 23:41
@vatsan-madhavan
Copy link
Member Author

For reference, this is what a typical crash-stack will look like (this is a .NET Framework crash stack):

mscorlib.ni!System.Collections.Generic.Dictionary_2[[MS.Utility.DpiAwarenessContextValue,_WindowsBase],[System.IntPtr,_mscorlib]].get_Item
at PresentationCore.ni!MS.Internal.DpiUtil in DpiUtil+DpiAwarenessScope.cs
at PresentationFramework.ni!System.Windows.SystemResources.CreateResourceChangeListenerWindow in SystemResources.cs
at PresentationFramework.ni!System.Windows.SystemResources.EnsureResourceChangeListener in SystemResources.cs
at PresentationFramework.ni!System.Windows.SystemResources.GetDpiAwarenessCompatibleNotificationWindow in SystemResources.cs
at PresentationFramework.ni!System.Windows.Interop.HwndHost.BuildOrReparentWindow in HwndHost.cs
at PresentationFramework.ni!System.Windows.Interop.HwndHost.OnSourceChanged in HwndHost.cs
at PresentationCore.ni!System.Windows.SourceChangedEventArgs.InvokeEventHandler in SourceChangedEventArgs.cs
at PresentationCore.ni!System.Windows.RoutedEventArgs.InvokeHandler in RoutedEventArgs.cs
at PresentationCore.ni!System.Windows.RoutedEventHandlerInfo.InvokeHandler in RoutedEventHandlerInfo.cs
at PresentationCore.ni!System.Windows.EventRoute.InvokeHandlersImpl in EventRoute.cs
at PresentationCore.ni!System.Windows.UIElement.RaiseEventImpl in UIElement.cs
at PresentationCore.ni!System.Windows.UIElement.RaiseEvent in UIElement.cs
at PresentationCore.ni!System.Windows.PresentationSource.UpdateSourceOfElement in PresentationSource.cs
at PresentationCore.ni!System.Windows.PresentationSource.RootChanged in PresentationSource.cs
at PresentationCore.ni!System.Windows.Interop.HwndSource.set_RootVisualInternal in HwndSource.cs
at PresentationCore.ni!System.Windows.Interop.HwndSource.Dispose in HwndSource.cs
at PresentationCore.ni!System.Windows.Interop.HwndSource.OnHwndDisposed in HwndSource.cs
at WindowsBase.ni!MS.Win32.HwndWrapper.Dispose in HwndWrapper.cs
at WindowsBase.ni!MS.Win32.HwndWrapper.WndProc in HwndWrapper.cs
at WindowsBase.ni!MS.Win32.HwndSubclass.DispatcherCallbackOperation in HwndSubclass.cs
at WindowsBase.ni!System.Windows.Threading.ExceptionWrapper.InternalRealCall in ExceptionWrapper.cs
at WindowsBase.ni!System.Windows.Threading.ExceptionWrapper.TryCatchWhen in ExceptionWrapper.cs
at WindowsBase.ni!System.Windows.Threading.Dispatcher.LegacyInvokeImpl in Dispatcher.cs
at WindowsBase.ni!MS.Win32.HwndSubclass.SubclassWndProc in HwndSubclass.cs

@vatsan-madhavan vatsan-madhavan added this to the 3.0 milestone Aug 2, 2019
@vatsan-madhavan vatsan-madhavan added the tell-mode Issues and PR's that require notice to .NET Core Shiproom label Aug 2, 2019
@vatsan-madhavan vatsan-madhavan merged commit 3a6a7f1 into master Aug 5, 2019
@vatsan-madhavan vatsan-madhavan deleted the dev/vatsan/dpiawarenesscontextvalue-crash-fix branch August 5, 2019 21:50
@ghost ghost locked as resolved and limited conversation to collaborators Apr 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
PR metadata: Label to tag PRs, to facilitate with triage tell-mode Issues and PR's that require notice to .NET Core Shiproom
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants