Custom region setting lost on reboot

[scottjenson]

1. Create custom region layout, save
2. Test recipes so hotkeys are snapping to correct regions
3. Reboot
4. MaxTo doesn't remember region so every maximize command now goes full screen
5. Open MaxTo>regions>Load Preset and reselect my saved region layout
6. Everything works normally

It appears my Preset is not saved across reboots, I've looked in settings for a 'save this preset for this monitor' type of setting but can't find anything.

Apologies if I'm just not RTFM. I assume this isn't really a bug but it is frustrating to have to remember to reload my preset after every reboot

[vegardlarsen]

You are not the first to report this issue, but I haven't been able to figure out what is happening exactly. Just two quick control questions:

1. When you say "save" in point 1, you mean that you clicked "Use regions", not "Save as preset"? If you don't click "Use regions", the regions are not applied.
2. Does MaxTo start successfully after a reboot? Meaning is the icon present in the notification area?

It would be helpful to see logs of this happening; preferably limited to logs just walking through the steps you outlined. See this page to find your log files.

PS! Sorry for the slow response. I have been sick this week.

[josezulu]

I am observing this same issue. It happens not only at reboot but also by closing the program and starting it again.

I have a preset saved, I load it, then I choose "Use regions" to apply the change. Restart the program and there are no regions defined.

Yes, MaxTo starts up fine when windows starts, shows in the notification area.

I found a workaround
Set the monitor settings to "Properties". I had it on "Number".

This error shows up in the logs repeatedly when I close the program:
System.IO.IOException: Pipe is broken. at System.IO.Pipes.PipeStream.WinIOError(Int32 errorCode) at System.IO.Pipes.PipeStream.BeginWriteCore(Byte[] buffer, Int32 offset, Int32 count, AsyncCallback callback, Object state) at System.IO.Stream.<>c.<BeginEndWriteAsync>b__53_0(Stream stream, ReadWriteParameters args, AsyncCallback callback, Object state) at System.Threading.Tasks.TaskFactory 1.FromAsyncTrim[TInstance,TArgs](TInstance thisRef, TArgs args, Func 5 beginMethod, Func 3 endMethod) at System.IO.Stream.BeginEndWriteAsync(Byte[] buffer, Int32 offset, Int32 count) at System.IO.Stream.WriteAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken) at MaxTo.Core.Communication.NamedPipeServer.<Send>d__26.MoveNext()

[scottjenson]

Having a hard time reproducing. I just rebooted and it actually worked. However, in shutting down, I did get a write to memory error from MaxTo (photo attached as I couldn't take a screen grab)

[josezulu]

@scottjenson
Ok, I just rebooted to try that out: I didn't get any errors like the one you show.
When the machine completed booting up, the regions were loaded properly.

I'm on Windows 7 though, it seems you are on 10? Don't know if that matters.

[vegardlarsen]

@scottjenson I think the screenshot may be a conflict with "Speech and Handwriting Recognition", which is a feature for Microsoft Office. Unless you are using that feature, can you try uninstalling that part of Office to see if it works? This may be something we can fix if we can verify that this is indeed the case.

However, this should not in any way be related to losing your regions. The regions are saved to disk by a process called MaxTo.Core, and MaxTo.UI only has read-only access to them.

@josezulu The error you linked should not be related either; it happens quite consistently when MaxTo exits if one of the processes exits a bit quicker than anticipated.

[scottjenson]

OK, I'll try when I get home. I didn't think I even had Office installed so if it's on, it's not by intention. I'll find and turn off.

As to my problem, the only thing I can guess is that my default region setting is saved now so things seem to be working fine. My only guess is that the bug was in the setting not getting saved properly. Of course, I could have done something wrong. I didn't answer your previous question though. I did save the region and gave it a name, "1-2-1" which always shows up at the bottom of my region list. I noticed it getting lost maybe three times. But as I said, it's saved now.

[dixon]

I found a workaround
Set the monitor settings to "Properties". I had it on "Number".

Confirming what @josezulu reported; mine were on "Serial number" and changing to "Properties" fixed the issue.

Running on Win10 with elevated privs.

[vegardlarsen]

@dixon @josezulu

To get to the bottom of this, I have create a tiny application that logs out everything MaxTo knows about your monitors and virtual desktops when it is run. It will create maxto-output-{timestamp}.txt in the same folder when it is run, so the contents of files ran at different times can be compared.

Here it is: Debug.zip

I would have made this as a LINQpad script or similar, but there are issues relating to application manifests that you just can't do in scripts. I have digitally signed both files in the archive using the same key as MaxTo is signed with.

Please run this file once before it happens (as a baseline), and once immediately after, and send me all the results? It would also be helpful to get a ZIP file of your %AppData%\MaxTo directory (exclude the license.txt file if you upload it here, you can send it to the support e-mail if you'd like). Log files may also be helpful.

[vegardlarsen]

Thanks to input from @dixon, we figured out the issue was from serial numbers containing illegal characters in the file name. We will release 2.0.1 today to remedy this issue (and some other crashes).

[quantum-x]

I could confirm that on "Number" monitor identification, I have the same issue, running 2.0.1

[vegardlarsen]

@quantum-x Please try out the 2.1.0 previews, which has some fixes that will probably remedy this (likely a different problem than this thread).