Nasty crashing bug using MBS WinDragDrop

General
1

I’ve 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 Xojo’s 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. (I’ve 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. (I’ve changed the app name to “DebugApp” just so I’m not linking public posts to a specific client.)

0x656c0509 XojoGUIFramework32!getIBeamCursor+0x52b4 USER32!InternalCallWinProc+0x23 USER32!UserCallWinProcCheckWow+0x109 USER32!DispatchMessageWorker+0x3bc USER32!DispatchMessageW+0xf XojoGUIFramework32!MainExport+0x72b MSVCR120!free+0x1a XojoGUIFramework32!MainExport+0x89e XojoGUIFramework32!MainExport+0x8ca XojoGUIFramework32!RuntimeStackCheck+0x21 XojoGUIFramework32!MainExport+0xeb DebugApp+0x1382 DebugApp+0x1718 kernel32!BaseThreadInitThunk+0xe ntdll!__RtlUserThreadStart+0x70 ntdll!_RtlUserThreadStart+0x1b

As I’ve tried different things the stack crawl has changed (it’s 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 it’s going to crash) happens immediately upon being unlocked/unfrozen.

I know this is very obscure, but I would appreciate any suggestions.

2

If it is a bug in the framework you may be SOL
There wont be a fix for it beyond “update to a newer version”
And yes it is possible there is a use after free or double free. Joe & William have fixed several that I know of.
One of the advantages of using newer tools (like Xcode 7.3 and VS 2015) is they also have better tools to help us identify those kinds of issues.

Not sure if the tools joe mentioned might give you a different perspective

3

Thanks for the reply Norman. I will definitely look into the tools in Joe’s post.

I just tried 2016r1 on one VM and did not encounter the crash. I have to try a number of VMs and test machines to be sure it’s gone due to the random nature of the crash.

If it IS fixed in 2016r1 I certainly can’t complain. You guys can’t be expected to support old OSes forever. I would rather tell my client “look guys, XP is gone” then “this key feature just doesn’t work (or won’t work for a while).”

I’ll keep digging. Thanks again!

4

WinDbg can only display the closest exported symbols. There aren’t 21172 bytes of instructions in getIBeamCursor.

See the documentation on creating crash dumps or you can use the .dump command inside of WinDbg.

5

Joe - I’m going to perform more testing tomorrow, but the bug appears to be fixed by Xojo 2016r1.

I don’t know if you’re interested in a full crash dump if 2016r1 resolves it. I’m guessing no, but if you would like me to create a crash dump any way I will.

Thanks to both of you for your quick responses. I will relay to my client that one of the great things about using Xojo is you can often get a quick response from Xojo staff via the forums, even over a weekend.

6

I’d take a very quick peek if you put it on Dropbox or something.

7