Windows APP SDK 1.3230331000 Drag and Drop Crash still present

[amercer-fdi]

Describe the bug

When attempting a drag and drop operation, accessing the DragEventArgs parameter of the Drop event will intermittantly causes the application to unrecoverably crash. This sometimes happens on the first attempt, most commonly on the second attempt, and I have never gotten further than 4 successful drops before it occurs.

Debugging in Visual Studio 2022 stops with and Unhandled Exception. The application has crashed at this point and shuts down. There is also no way to debug this now as can be seen from the two screenshots.

Steps to reproduce the bug

Please see #7192, #7007 and #7002. This bug and related bugs have been reported many times.

Expected behavior

Application continues running and unlimited drag and drop operations can be performed.

Screenshots

NuGet package version

WinUI 3 - Windows App SDK 1.3.0: 1.3.230331000

Windows version

Windows 11 (22H2): Build 22621

Additional context

No response

[zhuxb711]

Agree. My app also crashes due to this issue.

[Scottj1s]

@amercer-fdi thanks for the report. Can you attach a dump file to this issue, and/or a repro project?

[amercer-fdi]

@Scottj1s, yes but it'll be a bit. I removed the DnD code completely and just went with buttons instead. I'll throw together a sample project that reproduces it, hopefully this weekend. If it makes a difference, my two lists were inside a user control which was created from the Template Studio.

[mareksm]

`
Microsoft.UI.Xaml.dll!DirectUI::DropOperationTarget::RaiseDragDropEventActionAsync(enum DirectUI::DragDropMessageType,struct ABI::Microsoft::UI::Input::DragDrop::IDragInfo *,class DirectUI::RaiseDragDropEventAsyncOperation *,struct ABI::Windows::Foundation::IAsyncAction * *)
Microsoft.UI.Xaml.dll!DirectUI::RaiseDragDropEventAsyncOperation::OnStart(void)
Microsoft.UI.Xaml.dll!Microsoft::WRL::AsyncBase<struct ABI::Windows::Foundation::IAsyncOperationCompletedHandler,class Microsoft::WRL::Details::Nil,1,struct Microsoft::WRL::AsyncOptions<2,0,&struct _GUID const GUID_NULL,0> >::Start(void)
Microsoft.UI.Xaml.dll!DirectUI::DropOperationTarget::RaiseDragDropEventOperationAsync(enum DirectUI::DragDropMessageType,struct ABI::Microsoft::UI::Input::DragDrop::IDragInfo *,struct ABI::Microsoft::UI::Input::DragDrop::IDragUIOverride *,struct ABI::Windows::Foundation::IAsyncOperation * *)
Microsoft.UI.Xaml.dll!DirectUI::DropOperationTarget::EnterAsync(struct ABI::Microsoft::UI::Input::DragDrop::IDragInfo *,struct ABI::Microsoft::UI::Input::DragDrop::IDragUIOverride *,struct ABI::Windows::Foundation::IAsyncOperation * *)
Microsoft.UI.Input.dll!winrt::impl::consume_Microsoft_UI_Input_DragDrop_IDropOperationTarget::EnterAsync(struct winrt::Microsoft::UI::Input::DragDrop::DragInfo const &,struct winrt::Microsoft::UI::Input::DragDrop::DragUIOverride const &)
Microsoft.UI.Input.dll!winrt::impl::produce<struct winrt::Microsoft::UI::Input::DragDrop::implementation::SystemDropOperationTargetAdapter,struct winrt::Windows::ApplicationModel::DataTransfer::DragDrop::Core::ICoreDropOperationTarget>::EnterAsync(void *,void *,void * *)
DataExchange.dll!DropTargetInternal::DragEnter(struct IDragDropArgsPriv *,struct IDragUIOverridePriv * *)
rpcrt4.dll!Invoke�()
rpcrt4.dll!Ndr64StubWorker(void *,void *,struct _RPC_MESSAGE *,struct MIDL_SERVER_INFO *,long (*const *)(void),struct _MIDL_SYNTAX_INFO *,unsigned long *)
rpcrt4.dll!NdrStubCall3()
combase.dll!CStdStubBuffer_Invoke(IRpcStubBuffer * This, tagRPCOLEMESSAGE * prpcmsg, IRpcChannelBuffer * pRpcChannelBuffer) Line 1458
at onecore\com\combase\ndr\ndrole\stub.cxx(1458)
rpcrt4.dll!CStdStubBuffer_Invoke()
[Inline Frame] combase.dll!InvokeStubWithExceptionPolicyAndTracing::__l6::<lambda_c9f3956a20c9da92a64affc24fdd69ec>::operator()() Line 1279
at onecore\com\combase\dcomrem\channelb.cxx(1279)
combase.dll!ObjectMethodExceptionHandlingAction<<lambda_c9f3956a20c9da92a64affc24fdd69ec>>(InvokeStubWithExceptionPolicyAndTracing::__l6::<lambda_c9f3956a20c9da92a64affc24fdd69ec> action, ObjectMethodExceptionHandlingInfo * pExceptionHandlingInfo, ExceptionHandlingResult * pExceptionHandlingResult, void *) Line 87
at onecore\com\combase\dcomrem\excepn.hxx(87)
[Inline Frame] combase.dll!InvokeStubWithExceptionPolicyAndTracing(IRpcStubBuffer * pMsg, tagRPCOLEMESSAGE *) Line 1277
at onecore\com\combase\dcomrem\channelb.cxx(1277)
combase.dll!DefaultStubInvoke(bool bIsAsyncBeginMethod, IServerCall * pServerCall, IRpcChannelBuffer * pChannel, IRpcStubBuffer * pStub, unsigned long * pdwFault) Line 1346
at onecore\com\combase\dcomrem\channelb.cxx(1346)
[Inline Frame] combase.dll!SyncStubCall::Invoke(IServerCall *) Line 1403
at onecore\com\combase\dcomrem\channelb.cxx(1403)
combase.dll!SyncServerCall::StubInvoke(IRpcChannelBuffer * pChannel, IRpcStubBuffer * pStub, unsigned long * pdwFault) Line 781
at onecore\com\combase\dcomrem\ServerCall.hpp(781)
[Inline Frame] combase.dll!StubInvoke(tagRPCOLEMESSAGE * pMsg, CStdIdentity * pStdID, IRpcStubBuffer *) Line 1628
at onecore\com\combase\dcomrem\channelb.cxx(1628)
combase.dll!ServerCall::ContextInvoke(tagRPCOLEMESSAGE * pMessage, IRpcStubBuffer * pStub, CServerChannel * pChannel, tagIPIDEntry * pIPIDEntry, unsigned long * pdwFault) Line 1423
at onecore\com\combase\dcomrem\ctxchnl.cxx(1423)
[Inline Frame] combase.dll!CServerChannel::ContextInvoke(tagRPCOLEMESSAGE *) Line 1332
at onecore\com\combase\dcomrem\ctxchnl.cxx(1332)
combase.dll!DefaultInvokeInApartment(tagRPCOLEMESSAGE * pMsg, unsigned long CallCatIn, bool bIsTouchedASTACall, IRpcStubBuffer * pStub, CServerChannel * pChnl, tagIPIDEntry * pIPIDEntry, unsigned long * pdwFault) Line 3299
at onecore\com\combase\dcomrem\callctrl.cxx(3299)
[Inline Frame] combase.dll!AppInvoke(ServerCall * pStub, CServerChannel *) Line 1122
at onecore\com\combase\dcomrem\channelb.cxx(1122)
combase.dll!ComInvokeWithLockAndIPID(ServerCall * pServerCall, tagIPIDEntry * pIPIDEntry, bool * pbCallerResponsibleForRequestMessageCleanup) Line 2210
at onecore\com\combase\dcomrem\channelb.cxx(2210)
combase.dll!ThreadInvokeWorker(_RPC_MESSAGE * pMessage) Line 7016
at onecore\com\combase\dcomrem\channelb.cxx(7016)
combase.dll!ThreadInvoke(_RPC_MESSAGE * message) Line 7152
at onecore\com\combase\dcomrem\channelb.cxx(7152)
rpcrt4.dll!DispatchToStubInCNoAvrf�()
rpcrt4.dll!RPC_INTERFACE::DispatchToStubWorker()
rpcrt4.dll!RPC_INTERFACE::DispatchToStubWithObject()
rpcrt4.dll!LRPC_SCALL::DispatchRequest()
rpcrt4.dll!LRPC_SCALL::HandleRequest(struct _PORT_MESSAGE *,struct _PORT_MESSAGE *,void *,unsigned __int64,class RPCP_ALPC_HANDLE_ATTR *)
rpcrt4.dll!LRPC_ADDRESS::HandleRequest()
rpcrt4.dll!LRPC_ADDRESS::ProcessIO(void *)
rpcrt4.dll!LrpcIoComplete()
ntdll.dll!TppAlpcpExecuteCallback()
ntdll.dll!TppWorkerThread()
kernel32.dll!BaseThreadInitThunk�()
ntdll.dll!RtlUserThreadStart�()

`

[mareksm]

Microsoft.WindowsAppSDK.1.3.230602002

[Bondarenko1990]

The same problem. In Version 1.4.231008000, the application crashes when dragging. But I made single-instanced app issue

[Scottj1s]

@amercer-fdi, @Bondarenko1990 thanks for your patience. We've root-caused this issue and are investigating a fix. Will report back if there is an available workaround in the meantime.

[Scottj1s]

@mareksm, @Bondarenko1990, your DragDrop crashes both appear to be related to dispatching the operation on a thread pool thread, where the Xaml runtime has not been initialized, resulting from making Main async (typically for single-instance support). A simple workaround is to make Main sync and block on the async redirect check as noted here.

@amercer-fdi, your original issue is different - are you still seeing this with the latest version of WinAppSDK?

[mareksm]

Making app/main sync again doesn't do anything - it still crashes. I've added a note to the ticket: #9061

[Scottj1s]

All symptoms related to async Main have been addressed in issue #9061. The original issue reported here can no longer be repro'd - accessing the DragEventArgs parameter. Closing this issue until a repro can be demonstrated.

[kmgallahan]

@Scottj1s

I don't think this is the same async drag & drop issue that you linked, but rather a different one involving accessing DragEventArgs in a continuation of an async event handler as mentioned here:

#9296 (comment)

Using an async handler appears as though it is safe and recommended since DragEventArgs.DataView has multiple async-only methods. Unfortunately, they are unstable on re-entering the UI thread in a continuation.

As I suggested there, the documentation should probably be updated.