[Watson] clr20r3: CLR_EXCEPTION_System.Collections.Generic.KeyNotFoundException_80131577_PresentationCore.dll!MS.Internal.DpiUtil+DpiAwarenessScope..ctor #1198
Comments
|
@grubioe this is marked as area_netfx. IIRC we wanted to fix this in .NET Core but decided that the hit-counts were too low to meet the bar for .NET Framework, right? |
|
Yes, also because it reproduces in .NET Framework, |
[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.
|
We get these exceptions in a .Net 4.7.2 application - is there any way to work around this reliably i.e. by disabling dpi awareness (and if so.. what would be the correct approach)? |
vatsan-madhavan
added
the
tell-mode
|
@jbattermann, I suspect you are on .NET 4.8 runtime - the failing codepath was not introduced until .NET 4.8. Even then, your app has to use a a somewhat complex configuration. It would have to be an app that is (a) per-monitor DPI aware and (b) also mixes unaware child-windows in the same application. Visual Studio may do this; Word can do this sometimes for certain WinForms or WPF based plug-ins, where it will typically use system-aware (not unaware) plug-ins inside per-monitor aware Word application. You can certainly disable DPI awareness as a workaround by changing the application manifest to specify system-awareness (see dpiAwareness) - that should do it. That said, if you are encountering this problem, then you probably have an app that cannot be run only in system-aware mode owing to the fact that it needs to mix windows of different DPI_AWARENESS_CONTEXT's in the same application. All that said, we are working on fixing this in .NET 4.8 as well. |
|
@vatsan-madhavan We're running 4.7.2 all the way (4.8 isn't rolled out in our it environment yet and our .Net applications are 4.7.2 only, too) so the question is, will this be fixed in 4.7.2, too or "only" in 4.8? |
|
@jbattermann, This fix will only be made available for 4.8, because this exact problem cannot exist on 4.7.2. Let me explain. It’s conceivable that a crash involving frame 3 occurs on 4.7.2 runtime, but a crash involving frames 2 or 1 cannot happen on 4.7.2 - the code corresponding to those frames are new in 4.8 (for eg, DpiUtil+DpiAwarenesdScope) and don't exist in 4.7.2. If your crash stack is an exact match, then the underlying runtime has to be 4.8. If the runtime is 4.7.2 , then the crash stack is likely a bit different than the one being discussed here. If the runtime is definitely 4.7.2 and the crash stack is an exact match for this report, then I’m stumped. We’d want to start puzzling out why a 4.8 runtime reports itself as 4.7.2... and go from there. |
|
Ok here's the full stack trace we get in our .Net Application: ... which looks at first and second glance similar? If it does / is to you, as well.. is there a quick way to double check what runtime is being used? The users did/could not run our application before explicitly installing the 4.7.2 runtime though. |
|
https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed describes how to check the version of .NET Framework installed on a machine. |
|
4.7.2 it appears to be: |
|
@BrettLopez - have you heard reports of corrupt .NET 4.8 installations? |
|
Can you also open your application in WinDbg in one of the 4.7.2 reporting systems and look up the version of WindowsBase, PresentaionCore and PresentationFramework (using |
|
@grubioe, Can we create a new issue for this investigation (which could very well be about figuring out corrupt state) in the right netfx 4.8 feedback repo and use that to track progress? |
|
Comment from @BrettLopez (who is have trouble with login, so posting for him):
|
|
@vatsan-madhavan I've inquired with the user directly and asked to get the file(s) / info and will report back as soon as I have them. Thanks so far! |
|
I'm having the same problem on a mixed application WPF+Windows Forms with .NET 4.8 (version 4.8.03761) and windows 10 with the following version: PS C:\Users\LazzaAnd> systeminfo /fo csv | ConvertFrom-Csv | select OS*, System*, Hotfix* | Format-List Here below the stackTrace (it crashes when closing application): System.Transactions Critical: 0 : http://msdn.microsoft.com/TraceCodes/System/ActivityTracing/2004/07/Reliability/Exception/UnhandledUnhandled exception4GE.exeSystem.Collections.Generic.KeyNotFoundException, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089The given key was not present in the dictionary. at System.Collections.Generic.Dictionary I found a workaround. AppContextSwitchOverrides value = "Switch.System.Windows.DoNotScaleForDpiChanges=true; Switch.System.Windows.DoNotUsePresentationDpiCapabilityTier2OrGreater=true" Do you plan a fix for .NET 4.8? |
|
@AndreaLazz The fix for .NET 4.8 will be coming out soon. |
|
Thank you for your information. |
|
We have reproduced and this becomes the top crash in our product Microsoft Advertising Editor. and we are targeting 4.7.1 .NetFramework. Currently we cannot offer upgrading to 4.8 even the fix is released as it is close to holiday seasons. And our product must enable this DPI awareness otherwise introducing rendering bugs. I would be great to have the fix for 4.7. too. Thanks, at System.ThrowHelper.ThrowKeyNotFoundException() + 0x5 (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorlib.dll + 0x06000337) |
|
And I have another question: this crash is caused by the setting per-monitor (V1) or per-monitor (V2)? Our rendering issue can be fixed by only enabling V1. |
|
fyi (esp. @jbattermann, @AndreaLazz): |
ghost
locked as resolved and limited conversation to collaborators
Copied from ADO ID 893177
We have a bug here - a missing check.
\WPF\src\Core\CSharp\MS\Internal\DpiUtil\DpiUtil+DpiAwarenessScope.cs
We should either be catch
KeyNotFoundException, or better yet, checking fordpiAwarenessContextValue==Invalidand return withOperationSupported=falseearly in the constructor.Found from Watson data:
Call Stack
The text was updated successfully, but these errors were encountered: