Ive been spending hours trying to find a way around a crashing bug with drag/drop in a Windows app. At the moment it looks like the issue might actually be in one of Xojos DLLs and not in MBS at all, though Windows drag/drop seems to create the situation where the failure occurs.
- Xojo 2015r2.4. (Client still needs XP support.)
- App allows user to drag files from window to another app, or to Windows desktop.
- Frequency of the crash varies with machine tested. Sometimes it happens on the 1st drop, sometimes the 20th.
- Problem does not show on some Windows machines and virtual machines (?) but does on others.
- This is not related to multiple cores (my initial suspicion).
- Also does not appear to be tied to OS version.
- Unaffected machines may simply be the randomness in the frequency. Maybe on those machines it would happen with drop 200. (Ive only tested up to 100 drops. You can imagine how tedious that gets.)
As you drag individual files to the desktop on an affected machine eventually you run into "Access violation - code c0000005 with no useful info in the Windows event log. Xojo exception handlers are not called and the app goes down hard.
If I attach WinDbg to a running app and drag files until it crashes I get the following stack crawl. (Ive changed the app name to DebugApp just so Im not linking public posts to a specific client.)
As Ive tried different things the stack crawl has changed (its consistent for a single build), but it always involves XojoGUIFramework32!getIBeamCursor and MSVCR120!free. In another stack crawl it looked like getIBeamCursor and free were being called twice, like maybe the Xojo runtime was calling free() on an already freed pointer.
Using DisableBackgroundTasks and DisableAutoWaitCursor in the method which calls MBS to start the drag has no effect. (I know DisableAutoWaitCursor is deprecated, but since this seems to be related to cursors I took a shot.)
Something of note: if I use Win32 to lock the window (LockWindowUpdate) or freeze it (SendMessage( w.Handle, WM_SETREDRAW, 0, 0 )) then the crash (if its going to crash) happens immediately upon being unlocked/unfrozen.
I know this is very obscure, but I would appreciate any suggestions.