What happened?
Starting with 147.0.3912.60 on Windows Server machines, after the touchscreen input service has been activated by connecting from a device with a touchscreen like a touchscreen laptop, our .NET WinForms application becomes unresponsive for two seconds or longer whenever its WebView2 control gains or loses the input focus or when focus moves between WebView2 controls (e.g. launching or closing a floating window). The behavior has been confirmed on Windows Server 2025 and 2022. Using the WebView2 versions available through the WebView2.Runtime.X64 NuGet package, I was able to isolate that 146.0.3856.109 and earlier versions are not affected. Interestingly enough, if the application is instead run on the Windows 11 endpoint device that reproduces the problem on the server, the performance degradation is not seen. Running the app within an RDP session is enough to reproduce the problem, you don't need to use any app virtualization software.
The service I'm referring to was called the "Touch Keyboard and Handwriting Panel Service" (TabletInputService) in Windows 10/Server 2022 and has been replaced by the "Text Input Management Service" (TextInputManagementService) in Windows 11/Server 2025. The use of the word "activation" is intentionally vague: the problem does not happen just whenever the service is running; instead, something about connecting a touchscreen device to the server seems to cause it to start injecting tiptsf.dll (the Touch Keyboard and Handwriting Panel Text Services Framework DLL) into processes, including the msedgewebview2.exe browser process. When the process hears about focus events, it makes several long-lived calls into UIAutomationCore.dll to retrieve information:
ntdll!NtWaitForAlertByThreadId+0x14
ntdll!RtlpWaitOnAddressWithTimeout+0x9f
ntdll!RtlpWaitOnAddress+0xd8
ntdll!RtlWaitOnAddress+0x13
KERNELBASE!WaitOnAddress+0x2f
uiautomationcore!wil::slim_event_t<0>::WaitForSignal+0x1f
uiautomationcore!wil::slim_event_t<0>::wait+0x79
uiautomationcore!RequestResponseCoordinator::WaitForResponse+0x33
uiautomationcore!ChannelBasedClientConnection::DoCallWithReturn+0x263
uiautomationcore!CUIAutomationBlockingCore::DoCallWithReturn+0x6b
uiautomationcore!BlockingCoreDispatcher::DoCallWithReturn+0x154
uiautomationcore!BlockingCoreDispatcher::Dispatch_DoCallWithReturn+0xb5
uiautomationcore!DoCallWithReturn+0x192
uiautomationcore!LocalUiaNodeProxy::RealRemoteNodeFromProviderEntryPoint+0x1b4
uiautomationcore!ProviderEntryPoint::GetUiaNode+0x2cd2
uiautomationcore!UiaNodeFactory::CompleteNodeInfo+0x704
uiautomationcore!UiaNodeFactory::FromPartialNodeInfo+0x1a
uiautomationcore!UiaNodeFactory::FromProviderEntryPoint+0x8b
uiautomationcore!CUIAutomation::GetNodeFromFactory+0x65
uiautomationcore!CUIAutomation::ElementFromHandle+0x178
tiptsf!CImmersiveFocusTracker::_HandleAutomationEvent+0x33c
tiptsf!CImmersiveFocusTracker::HandleAutomationEvent+0x52
tiptsf!TabletMsgWndProc+0x1c3
user32!DispatchHookW+0xbc
user32!CallHookWithSEH+0x33
user32!__fnHkINLPMSG+0x4d
ntdll!KiUserCallbackDispatcherContinue
win32u!NtUserPeekMessage+0x14
user32!_PeekMessage+0x43
user32!PeekMessageW+0x13f
msedge!base::MessagePumpForUI::ProcessNextWindowsMessage+0xf5
msedge!base::MessagePumpForUI::DoRunLoop+0xfd
msedge!base::MessagePumpWin::Run+0x88
msedge!base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run+0xe3
msedge!base::RunLoop::Run+0x70
msedge!content::BrowserMainLoop::RunMainMessageLoop+0x8e
msedge!content::BrowserMain+0x96
msedge!content::RunBrowserProcessMain+0xce
msedge!content::ContentMainRunnerImpl::RunBrowser+0x452
msedge!content::ContentMainRunnerImpl::Run+0x264
msedge!content::RunContentProcess+0x296
msedge!content::ContentMain+0x5f
msedge!ChromeMain+0x2d3
msedgewebview2!MainDllLoader::Launch+0x3e1
msedgewebview2!wWinMain+0x724
msedgewebview2!__scrt_common_main_seh+0x106
KERNEL32!BaseThreadInitThunk+0x10
ntdll!RtlUserThreadStart+0x2b
Attaching WinDbg to the browser process shows UIAutomationCore has started throwing many C++ EH exceptions that did not appear in v146 and earlier. They tend to have a call stack that looks like this:
ucrtbase!CxxThrowException+0x9a
uiautomationcore!wil::details::ThrowResultExceptionInternal+0x4e
uiautomationcore!wil::ThrowResultException+0x20
uiautomationcore!wil::details::ReportFailure_NoReturn<0>+0x2f2
uiautomationcore!wil::details::ReportFailure_Base<0,0>+0x30
uiautomationcore!wil::details::ReportFailure_Hr<0>+0x5f
uiautomationcore!wil::details::in1diag3::Throw_Hr+0x18
uiautomationcore!LocalUiaNodeProxy::RealRemoteNodeFromProviderEntryPoint+0xa6b
uiautomationcore!ProviderEntryPoint::GetUiaNode+0x2cd2
uiautomationcore!UiaNodeFactory::CompleteNodeInfo+0x704
uiautomationcore!UiaNodeFactory::FromPartialNodeInfo+0x1a
uiautomationcore!UiaNodeFactory::FromProviderEntryPoint+0x8b
uiautomationcore!CUIAutomation::GetNodeFromFactory+0x65
uiautomationcore!CUIAutomation::ElementFromHandle+0x178
tiptsf!CImmersiveFocusTracker::_HandleAutomationEvent+0x33c
tiptsf!CImmersiveFocusTracker::HandleAutomationEvent+0x52
tiptsf!TabletMsgWndProc+0x1c3
user32!DispatchHookW+0xbc
user32!CallHookWithSEH+0x33
user32!__fnHkINLPMSG+0x4d
ntdll!KiUserCallbackDispatcherContinue
win32u!NtUserPeekMessage+0x14
user32!_PeekMessage+0x43
user32!PeekMessageW+0x13f
msedge!base::MessagePumpForUI::ProcessNextWindowsMessage+0xf5
msedge!base::MessagePumpForUI::DoRunLoop+0xfd
msedge!base::MessagePumpWin::Run+0x88
msedge!base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run+0xe3
msedge!base::RunLoop::Run+0x70
msedge!content::BrowserMainLoop::RunMainMessageLoop+0x8e
msedge!content::BrowserMain+0x96
msedge!content::RunBrowserProcessMain+0xce
msedge!content::ContentMainRunnerImpl::RunBrowser+0x452
msedge!content::ContentMainRunnerImpl::Run+0x264
msedge!content::RunContentProcess+0x296
msedge!content::ContentMain+0x5f
msedge!ChromeMain+0x2d3
msedgewebview2!MainDllLoader::Launch+0x3e1
msedgewebview2!wWinMain+0x724
msedgewebview2!__scrt_common_main_seh+0x106
KERNEL32!BaseThreadInitThunk+0x10
ntdll!RtlUserThreadStart+0x2b
The TabletInputService can be disabled in Server 2022, which allows working around this problem at the cost of losing touchscreen support. The TextInputManagementService service cannot be disabled in Server 2025.
Importance
Moderate. My app's user experience is affected, but still usable.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
148.0.3967.54
SDK Version
1.0.3485.44
Framework
Winforms
Operating System
Windows Server
OS Version
26100.32860
Repro steps
The behavior can be reproduced with the WebView2WpfBrowser sample app. The easiest way to see it is to use the Windows -> New Window menu item to launch a new WebView2 window, click into the webpage to give the new WebView2 control the focus, and then dismiss the new window by clicking its close button. The application will hang for several seconds as it closes the window.
Interestingly, I am not seeing the problem in the WebView2WindowsFormsBrowser, even though the application where we first detected the problem uses WinForms.
Repros in Edge Browser
No, issue does not reproduce in the corresponding Edge version
Regression
Regression in newer Runtime
Last working version (if regression)
Runtime 146.0.3856.109
What happened?
Starting with 147.0.3912.60 on Windows Server machines, after the touchscreen input service has been activated by connecting from a device with a touchscreen like a touchscreen laptop, our .NET WinForms application becomes unresponsive for two seconds or longer whenever its WebView2 control gains or loses the input focus or when focus moves between WebView2 controls (e.g. launching or closing a floating window). The behavior has been confirmed on Windows Server 2025 and 2022. Using the WebView2 versions available through the WebView2.Runtime.X64 NuGet package, I was able to isolate that 146.0.3856.109 and earlier versions are not affected. Interestingly enough, if the application is instead run on the Windows 11 endpoint device that reproduces the problem on the server, the performance degradation is not seen. Running the app within an RDP session is enough to reproduce the problem, you don't need to use any app virtualization software.
The service I'm referring to was called the "Touch Keyboard and Handwriting Panel Service" (TabletInputService) in Windows 10/Server 2022 and has been replaced by the "Text Input Management Service" (TextInputManagementService) in Windows 11/Server 2025. The use of the word "activation" is intentionally vague: the problem does not happen just whenever the service is running; instead, something about connecting a touchscreen device to the server seems to cause it to start injecting tiptsf.dll (the Touch Keyboard and Handwriting Panel Text Services Framework DLL) into processes, including the msedgewebview2.exe browser process. When the process hears about focus events, it makes several long-lived calls into UIAutomationCore.dll to retrieve information:
Attaching WinDbg to the browser process shows UIAutomationCore has started throwing many C++ EH exceptions that did not appear in v146 and earlier. They tend to have a call stack that looks like this:
The TabletInputService can be disabled in Server 2022, which allows working around this problem at the cost of losing touchscreen support. The TextInputManagementService service cannot be disabled in Server 2025.
Importance
Moderate. My app's user experience is affected, but still usable.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
148.0.3967.54
SDK Version
1.0.3485.44
Framework
Winforms
Operating System
Windows Server
OS Version
26100.32860
Repro steps
The behavior can be reproduced with the WebView2WpfBrowser sample app. The easiest way to see it is to use the Windows -> New Window menu item to launch a new WebView2 window, click into the webpage to give the new WebView2 control the focus, and then dismiss the new window by clicking its close button. The application will hang for several seconds as it closes the window.
Interestingly, I am not seeing the problem in the WebView2WindowsFormsBrowser, even though the application where we first detected the problem uses WinForms.
Repros in Edge Browser
No, issue does not reproduce in the corresponding Edge version
Regression
Regression in newer Runtime
Last working version (if regression)
Runtime 146.0.3856.109