microsoft
Drag&Drop does not work with within Elevated Apps
Describe the bug
Reorder a ListView with drag&drop make the app crash when running elevated.
Steps to reproduce the bug
- Build https://github.com/davidegiacometti/listview-crash
- Run as normal user
- Reorder the ListView with drag&drop: working
- Retry running elevated: Catastrophic failure (0x8000FFFF (E_UNEXPECTED))
Expected behavior
Working when running elavated
Screenshots
No response
NuGet package version
WinUI 3 - Windows App SDK 1.1.4
Windows app type
- [ ] UWP
- [X] Win32
Device form factor
Desktop
Windows version
Windows 10 (21H2): Build 19044
Additional context
No response
Does this issue repro after 1.2-preview2? There were significant Drag and Drop fixes in that release (all of which are in 1.2 stable).
There's a limitation currently that drag/drop isn't supported in apps running elevated
https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/stable-channel#elevation
Hi @MikeHillberg Thank you! I totally missed that. Is there an official issue tracking this or should I leave this opened?
I don't see it in Issues either, let's leave this one. And thanks for opening
Was this solved? At current state 1.3, When I drag on elevated app I see ban icon.
@Petrarca181 I think you're referring to dragging external content into the elevated app? That would present the ban icon, and is a behavior of Windows. You can repro by running Notepad as admin, and attempting to drag a txt file into.
Starting to drag a Border in an elevated app also crashes due to it being unsupported. Why is this in the Freezer? It sounds like being able to drag UI elements is a useful part of many UIs.
I have exactly the same issue/senario with
<GridView x:Name="GridViewDevices"
CanDragItems="True"
SelectionMode="Extended"
ItemsSource="{x:Bind ItemsSourceDevices, Mode=TwoWay}"
Loaded="{x:Bind LoadedStartConnectedAnimationForBackNavigationDevices}"
ItemsPanel="{StaticResource ItemsPanelTemplateDevices}"
ItemTemplate="{StaticResource DataTemplateDevices}"
ContainerContentChanging="ContainerContentChangingDevices"/>
If i run code in visualstudio 2022 and start normally, all is good. If i start VS as admin, code segs on start of drag. Im running windowsappsdk 1.3.230724000 (everything else is latest too). debugger shows the event "catastrophic issue"
Any update on this? Application crashing in elevated mode when user initiates drag is horrible experience.
Simple functionality like CanReorderItems simply crashes the app...
sadly I just upgraded to [1.4.2 (1.4.231008000)] (https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/stable-channel#version-142-14231008000) and the bug still exists. code crashes with "catastrophic error" when Admin and drag and drop is performed, but works fine if not running as Admin
Yeah, for now it seems best solution is to to just implement in-app Drag&Drop yourself without using builtin apis.
After more than one year development, WinUI team still not resolve this issue.
After more than one year development, WinUI team still not resolve this issue.
This is a very critical bug. Don’t the Microsoft team think so?
Yeah, for now it seems best solution is to to just implement in-app Drag&Drop yourself without using builtin apis.
Sounds like the best solution is not to use Windows App SDK / WinUI 3 as long as that's the level of maturity and support.
Our current application ships with SDK 1.3.230724000 and many of our customers suddenly have the same issue. Our application needs elevated mode. Strangely it never happened before the latest Windows updates. We didn't even change anything in our application. Update: Same problem persists with SDK 1.4.231115000.
Same problem occurs even with the latest "WinUI 3 Gallery" app in elevated mode and latest SDK. It even sometimes crashes when switching between the pages.
This is a serious issue and must be addressed as soon as possible!
I support you MetalMonkey in saying this is a serious issue and is not being taken seriously. I don't even see an acknowledgement that the problem has been recreated, even though it takes 2 minutes to recreate. Could someone at Microsoft acknowledge that this is a serious issue and provide an update as to the plan to fix it? thx
This also seems to affect the TabView and it occurs in WinUI 2 with Xaml Islands as well - you can see in Notepad and Windows Terminal (https://github.com/microsoft/terminal/issues/6661) they've just disabled the ability to reorder tabs when the app is running as administrator, otherwise the app will crash when you try to reorder tabs - quite disappointing that they've had to resort to that to address this issue since now you can't reorder tabs when running as admin. And this is in the latest release version of Windows 11 as well.
After two years, I have never seen WinUI team plan to fix this issue.
A shame really as my app also depends on admin access for hardware sensors. For now I just added a safeguard where I disable CanDrag if Admin access is detected.
i think the worst part about this is that it crashes even when dragging within your own application
I'm developping with MAUI 9.0.0 with all latest libs, and when I try to use the drag and drop with a Window compile, that bug occurs if we are admin. Every app that use WinUI sdk crash on drag if admin, what the link between drag and to be admin ?
There is "This needs to be fixed in the drag/drop code, but won't be for a while"
at https://github.com/microsoft/microsoft-ui-xaml/blob/ffe33f9b7d0e9f5a2ca3330d0ce329f09dff092b/src/dxaml/xcp/dxaml/lib/StartDragAsyncOperation.cpp#L104
Any update on this? Or does anyone have an alternative solution/substitution to work around this? We are losing some very cool functionality due to this and can't recommend users don't run in admin mode, due to other xaml issues breaking when not in admin mode.
Is there an easy way to prevent the exception being thrown which results in the crash? I am working on a WinUI 3 app for my client that utilises TreeView controls. The app has to run as admin. I have set "CanDrag" and "CanDragItems" to false on all the TreeView controls, yet they still throw the exception and crash!
The past general guidance is for applications to run as standard user (e.g. see certification guidance here: https://learn.microsoft.com/windows/win32/win_cert/certification-requirements-for-windows-desktop-apps#9-apps-must-follow-user-account-control-guidelines) and elevate privileged operations in a separate process. (This was called out in a newer duplicate issue, so reposting here.)
It'd be good to understand anyone's scenario who cannot fit into this pattern, for instance @andyeder you said your app must be run as admin, why?
Hi, @michael-hawker - thanks for the reply and information.
Unfortunately, I cannot provide any further information due to the sensitivity and nature of my client's work. I realise that this is not a particularly useful or helpful response so please accept my apologies! However, thank you for taking the time to reply - much appreciated.
Thanks @andyeder for getting back to me, much appreciated. I understand if there's sensitive information about things. Is there any generalized information you could provide, e.g. is it a specific other API that you're trying to use within Windows, is it that everything in their environment runs as admin (for some reason), just curious if there's any broader information at play to understand why the app itself needs/requires elevation.
If you still can't provide anything, I understand. I'm just trying to better understand the scenarios around what folks are trying to do to really understand the root cause of the requirements, i.e. is this an XY problem?
Should any code cause a segment violation just because it's run in admin mode...even a graceful exit would be more acceptable. It's so easy to recreate..use visual studio in admin mode and debug a drag and drop program...it causes an immediate segment violation (last tested approx 1 year ago)
