Hello,
Sorry to hear you are having issues. Need to know your Fences full version number installed.

Please try these steps.

Turn the "Advanced logging" on. Refer the screenshot below. 

When the issue reappear. Please click on the "Create error report package". Just follow the instruction to submit your error report package. Support will look into it and see what is the issue.

Thank you.
Basj,
Stardock Community Assistant.

Hi gizmoo, the team was able to review your log, but word is that it was difficult to sort out what was the action you were intending. The log and the status was sent, but would it be possible to include in the report description or here what the specific names that you had reordered, i.e. was expected, was happened.

Mose useful might be:

- Reorder, wait ~20 seconds (it can take 5-20 seconds to save on delay)

- Capture a backup

- Reboot

- Capture a backup

- Upload report.

The team did verify by hand that saving is happening as expected after re-ordering tabs via the menu, so we're not super sure what's happening. In the logs we'll be looking for the groups saving in the correct order and then looking somewhere for the incorrect order. Having a bit of a hard time figure out how this would happen however, given that a restoring backup fixes the issue. (If it was in the backup, then it was saved. And if it restores, then it was loaded. So- unclear how it could be "reverting" to anything thereafter.)

Thanks for the help

This is after reboot. I worked on several things before rebooting, 

as you can see, the tab has moved, to the middle pos.

this is the backup I made before rebooting, as you can see, Everything is improper position

this is a new backup, As you can see the tabs are out of position

I used fences restore using the good backup, it Put everything back where I wanted it.

the only problem is, after the next reboot, Everything will be out of place again

Hi gizmoo2000 – thank you for the report.

We looked through it, and based on what we found are going to add some addition debug output to see if we can narrow down where this is changing.

Based on what's in the log, we see it start up with this, below. The program outputs every time it loads a group's data.

The first entry is this, which is shortly after the first reboot after turning the logging back on

2025-08-09 01:08:45,856 - LoadGroups - 4 - 7|9607|447|637|102|0|Apps` |\\.\DISPLAY4` |9600|0|1920|1080|0|0|255|0|` |-1|0|0|0|0|{C3D4C75D-F004-4BD7-B16C-B489ABA9B4CC} |2|0|0|

the last 3 numbers are what matters here - of "2|0|0|", the "2" is the groupid, and the first 0 is it's position, zero-based index. the third indicates whether it was selected last. 

The next time we see it appear, it's in the correct position, "1", which is the 2nd position in zero-based index, which is where you wanted it.

This happens right after a snapshot is loaded. So, it would be expected that the correct value would be loaded.

2025-08-09 02:01:27,123 - Restoring Snapshot: a1f2f08f-947a-46ac-8e8e-3bef5575daf1

 2025-08-09 02:01:28,047 - LoadGroups - 4 - 7|9607|447|637|102|0|Apps` |\\.\DISPLAY4` |9600|0|1920|1080|0|0|255|0|` |-1|0|0|0|0|{C3D4C75D-F004-4BD7-B16C-B489ABA9B4CC} |2|1|0|

We then see you take a new backup after loading that other backup, the new one does report the same correct position in that backup file
2025-08-09 02:02:02,330 - Took Snapshot: 220098b0-2256-4d70-92c0-6bd4ab91e4ac / 8/8/2025 10:02 PM

<string>7|9607|447|637|102|0|Apps` |\\.\DISPLAY4` |9600|0|1920|1080|0|0|255|0|` |-1|0|0|0|0|{C3D4C75D-F004-4BD7-B16C-B489ABA9B4CC} |2|1|0|</string>

The system is rebooted

2025-08-09 02:04:34,870 - =========================================================
2025-08-09 02:04:34,870 - ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
2025-08-09 02:04:34,870 - FENCES STARTUP - LOADED pid6140 tid10108, ticks49875

And so far so good, tab reports being in the right spot during load

2025-08-09 02:04:42,107 - LoadGroups - 4 - 7|9607|447|637|102|0|Apps` |\\.\DISPLAY4` |9600|0|1920|1080|0|0|255|0|` |-1|0|0|0|0|{C3D4C75D-F004-4BD7-B16C-B489ABA9B4CC} |2|1|0|

But then, when you take the next snapshot

2025-08-09 02:13:01,650 - Took Snapshot: bf54e63e-af3c-48e6-84b2-1a1227ce19e9 / 8/8/2025 10:13 PM

It's in the wrong position

<string>7|9607|447|637|102|0|Apps` |\\.\DISPLAY4` |9600|0|1920|1080|0|0|255|0|` |-1|0|0|0|0|{C3D4C75D-F004-4BD7-B16C-B489ABA9B4CC} |2|0|1|</string>

So, we're indeed able to see this occur. The next step is, what's happening to make this overwrite occurr.

Some places we're going to debug:

- Output during group saves

- Output when making any changes to tab positions, either manually, or by "correction".

We'll let you know when we have a build to test. Thank you for hanging tight!

Wow, indeed, that is very odd.

Ok WELL. Hopefully this new build gives some insight. It will show as v6.0.2.6 if you hover over the version in About
https://www.dropbox.com/scl/fi/928s2nfgsgz28tv68ypnr/UpdatePatcher_Debug_2025_08_18__9_04_21_pm.exe?rlkey=mo6zlti3a5nlmrh0dgojba8ex&dl=1

It has a bunch more debug output, and we took a swing as well at tightening up one area that could in-theory result in mixing up of tab order during startup. (Rare race condition that technically should never happen, but, the new code drives the possibility down to ~0.)

Let's see how it goes and otherwise what the debug info shows. Same routine as last time. That gave good insight as was shown.

Cheers and thanks again