Issue with WPF application becoming unresponsive after plugging or unplugging a USB device supporting pen events

_This issue has been moved from [a ticket on Developer Community](https://developercommunity.visualstudio.com/t/Issue-with-WPF-application-becoming-unre/1384622)._

---

I posted this issue at https://docs.microsoft.com/en-us/answers/questions/156988/issue-with-wpf-application-becoming-unresponsive-a.html, but perhaps this would be a better forum to ask it. I'll copy and paste the information from there to here:

I've run across an issue on Windows 10 where WPF apps seem to become unresponsive when unplugging or plugging in a USB device that registers as an input device that can receive touch/stylus events. This can be seen by creating a basic WPF app in Visual Studio, running it, and then adding/removing one of these devices.

I used Spy++ to see which messages the app was receiving. I saw a number of messages I was expecting to see - WM_DEVICECHANGE, WM_POINTERDEVICECHANGE, as well as 0x02C8 or 0x02C9 (WM_TABLET_ADDED or WM_TABLET_DELETED, respectively). However, after this, thousands (or sometimes tens of thousands) of messages were sent to a window belonging to the app that is at (0,0) with dimensions 0x0. Its caption is "OLEChannelWnd". The messages are mostly the same:

• They're all posted to the window
• The message ID is 0x0400 (WM_USER + 0)
• The wParam is always the same (0x0000BABE)
• The lParam varies each time I restart the WPF app, but they seem to settle on a small number of values - for example, the last time I tried this, I saw 0x05D08BB0 4-6 times, then 0x0D1B8E98 a dozen or more times, then 0x0D1B7B90 several times, and so on.

After doing research online, I found some posts that talked about a possible issue in the PenThreadWorker thread - that it could be running into some kind of deadlock when initializing certain objects. I also found several posts that mentioned disabling the stylus & touch events by setting "Switch.System.Windows.Input.Stylus.DisableStylusAndTouchSupport". I can add this to the app.config for my app as follows:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Input.Stylus.DisableStylusAndTouchSupport=true" />
</runtime>

or, equivalently, I can do the following during application startup:

AppContext.SetSwitch("Switch.System.Windows.Input.Stylus.DisableStylusAndTouchSupport", true);

This does fix the issue - I don't see these WM_USER messages being sent to the app, and as such the app becomes immediately responsive once the device is plugged/unplugged. However, one of the WPF apps that I'm working with (i.e. not the simple test app) needs to process tablet events, so this setting can't be used there. Furthermore, it can only be set either in app.config or during application startup - any calls to it after that are ignored.

I've tried this with .NET 4.5.1, .NET 4.6 (which is required to use the code-based method) as well as .NET 4.8, but in all cases I see this same result.

---
### Original Comments

#### Feedback Bot on 11/19/2020, 02:53 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

#### Feedback Bot on 2/19/2021, 10:06 PM:

I detected that this issue hasn’t received a lot of activity, votes, or comments in the past 90 days. Based on this, the issues severity and affected area, it’s my experience that this issue is unlikely to get fixed. To improve the situation, consider following best practices for quality problem reports, and giving us more details on how this issue is impacting you.

#### Mila Zhou[MSFT] on 2/25/2021, 10:32 PM:

Thank you for taking the time to log this issue! Did you still reproduce this issue in the latest stable version of Visual Studio installed from https://visualstudio.microsoft.com/downloads ?

If so, could you please provide a sample solution that has this problem so that we can conduct further research?

We look forward to hearing from you!

#### Feedback Bot on 3/9/2021, 07:18 PM:

We will close this report in 14 days because we don’t have enough information to investigate further. To keep the problem open, please provide the requested details.

#### Feedback Bot on 3/22/2021, 01:05 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

#### Feedback Bot on 3/29/2021, 11:55 PM:

Thank you for taking the time to provide your suggestion. We will do some preliminary checks to make sure we can proceed further. We'll provide an update once the issue has been triaged by the product team.