Currently, we are investigating a similar report, so I will share our current observations on it. Please tell us whether they seem applicable to your scenario, or we should be looking somewhere else for the source of this issue.
Some time ago we stumbled on a memory leak in DragDrop.DoDragDrop, which can cause a massive memory footprint in some scenarios. In the SP version 2016.3.1024.45 we introduced a fix for it. To prevent the memory problem we decided to pass a WeakReference to the dragged data to the method, instead of the dragged data itself. To avoid a potential breaking change in the Telerik DragDrop events args, we added internal logic that deserializes the passed WeakReference and exposes the original drag data in the event arguments of Telerik DragDropManager's events. However, we cannot guarantee this for the original WPF DragDrop events, as we do not have direct control to this logic. Thus if one subscribes to UIElement.Drop instead of DragDropManager.Drop, the event arguments would contain the WeakRefence to the data instead of the data itslef.
I am attaching a sample project that I prepared regarding this scenario. It does not use RadGridView, but the logic should be pretty similar as DragDropManager should be completely control independent. The first option is to use UIElement.Drop, but uncomment the logic marked as workaround in the comments. The other one, which is recommended, is to stick to DragDropManager.Drop.
Telerik by Progress
Do you need help with upgrading your WPF project? Try the Telerik API Analyzer
and share your thoughts!