Preview2: Crash during drag & drop (0x00007FFBCFD8B362 KernelBase.dll)

[jschwizer99]

Describe the bug

Fatal exception during drag & drop with WinUI 1.1.0 Preview2 during either get_DataView() or get_Modifiers(). The same code works fine for WinUI 1.0.3.

Besides the hard crash, the drop area seems to be in the incorrect position.

Steps to reproduce the bug

See attached minimal project.
WinUIDragOverCrash.zip

Note: As extracted from a large failing project, the individual blocks may miss functionality (especially the drop handler). The drop handler of the original project contains o lot of async processing of the dropped data.

Compile and start project. Perform several a drag & drop operation. The drop area for WinUI 1.1.0 Preview 2 is not where it should be. On my screen it was on the lower right corner of the application. Move it around on the drop area to provoke calls to OnDragOver().

Debug Output

onecoreuap\shell\dataexchange\winrt\lib\droptargetinternal.cpp(306)\DataExchange.dll!00007FFB95466B58: (caller: 00007FFBD10295D3) ReturnHr(41) tid(95d4) 80070490 Element not found.
OnDragOver.
onecoreuap\shell\dataexchange\winrt\lib\droptargetinternal.cpp(306)\DataExchange.dll!00007FFB95466B58: (caller: 00007FFBD10295D3) ReturnHr(42) tid(3c68) 80070490 Element not found.
OnDragOver.
onecoreuap\shell\dataexchange\winrt\lib\droptargetinternal.cpp(306)\DataExchange.dll!00007FFB95466B58: (caller: 00007FFBD10295D3) ReturnHr(43) tid(3c68) 80070490 Element not found.
OnDragOver.
Exception thrown at 0x00007FFBCFCB4F69 (KernelBase.dll) in WinUIDragOverCrash.exe: WinRT originate error - 0x80004005 : 'Reentrancy was detected in this XAML application. Use a debugger to locate the reentrant code and, if necessary, move that code to an asynchronous event handler. Press OK to exit the application.'.
Unhandled exception at 0x00007FFBCFD8B362 (KernelBase.dll) in WinUIDragOverCrash.exe: 0xC000027B: An application-internal exception has occurred (parameters: 0x0000017057BA4A00, 0x0000000000000001).

Stack Trace

 	KernelBase.dll!00007ffbcfd8b362()	Unknown
 	combase.dll!00007ffbd1abcd7a()	Unknown
 	Microsoft.ui.xaml.dll!00007ffb1d54df38()	Unknown
 	Microsoft.ui.xaml.dll!00007ffb1d34250e()	Unknown
 	Microsoft.ui.xaml.dll!00007ffb1d416a3e()	Unknown
 	Microsoft.ui.xaml.dll!00007ffb1d416986()	Unknown
 	CoreMessagingXP.dll!00007ffb753e3f98()	Unknown
 	CoreMessagingXP.dll!00007ffb753e419e()	Unknown
 	CoreMessagingXP.dll!00007ffb753e3d6b()	Unknown
 	CoreMessagingXP.dll!00007ffb753bf808()	Unknown
 	CoreMessagingXP.dll!00007ffb753bf6db()	Unknown
 	CoreMessagingXP.dll!00007ffb7539c470()	Unknown
 	CoreMessagingXP.dll!00007ffb75369b54()	Unknown
 	CoreMessagingXP.dll!00007ffb75369406()	Unknown
 	CoreMessagingXP.dll!00007ffb7535ed7b()	Unknown
 	CoreMessagingXP.dll!00007ffb75361010()	Unknown
 	CoreMessagingXP.dll!00007ffb753614e6()	Unknown
 	CoreMessagingXP.dll!00007ffb7536140a()	Unknown
 	CoreMessagingXP.dll!00007ffb753b466f()	Unknown
 	CoreMessagingXP.dll!00007ffb753b460f()	Unknown
 	user32.dll!00007ffbd168e858()	Unknown
 	user32.dll!00007ffbd168e3dc()	Unknown
 	user32.dll!00007ffbd16a0bc3()	Unknown
 	ntdll.dll!00007ffbd2230ba4()	Unknown
 	win32u.dll!00007ffbd0001064()	Unknown
 	user32.dll!00007ffbd168a5c3()	Unknown
 	user32.dll!00007ffbd168a523()	Unknown
 	combase.dll!00007ffbd192e29b()	Unknown
 	combase.dll!00007ffbd192e205()	Unknown
 	combase.dll!00007ffbd192ec0a()	Unknown
 	combase.dll!00007ffbd192e57f()	Unknown
 	combase.dll!00007ffbd192ca5a()	Unknown
 	combase.dll!00007ffbd192c73b()	Unknown
 	combase.dll!00007ffbd19044d6()	Unknown
 	combase.dll!00007ffbd192ccc3()	Unknown
 	combase.dll!00007ffbd194051b()	Unknown
 	combase.dll!00007ffbd192c014()	Unknown
 	combase.dll!00007ffbd197950e()	Unknown
 	rpcrt4.dll!00007ffbd108c334()	Unknown
 	combase.dll!00007ffbd1974fd8()	Unknown
 	combase.dll!00007ffbd19eaea2()	Unknown
 	DataExchange.dll!00007ffb954688f2()	Unknown
 	Microsoft.ui.xaml.dll!00007ffb1da03018()	Unknown
 	Microsoft.ui.xaml.dll!00007ffb1d7d259d()	Unknown
>	WinUIDragOverCrash.exe!winrt::impl::consume_Microsoft_UI_Xaml_IDragEventArgs<winrt::Microsoft::UI::Xaml::IDragEventArgs>::DataView() Line 914	C++
 	WinUIDragOverCrash.exe!winrt::WinUIDragOverCrash::implementation::MainWindow::OnDragOver(const winrt::Windows::Foundation::IInspectable & __formal, const winrt::Microsoft::UI::Xaml::DragEventArgs & args) Line 38	C++
 	[External Code]	
 	WinUIDragOverCrash.exe!winrt::impl::delegate<winrt::Microsoft::UI::Xaml::DragEventHandler,void <lambda>(const winrt::Windows::Foundation::IInspectable &, const winrt::Microsoft::UI::Xaml::DragEventArgs &)>::Invoke(void * sender, void * e) Line 4736	C++
 	[External Code]	
 	WinUIDragOverCrash.exe!winrt::impl::consume_Microsoft_UI_Xaml_IApplicationStatics<winrt::Microsoft::UI::Xaml::IApplicationStatics>::Start(const winrt::Microsoft::UI::Xaml::ApplicationInitializationCallback & callback) Line 157	C++
 	WinUIDragOverCrash.exe!winrt::Microsoft::UI::Xaml::Application::Start::__l2::<lambda>(const winrt::Microsoft::UI::Xaml::IApplicationStatics & f) Line 12146	C++
 	WinUIDragOverCrash.exe!winrt::impl::factory_cache_entry<winrt::Microsoft::UI::Xaml::Application,winrt::Microsoft::UI::Xaml::IApplicationStatics>::call<void <lambda>(const winrt::Microsoft::UI::Xaml::IApplicationStatics &) &>(winrt::Microsoft::UI::Xaml::Application::Start::__l2::void <lambda>(const winrt::Microsoft::UI::Xaml::IApplicationStatics &) & callback) Line 6331	C++
 	WinUIDragOverCrash.exe!winrt::impl::call_factory<winrt::Microsoft::UI::Xaml::Application,winrt::Microsoft::UI::Xaml::IApplicationStatics,void <lambda>(const winrt::Microsoft::UI::Xaml::IApplicationStatics &)>(winrt::Microsoft::UI::Xaml::Application::Start::__l2::void <lambda>(const winrt::Microsoft::UI::Xaml::IApplicationStatics &) && callback) Line 6354	C++
 	WinUIDragOverCrash.exe!winrt::Microsoft::UI::Xaml::Application::Start(const winrt::Microsoft::UI::Xaml::ApplicationInitializationCallback & callback) Line 12147	C++

Expected behavior

I would expect that winrt::Microsoft::UI::Xaml::DragEventArgs::DataView() and winrt::Microsoft::UI::Xaml::DragEventArgs::Modifiers() can be accessed in the DragOver event handler without need of switching between threads.

Screenshots

Wrong Drop Area of WinUI 1.1.0 Preview 2

NuGet package version

No response

Windows app type

• UWP
• Win32

Device form factor

Desktop

Windows version

Windows 10 (21H2): Build 19044, Windows 10 (20H2): Build 19042

Additional context

No response

[gabbybilka]

@MikeHillberg do we have a bug link for this one?

[codendone]

I'm currently not able to repro the crash, perhaps because I'm trying the repro on Win11 rather than Win10. From what I can see of the callstack, I don't see any changes made in WinUI/WinAppSDK after 1.0 in getting DataView.

[jschwizer99]

@codendone Can you confirm on your platform the shift of the drop zone? For me, the crash was not triggered immediately for this reduced setup. I had to start the application several times in Debug mode and move around on the shifted drop zone (indicated by Move / Copy labels).
Let me know if you need additional information.

[codendone]

Yes, I needed to offset to the drop zone (which I see is logged as #7008) and I see the Move label along with the "OnDragOver" text in the debug output. But no crash. I still need to try on Win10.

[jschwizer99]

The crash signature looks like the one reported in #7007. However, on my WinRT C++ based application, I never saw it on WinUI 1.0.2 and 1.0.3. It was triggered quite fast on WinUI 1.1.0-Preview1 and WinUI 1.1.0-Preview2.

[jschwizer99]

Both reported issues (crash and offset) are still visible in WinUI 1.1.0-preview3 (#7061).

[jschwizer99]

Just tested it with WinUI 1.1.0. As @ShashankNay already mentioned the issue is still there. Without a working drag & drop, we can not update our application to the WinUI 1.1.0 Release. This is a serious blocker.

[marb2000]

@jschwizer99 We published a service update (1.1.1) with a bug fix. Let us know if finally fixed this tricky bug.

[wbokkers]

@marb2000 @gabbybilka @MikeHillberg
Unfortunately Drag & Drop still crashes with 1.1.1 when dragging a file (outside the app) onto the app. This is even worse than in 1.0.3 ! See also issue #7231

[wbokkers]

@bpulliam As mentioned in #7231, this is not a duplicate of this issue. So there's still stuff to fix regarding D&D

[nseveno]

My app also still crashes after upgrading to version 1.1.1.

[rocksdanister]

Still crashing with v1.1.1, dragging a file from outside my app used to crash 1/10 times in 1.0.3 but from 1.1 onwards its 9/10 times.

Had to turn off the feature for the time being rocksdanister/lively#1262

[jschwizer99]

@marb2000 I've tested both my full app and the drag & drop demo application as attached to this ticket for version 1.1.1. Both still show the WinRT error message 'Reentrancy was detected in this XAML application' followed by an unhandled exception. I did see the issue both for Release and Debug builds. I always see the exception for the get_DataView() method. I never did catch any on get_Modifiers(). After these exceptions, my app Release build will crash. The Debug build seems to still keep running after a few F5 (exceptions are not marked as breaks).
I've also retested under the same conditions 1.1.0. There seems not to be a noticeable difference. For 1.0.3 the issue cannot be observed on my full app and the demo drag & drop app both for Release and Debug.

[jschwizer99]

@marb2000 Let me know what further information you need. For this typical crash on 1.1.1 Debug, I can supply the 200MB+ dump or the stowed exceptions for the initial d&d crash example project.

As further info when trying out all the different versions, apps, and builds. It seems that sometimes the crash is tough to trigger (or not at all > 200 d&d), sometimes a build will crash right away (in sequence). The only stable observation is that my apps and crash example does not show the issue for <= 1.0.4 versions. This is a different signature as of #7231.

In order to trigger the issue more frequently a tree/list could be filled with a lot of small objects with drop individual zones. Moving up / down will trigger the issue very fast. That is the layout of my large app that shows it quite frequently.

[wbokkers]

@marb2000 Tested 1.1.1. In our app it doesn't solve any drag&drop crashes and even adds some more. I have crash dumps available. How can I send them?
I attached stack traces for internal d&d and file d&d.

Xelion-drag-drop-inside-app-WinAppSDK111.txt

Xelion-drag-drop-file-on-app-WinAppSDK111.txt

[terrycox]

More drag and drop weirdness:
#7266

[marb2000]

Thanks for all this info. Very useful.

Updating this thread. We are actively investigating these drag&drop issues (@Scottj1s is actually investing time on it). Some of them looks similar but could have a different root cause. These bugs are very tricky to diagnose and solve, given it can cause collateral issues, but we are making progress! No ETA yet, but we are planning to service it.

[wbokkers]

@marb2000 Thank you Miguel and others for looking into these type of issues. That is greatly appreciated.

[jschwizer99]

@marb2000
As there are no release notes of App SDK 1.1.2 available I've tried it shortly on my application. It still crashes during drag&drop with the usual thread race exception. This time I saw it during the get_Modifiers() call.

[DierkDroth]

Accessing DragEventArgs.DataView with 1.1.3 crashes my C# app. Downgrading to 1.0.3 'resolves' the issue.

I tried to reproduce the issue in a blank, minimal repo (Visual Studio 2022 latest: "Blank app, Packaged (WinUI 3 in Desktop") but failed. I suspect there are a few side conditions involved which are not easy to catch by a fresh, new repo.

[Scottj1s]

fix is now available in Windows App SDK 1.2 Preview 1

[wbokkers]

@Scottj1s Can I use SDK 1.2 Preview 1 in production?

[Scottj1s]

Yes, you can - the corresponding framework package is available in the store

[Scottj1s]

@wbokkers, my apologies - Windows App SDK Previews are not supported in production:
https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/preview-channel

[wbokkers]

@Scottj1s So when will there be a fix in a production ready version? We need the d&d issues to be resolved very badly in our app. What is fix worth if it can't be used in production?

[Scottj1s]

The only alternative I can think of is to go SelfContained:
https://docs.microsoft.com/en-us/windows/apps/package-and-deploy/self-contained-deploy/deploy-self-contained-apps

[wbokkers]

@Scottj1s That's not an option. I looked into that, but I need to change lots of code for this to work. It is a big app that touches every aspect of the life cycle. We also use appinstaller technology for getting updates.

[lakienvinh]

(Add more details to this bug) - In my case: Windows App SDK 1.1.4:

1. Drag a file from Desktop or Window Explorer to Grid and everything works well.
2. Because my ListView need drag & drop feature to re-order items, I must allow Drag & Drop on ListView item, then I try to drag an item from ListView to Grid, exception occurs at line e.DataView. I cannot know how to handle this and am waiting for the Windows App SDK 1.2.

[jschwizer99]

@Scottj1s I've tested my large application with App SDK 1.2.0-preview1. I could no more observe the crashes as reported in this ticket. Many thanks again for the fixes.

Unfortunately, during testing, I hit another regression of App SDK v1.1.x that triggers a crash when using colorpickers. The issue is reported in #7239. It would be great if this regression also gets attention so that finally we again have a WinUI that is as stable as App SDK v1.0.x.

[Setsu-BHMT]

I've discovered a very reliable sample that can reproduce this bug (I think it's this bug but can't verify, explained below)
Tested on WindowsAppSDK v1.1.5 (latest)
DragDropBugSample.zip

Create a blank app with WinUI3, and drop the 2 files into the solution.
There are three ListViews; the left and right ones are inside of Expander controls but the center one is not.
Drag an item from the left list, hold your mouse for 2 or more seconds, then drop onto the center list.
You get an unhandled win32 exception every time. Visual Studio 2022 can't even debug it; detaching and then reattaching as suggested by the dialog box doesn't work.
You can also trigger the bug by dragging quickly, but will require more attempts.
Notice the same doesn't happen if you drop onto the right ListView. The intended behavior of moving items from one container to the other works every time between these two.
Note that this bug exists not just for ListView; changing the center ListView to a GridView will also trigger the same bug.