digitalcreations / MaxTo

Public issue tracker for MaxTo
https://docs.maxto.net
76 stars 5 forks source link

Crashes in DOpus Picture Viewer and on windows shutdown #779

Open eikowagenknecht opened 2 years ago

eikowagenknecht commented 2 years ago

Describe the bug Having MaxTo enabled leads to two problems:

1) Directory Opus crashes on opening windows. Here is the analysis of the DOpus developer: https://resource.dopus.com/t/maxto-crashes-when-opening-image-files/40271

2) On Windows shutdown, errors similar to https://github.com/digitalcreations/MaxTo/issues/409 happen for various applications, e.g. Keepass and Citrix Workspace:

Anwendung: CDViewer.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: Ausnahmecode c0000005, Ausnahmeadresse 10001DAC
Stapel:
   bei System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr, IntPtr, Int32, IntPtr, IntPtr)
   bei System.Windows.Forms.NativeWindow.DefWndProc(System.Windows.Forms.Message ByRef)
   bei System.Windows.Forms.Form.DefWndProc(System.Windows.Forms.Message ByRef)
   bei System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
   bei System.Windows.Forms.ScrollableControl.WndProc(System.Windows.Forms.Message ByRef)
   bei System.Windows.Forms.Form.WndProc(System.Windows.Forms.Message ByRef)
   bei Citrix.DesktopViewer.MainWindow._WndProc(System.Windows.Forms.Message ByRef)
   bei Citrix.DesktopViewer.MainWindow.WndProc(System.Windows.Forms.Message ByRef)
   bei System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System.Windows.Forms.Message ByRef)
   bei System.Windows.Forms.Control+ControlNativeWindow.WndProc(System.Windows.Forms.Message ByRef)
   bei System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
   bei System.Windows.Forms.UnsafeNativeMethods.PeekMessage(MSG ByRef, System.Runtime.InteropServices.HandleRef, Int32, Int32, Int32)
   bei System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
   bei System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
   bei System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
   bei System.Windows.Forms.Application.Run(System.Windows.Forms.Form)
   bei Citrix.CDViewer.InternalLaunchWrapper.LaunchInternal()
   bei System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
   bei System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   bei System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   bei System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   bei System.Threading.ThreadHelper.ThreadStart()

Maxto Log around that time:

2022-01-10 11:19:42 [Core@2.2.1.772] [Error] [MaxTo.Core.Bootstrapper] Process Server exited without explanation
2022-01-10 11:19:42 [Core@2.2.1.772] [Error] [MaxTo.Core.Bootstrapper] Process CompanionX64 exited without explanation
2022-01-10 11:19:42 [UserInterface@2.2.1.772] [Information] [] Deactivated "MaxTo.UI.ViewModels.NotificationIconViewModel". Closed: True

It took me a very long time to rule out memory / hardware problems etc. and pinpoint this to MaxTo. Please fix this as having many crashes makes MaxTo unusable.

Screenshots For 1) see linked thread For 2) image

System information: Windows 10 Version 21H2 Build 19044.1415, but also happens on Windows 11. MaxTo 2.2.1

eikowagenknecht commented 2 years ago

At the very least as a workaround, the ability for MaxTo to not touch some apps would be needed. Like the Compatibility settings, but user defined.

eikowagenknecht commented 2 years ago

Is this product supported any more?

oscillik commented 2 years ago

I am also suffering from this problem, and would really appreciate if this could be looked into.

GPSoft, the developers of Directory Opus have a few threads on their support forum which go into some detail that may assist you in nailing this down.

https://resource.dopus.com/t/maxto-crashes-when-opening-image-files/40271/2

https://resource.dopus.com/t/crash-creating-folder-on-network-share-due-to-maxto-window-hook/29500/8

If required, I'd be willing to send over the crashdumps from Directory Opus if they would be useful to you in getting to the bottom of this.

eikowagenknecht commented 2 years ago

Very disappointed about the support here, I switched to Microsoft Powertoys which is even better in some regards, free and does not crash! 👍

oscillik commented 2 years ago

Unfortunately FancyZones within Microsoft's PowerToys isn't suitable for me, as it seems it lacks the functionality to immediately move a window to a particular position on the grid by keyboard shortcut.

I'm hoping that MaxTo devs can respond soon.

eikowagenknecht commented 2 years ago

Yeah I think it can't do this. But setting the movement to relative position and then moving windows around with win + left/right/up/down works really good.

Defining a good set of overlapping zones needed quite some JSON editing as well, but I'm very content with the result.

vegardlarsen commented 2 years ago

I have so far not been able to reproduce this with MaxTo 2.2.1 and Directory Opus 12.26 on Windows 11 21H2 (22000.493).

oscillik commented 2 years ago

I am running Windows 10 21H2 (19044.1526), and continues to affect me.

Again, I am more than willing to privately send over the crashlogs from Directory Opus if this will help.

LeoDavidson commented 1 year ago

Opus developer here.

Reproducing the problem is very easy:

After not very long, the process will be killed. Crash dumps suggest heap corruption or a callback DLL that has been unloaded.

It's quite frustrating that we are still getting users reporting this problem to us, and thinking it's a bug in Opus, which we then have to investigate only to find it's this issue that's still there. If we can help to fix it, please let us know. Or add Opus to the long list of other apps that MaxTo causes problems with and needs workarounds for. Up to you. Or if there is something we can do on our side to prevent the hook DLL being loaded into our process, we'd be happy to do that too.

Guessing about possible causes, our viewer window can resize itself while it is opening (to fit the image size, toolbars, etc. dynamically as the window opens). That could be confusing things. Some software with UI hooks also gets confused by Opus's multiple UI threads which talk to each other and sometimes have multiple UI threads for the same top-level window.

johanboekhoven commented 1 year ago

I'm just here to support this issue, love MaxTo love DOpus, let's get them to work together flawlessly!

vegardlarsen commented 1 year ago

Just to let you all know, we are very aware of this issue, and haven't been able to pin it down yet. Our regular compatibility shim method (which allows us to disable all MaxTo functionality for a given window) does not appear to work for DOpus.

LeoDavidson commented 1 year ago

Is there anything we can do/provide on the Opus side to help track things down? This issue is over a year old now. :(

LeoDavidson commented 1 year ago

Seems there is no desire to actually fix this, and you're happy for your software to make ours crash and look unstable for over a year now.

I've tried a few times to work out how to block your DLL or window hooks/subclassing from loading into our process, but haven't been able to work out a way.

Our only option now is to detect when the DLL is in our process and display a message to the user to warn them that MaxTo is known to crash other software and should be uninstalled, pointing to this bug report as evidence.

balaji-dutt commented 1 year ago

Seems there is no desire to actually fix this, and you're happy for your software to make ours crash and look unstable for over a year now.

I've tried a few times to work out how to block your DLL or window hooks/subclassing from loading into our process, but haven't been able to work out a way.

Our only option now is to detect when the DLL is in our process and display a message to the user to warn them that MaxTo is known to crash other software and should be uninstalled, pointing to this bug report as evidence.

I've been subscribed to this Issue for a while now but did not want to comment and add unnecessary noise.

I'm a Dopus user and have been affected by this issue as well. I use Dopus far more than I use MaxTo and had uninstalled MaxTo a while back to avoid the crashing issue.

Given the complete lack of updates on this thread, I'm glad I did that and am pretty sure I will never be installing the software again, despite having bought a MaxTo license to support the dev's in the past.

It seems like most issues stay open without any real fixes (apart from issues that can be closed as "read the docs"), perhaps the devs should update the README to state the software is no longer actively supported?