Touch and Stylus inputs not working on .Net 6.0 WPF application

[Tpb13]

We have a WPF application on .net framework 4.7.2, which used to work for touch and stylus inputs. After we migrate the application to .net 6.0, touch and stylus inputs are not working on UIElements. After searching in other forums, i came across to keep "Switch.System.Windows.Input.Stylus.EnablePointerSupport": true in runtimeconfig.template.json file to make touch input work.
{
"configProperties": {
"Switch.System.Windows.Input.Stylus.EnablePointerSupport": true
}
}

After adding this, touch input is working but not touch move or scroll.
Anybody come across this issue in WPF .net 6.0 appliation. Am i missing any configuration setting after using upgrade assistant tool to migrate from framework to .net 6. Any help would be appreciated.

[Tpb13]

While debugging, i came across this exception System.InvalidCastException Message=Interface not registered. When this exception comes, pen and tablet devices are not registering. Due to this, touch input is not working. When i added the "Switch.System.Windows.Input.Stylus.EnablePointerSupport": true to the runtimeconfig file, exception went away but scroll not working.

[Tpb13]

I believe the issue #2393 looks same.
@rladuca & @vatsan-madhavan Could you please provide some pointers here.

[rladuca]

I no longer work on WPF so @dotnet/wpf-developers will have to help out.

Initial thoughts would be that perhaps there is a race condition between registering the activation context and some other code. I'd be curious as to what the stack that leads to your exception looks like and how it compares to the non-exceptional case. I do suggest getting at least a repro application and perhaps some dumps so that others can more effectively debug the issue. A time travel session would be pretty useful as well: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview.

EnablePointerSupport was never fully fleshed out due to technical issues with underlying OS support vs what WISP supplied. That is why some portions of it might not work well. Its current use is more about getting around blocking issues with the WISP based stack where applicable. Sometimes that is useful, sometimes not. It all depends on the requirements of your app.

[Tpb13]

Thank you @rladuca for the quick response. Below is the screenshot of exception stack. This exception occurs only when launching modeless window from new thread using Application.Current.Dispatcher.InvokeAsync(Action). I am working on creating new application to reproduce the error.