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. *** This may simply be the randomness in the frequency. Maybe on “unaffected” 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 would appreciate any suggestions. Daniel L. Taylor Taylor Design Computer Consulting & Software Development [email protected] www.taylor-design.com _______________________________________________ Mbsplugins_monkeybreadsoftware.info mailing list [email protected] https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info
