Short, incomplete swipe gestures on the SwipeControl sometimes causes crashes (fail fast exception)

[Sergio0694]

Describe the bug

As the title says, doing short, incomplete swipe gestures on the SwipeControl sometimes causes crashes. This has been reported by a couple users, but I can't seem to be able to replicate that using the simulator (I don't have a touch screen device to test this on).

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Create a SwipeControl with some left/swipe items, use it as the root control in an item template used in a ListView
2. Try to swipe the control a bit and release it before the swipe threshold is reached
3. Repeat a few times
4. The app should crash (see the original bug report here)

Expected behavior

The exception should not be raised

Version Info

Windows 10: 10.0.18362.175 x64 NuGet package version: WinUI: 2.1.190606001

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
May 2019 Update (18362)	Yes
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)
Anniversary Update (14393)

Device form factor	Saw the problem?
Desktop	Yes
Mobile
Xbox
Surface Hub
IoT

Additional context I should note that the app is currently using the SDK 17763 as both minimum and target. Also, here is the complete stack trace from AppCenter:

KERNELBASE.dll              RaiseFailFastException() xcpt.c:1133
SharedLibrary.dll           Interop::mincore RaiseFailFastException() Interop.manual.cs:88
SharedLibrary.dll           System::RuntimeExceptionHelpers FailFast() RuntimeExceptionHelpers.cs:236
system.private.interop.dll  System::Runtime::InteropServices::__native_ccw AccessNeuteredCCW_FailFast() ComCallableObject.cs:453
system.private.interop.dll  System::Runtime::InteropServices::__native_ccw get_ComCallableObject() ComCallableObject.cs:442
system.private.interop.dll  System::Runtime::InteropServices::__vtable_IUnknown QueryInterface() StandardInterfaces.cs:88
Microsoft.UI.Xaml.dll       ReferenceTracker_RefreshContainer,winrt::Microsoft::UI::Xaml::Controls::implementation::RefreshContainerT,winrt::Microsoft::UI::Private::Controls::IRefreshContainerPrivate_ QueryInterface() runtimeclasshelpers.h:182
Microsoft.UI.Xaml.dll       winrt::impl::weak_ref_1_ Resolve() base.h:8216
Microsoft.UI.Xaml.dll       winrt::weak_ref_SwipeControl_ get() base.h:4154
Microsoft.UI.Xaml.dll       SwipeControl ValuesChanged() swipecontrol.cpp:328
Microsoft.UI.Xaml.dll       winrt::impl::produce_SwipeControl,winrt::Windows::UI::Composition::Interactions::IInteractionTrackerOwner_ ValuesChanged() windows.ui.composition.interactions.h:2072
dcomp.dll                   Microsoft::WRL2::ContextSession LeaveSession_Callback__lambda_98d6ddd492b07c54c34c6a3c3744782e_ _() wrl2agile.h:1093
dcomp.dll                   Windows::UI::Composition::Interactions::InteractionTracker Message_ScrollValuesChanged_Callback() wrtinteractiontracker.cpp:2149
CoreMessaging.dll           CoreUICallReceive() api.cpp:208
dcomp.dll                   Windows::UI::Composition::Compositor s_OnCallbackMessage_NoLock() wrtcompositor.cpp:4714
dcomp.dll                   DirectComposition::CMessageConversationHost OnItemMessage() messageconversationhost.cpp:233
CoreMessaging.dll           Microsoft::CoreUI::ICallbackMessageConversationHost$X__CallbackAdapter OnItemMessage() common__dllinterop.cpp:6510
CoreMessaging.dll           Microsoft::CoreUI::Conversations::ItemMessageDispatcher Callback_OnMessageCore() itemmessagedispatcher.cs:37
CoreMessaging.dll           Microsoft::CoreUI::Messaging::MessageSession Callback_DeliverMessage() messagesession.cs:5157
CoreMessaging.dll           Microsoft::CoreUI::Messaging::MessageSession Callback_DeliverMessageBatch() messagesession.cs:5080
CoreMessaging.dll           Microsoft::CoreUI::Messaging::AlpcClientSender Callback_ProcessBuffer() alpcclientsender.cs:302
CoreMessaging.dll           Microsoft::CoreUI::Messaging::AlpcClientThunk Callback_ProcessAsynchronousBuffer() alpcclientsendern.cpp:74
CoreMessaging.dll           AlpcConnection Callback_HandleReceivedBuffer() alpcconnection.cpp:709
CoreMessaging.dll           AlpcConnection Callback_ProcessIncoming() alpcconnection.cpp:469
CoreMessaging.dll           Microsoft::CoreUI::Messaging::AlpcClientSender$R Delegate0() microsoft.coreui.messaging.cpp:233
CoreMessaging.dll           Microsoft::CoreUI::Dispatch::OffThreadReceiver Callback_OnDispatch() offthreadreceiver.cs:230
CoreMessaging.dll           Microsoft::CoreUI::Dispatch::EventLoop Callback_RunCoreLoop() eventloop.cs:779
CoreMessaging.dll           Microsoft::CoreUI::Dispatch::UserAdapter OnUserDispatch() useradapter.cs:261
CoreMessaging.dll           Microsoft::CoreUI::Dispatch UserAdapter_DoWork() useradaptern.cpp:423
CoreMessaging.dll           Microsoft::CoreUI::Dispatch UserAdapter_WindowProc() useradaptern.cpp:658
user32.dll                  UserCallWinProcCheckWow() clmsg.cxx:279
user32.dll                  DispatchMessageWorker() clmsg.cxx:3142
Windows.UI.dll              Windows::UI::Core::CDispatcher ProcessMessage() dispatcher.cpp:327
Windows.UI.dll              Windows::UI::Core::CDispatcher WaitAndProcessMessagesInternal() dispatcher.cpp:1953
Windows.UI.dll              Windows::UI::Core::CDispatcher ProcessEvents() dispatcher.cpp:599
Windows.UI.Xaml.dll         CJupiterWindow RunCoreWindowMessageLoop() jupiterwindow.cpp:1233
Windows.UI.Xaml.dll         DirectUI::DXamlCore RunMessageLoop() dxamlcore.cpp:2453
twinapi.appcore.dll         Windows::ApplicationModel::Core::CoreApplicationView Run() coreapplicationview.cpp:561
twinapi.appcore.dll         _lambda_643db08282a766b00cec20194396f531_ operator() coreapplicationviewagilecontainer.cpp:1158
SHCore.dll                  _WrapperThreadProc() thread.cpp:321
kernel32.dll                BaseThreadInitThunk() thread.c:64
ntdll.dll                   RtlUserThreadStart() rtlstrt.c:1153

[YuliKl]

@Sergio0694, thank you for reporting this problem. @RBrid, can you investigate?

[RBrid]

Thank you @Sergio0694. Sergio and @YuliKl, I have not been able to repro this crash. Do you have a repro application I could be using to try again? Thank you.

[Sergio0694]

Hi @RBrid - thank you for looking into this. It's unfortunate that you weren't able to reproduce this on your end, I suspect this one won't be able to track down. I'm seeing a few of these crashes (13 so far) from different devices, if it can help: I don't have a repro application, as I wasn't able to reproduce the crash on my end either, so I couldn't start stripping down code to try to isolate the issue on my end.

How would like to go ahead regarding this? All I could do at this point is to give you access to the repository (the app is a commercial one in the Store, but I'd be fine if it was just you or your team cloning the repo), then you could try building and running the app yourself and seeing if you can reproduce the crash doing that. Let me know what works for you, and thank you again for your time!

[Sergio0694]

Hey @RBrid - just though I'd give you an update on this. This crash keeps happening pretty frequently for me, here's a screenshot of the latest recorded devices and OS versions (this is just from the crashes in the last week or so), in case it helps: I tried replicating this multiple times on the simulator, but with no success. I mean, I could get the swipe control to break down multiple times and stop working entirely (I'll open a separate issue for this), but with no crashes. I think an actual physical device with a touch screen might be needed to reproduce this (or maybe I've just been unlucky, not 100% sure about this). For all I know the two issues might be related, and the difference in behavior (break down vs. crash) might be caused in part by me trying to repro them in the simulator instead of an actual device.

The stack trace I'm getting is always the same exact one I posted in my first message here, hopefully having that might help a bit to investigate this.

I understand that this is probably not a super high priority bug, but I just thought I'd give you the extra info. Also, my offer is always available if someone from your team wants access to the repo to clone it and look into this. Or, if you just need to make the app crash and an external debugger is enough, you can find it here in the Store.

Thanks again for your time! 😊

[RBrid]

Thank you and sorry for the delay @Sergio0694, I will be gone for a month. @jevansaks, you may want to re-assign this during my absence.

[kmahone]

@Sergio0694, I am not able to reproduce this crash either in the repro app or in Legere from the Store. I tried on both a desktop machine and a Surface Pro 4.

It is difficult to determine the root cause from the call stack. But I do have a question: are you using a SwipeControl directly, or have you made a custom type that derives from SwipeControl? The callstack looks like it is calling out to managed code when it is resolving the SwipeControl, which makes me suspect that there is a derived type involved.

[Sergio0694]

Hi @kmahone - that is correct, I am in fact using the SwipeControl through an inherited control, though I'm not actually modifying anything in particular, just adding an extra event. This is the code for the custom control I'm using:

/// <summary>
/// A simple extension for the <see cref="SwipeControl"/> that allows to relay external actions to different instances of the control
/// </summary>
public sealed class RelaySwipeControl : SwipeControl
{
    /// <summary>
    /// Raised whenever a swipe action is externally triggered
    /// </summary>
    public event EventHandler<object> ActionInvoked;

    /// <summary>
    /// Raises the <see cref="ActionInvoked"/> event to relay a given action
    /// </summary>
    /// <param name="data">The associated data for the invoked action</param>
    public void RelayExternalAction([NotNull] object data) => ActionInvoked?.Invoke(this, data);
}

The reason why I'm doing this is that I'm using this control as the root control in some of my user templates, and since users in Legere can customize the swipe actions in the app, what I'm doing is using a single, shared instance of the SwipeActions items that are held in a resource dictionary with code behind, initializing the various actions at startup following the user settings, and then I'm simply using {StaticResource} to link those shared actions to each instance of the SwipeControl. The reason for that ActionInvoked event I've added is so that the actions that are in the resource dictionary can just get the sender (the RelaySwipeControl control), then manually call that RelayExternalAction method with the appropriate info, and then I can just use that event handler in each single template to handle the invoked action accordingly.

This makes the code much more efficient (and cleaner), as I don't have to spawn and initialize all the various swipe actions in each and every single template.

Also, as I've previously mentioned, in case it might help, I'd be willing to share the repo of the app with you or your team, if you think that looking at my code could help you investigate this 😊

[Sergio0694]

Hello, are there any updates on this? The SwipeControl alone is currently responsible for the two most frequent crashes I'm getting in my app 😟

Please let me know if there's any way I can help you guys track this issue, I'm happy to help if I can!

[kmahone]

Hi @Sergio0694, sorry for the lack up updates on this.

The issue is due to some problem with the interaction between WinRT weak references with .net types derived from WinRT types.

Unfortunately, I have never been able to reproduce this crash - I tried on multiple devices including a Surface Pro 4. I have been able to get crash dumps though which shed some light on the problem. One thing that would be helpful would be if there was a method to reproduce the issue so that I could debug the crash in real time instead of through a crash dump. But it sounds like you were never able to reproduce the issue yourself?

If you are looking for a work-around to avoid hitting this problem, one possibility would be to not derive RelaySwipeControl directly from SwipeControl. If instead RelaySwipeControl was a UserControl that contained a SwipeControl, this bug would not be hit. It would mean that RelaySwipeControl would need to replicate the necessary properties of SwipeControl on its api, which is not ideal. Depending on the specifics of your app, this may or may not be a reasonable work-around.

[kmahone]

@Sergio0694 I have made a fix to SwipeControl that I think should resolve this issue. However, since I cannot reproduce the issue myself, there is no way for me to confirm that the issue has been fixed. Probably the best thing to do is to wait for a new WinUI prerelease to get published on nuget.org and then update your app and see if the crash goes away.

Alternatively, if you don't want to wait for an official version to get pushed to nuget.org, you can pick up one of our CI builds and use that. Let me know if you are interested in taking that approach.

If you continue to observe this crash in your app after upgrading to a build with this change, let me know and I will reactivate the issue.

[Sergio0694]

Hi @kmahone - I was just about to reply to your previous comment, thanks! I've followed your advice and refactored my code, instead of inheriting from SwipeControl I'm now using a templated ContentControl with a SwipeControl and a ContentPresenter in the template, and placing those relay properties in that control, as you suggested. I've just pushed an update to production with this change, so we'll see how it goes with the analytics.

It's great to hear that you think you've actually managed to fix the issue though! Unfortunately I won't be able to try that out myself for a while though, my app is stuck on WinUI 2.1 due to a known issue with the Windows 10 18362 SDK which just causes my app to fail to build completely as soon as I target that SDK, so I've been forced to stay on 17763 as target until 20H1 comes out next year.

Thanks again for your time and your help! Have a nice day! 😊

[jevansaks]

a known issue with the Windows 10 18362 SDK which just causes my app to fail to build completely as soon as I target that SDK,

Can you elaborate? Do you have a link to the tracking issue and the response you've gotten?

[Sergio0694]

@jevansaks Sure! Paging @LanceMcCarthy as he was so kind to take the time to help me out and investigate the issue. He also has more insights into what is happening exactly. I can give access to the repo to you or someone else from the WinUI team in case you're interested, that was you'll also be able to see the full investigation that Lance did there.

From my understanding, there were a number of issues that only made it possible to build the app starting from the preview SDK 18970. It started out from the "child node 2 exited prematurely" error (see issue #1286), which I think has been fixed now, but then other issues piled up on top of it. Here's a screenshot from one of the reports that Lance wrote in my repo:

[jevansaks]

Sounds like something @DanZil and @alwu-msft should help with. Is the app open source or could you share the XAML file that's failing to compile? Have you narrowed it down to specific syntax or structure in the XAML file that's tripping this?

[LanceMcCarthy]

@jevansaks You can ping Kevin Larkin for the MSFT internal BR. The issue was fixed in insider preview builds 18970 or newer.

Here's my post on the topic https://dvlup.com/2019/08/07/postmortem-child-node-2-compilation-error-after-updating-to-18362-sdk/

Here's a related public item https://developercommunity.visualstudio.com/content/problem/544057/uwp-visual-studio-2019-targetting-1903-18362.html