Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

WPF touch application (partially) freezes on .NET Framework 4.7

Update

Microsoft acknowledged the issue:

Gepost door Microsoft op 13/10/2017 om 11:38

Thank you for reporting this. We are aware of this issue and are fixing it in a future version of .NET. There is also a related issue that is being released in a servicing fix that will drastically reduce the possibility of hitting this problem. This will be serviced relatively soon.

Problem

Our WPF application is being used on tablets using touch (no stylus) and we are experiencing issues after the installation of .NET Framework 4.7. Two scenarios can occur after using the application for a while: either the application freezes completely and has to be restarted or all touch functionality in Popup or Window elements is disabled. There is quite a difference between the two but I believe the cause is the same.

Scenario 1: full freeze

  • The application becomes fully unresponsive, the application must be closed using the Task Manager
  • Touch nor mouse can be used
  • Sometimes the following error is thrown before the application hangs:

Index was outside the bounds of the array.

This is the stacktrace:

   at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
   at System.Windows.Input.StylusWisp.WispLogic.CoalesceAndQueueStylusEvent(RawStylusInputReport inputReport)
   at System.Windows.Input.StylusWisp.WispLogic.ProcessSystemEvent(PenContext penContext, Int32 tabletDeviceId, Int32 stylusDeviceId, Int32 timestamp, SystemGesture systemGesture, Int32 gestureX, Int32 gestureY, Int32 buttonState, PresentationSource inputSource)
   at System.Windows.Input.PenContext.FireSystemGesture(Int32 stylusPointerId, Int32 timestamp)
   at System.Windows.Input.PenThreadWorker.FireEvent(PenContext penContext, Int32 evt, Int32 stylusPointerId, Int32 cPackets, Int32 cbPacket, IntPtr pPackets)
   at System.Windows.Input.PenThreadWorker.ThreadProc()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart() 

Scenario 2: partial freeze

  • The main window is still responsive (by mouse and touch) but any 'overlay' content (Modal Dialog, Window, Popup element from DatePicker, ComboBox, ...) doesn't respond to tapping. The application must be restarted to reenable touch.
  • Mouse can still be used in 'overlay' elements.

This issue is also explained in detail here. A video of the behavior after the issue occurs can be found here.

Additional Info

  • Both scenarios can be simulated on different types of tablets and also on the Windows Simulator, using a mix of Windows 8.1 and Windows 10.
  • The issues are fixed when removing .NET Framework 4.7
  • Scenario 2 can be easily reproduced by quickly tapping some ComboBox elements with multiple fingers. After a few minutes, the popup is no longer responsive to touch.
  • Scenario 1 is harder to simulate and occurs randomly.

Cause

The issue seems to have something to do with the StylusWisp code. I guess it suddenly fails and becomes unusable after that point.

When disabling the Stylus support by either using DisableWPFTabletSupport or DisableStylusAndTouchSupport, the issue disappears. However, any ScrollViewer with PanningMode="Both" can't be swipe scrolled anymore.

Solution?

A similar issue has been reported to Microsoft. Since there is not much support yet, a fix might take a while. In the meantime I'm looking for a solution for this issue that doesn't involve disabling the .NET Framework 4.7 and that keeps the original touch support intact. Does anyone have the same issues and a better solution?

like image 939
Bruno V Avatar asked Sep 05 '17 07:09

Bruno V


2 Answers

Why it break in .NET Framework 4.7 for Windows10 Creators Update?

My friend lsj download the source code from https://referencesource.microsoft.com and find the .NET 4.7 for Windows 10 Creators Update have not add lock to WispLogic.CoalesceAndQueueStylusEvent and the other add the lock.

So it only break in .NET Framework 4.7 for Windows10 Creators Update. And .NET Framework 4.7 RTM add the lock to WispLogic.CoalesceAndQueueStylusEvent and fix it.

Which version add lock?

  • .NET 4.7 RTM
  • .NET 4.7.2 RS4
  • .NET 4.7.2 ZDP
  • .NET 4.8 RTM

Which version remove lock?

  • .NET 4.6.2 RS1
  • .NET 4.6.2 RTM
  • .NET 4.7 RS2
  • .NET 4.7.1 RS3
  • .NET 4.7.1 Downlevel

The funny thing is .NET 4.7 RTM add the lock to WispLogic.CoalesceAndQueueStylusEvent and the .NET 4.7.1 Downlevel remove it.

The .NET 4.7.2 for Windows 10 April 2018 Creators Update is the frist version to add lock and it seems fix in .NET 4.7.2 not fix in .NET 4.7.1

like image 82
lindexi Avatar answered Nov 15 '22 21:11

lindexi


Installing the .NET Framework 4.7.1 seems to fix the issue. The .NET Framework 4.7.1 is also included in the Windows 10 Fall Creators Update which has started rolling out since October.

like image 36
Bruno V Avatar answered Nov 15 '22 21:11

Bruno V