Tabs

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.

Version 6.00 Business Edition, checked for updates, nothing. 

turned on the logging, will send you a report.

You got a pretty rough job, Considering the insanity of Microsoft, to bad you don't have a Linux version. 

Mike Hoida

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

if I use the menu, tabs, move tabs left, they move, and are fine until when I boot up the computer the next day. then they are reverted back to the original positions. I can do a backup in fences, and the next day use that backup to put them back to the new positions I wanted them in. 

this is starting

this is where I wanted them moved to

I can do a backup in fences. it saves everything

now when I reboot, the tabs will be back in the starting position

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

Yes this should definitely not be happening. Thank you for sharing the screenshots for point of reference, so that we know what it SHOULD look like.

What is unclear is: When you load a backup, it loads that specific configuration into the registry and reloads settings from scratch. There is no difference between that and restarting your computer. So. Trying to figure it out.

I don't know that the logs have enough info to show this, but since we want to get this resolved for you let's do this step:

(1) Ensure Advanced Logging is enabled from the Troubleshooting dropdown in About. Enable it if it is not, and log off / on or reboot to make it take effect.

(2) Load the good backup.

(3) Take another backup. (Dumb but, we'd like to see what the registry looks like at that point, since a backup captures this.)

(4) Reboot

(5) Take another backup, assuming it's messed up

(6) Immediately submit a report via Troubleshooting → Capture Debug Report

We'll take a look and try to see what pops out, or, figure out what debug statements we need to get put in. This isn't something we've seen so we would love to get this resolved for you.

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!

It does get a little bit stranger, after several reboots the tab eventually moves all the way back to the third position, were it originally was before I started moving the tabs around. But that usually takes several reboots when I leave it in the second position rather than reloading from the backup and moving it back to the first.

1 first reboot moves the tab back to the second position .

If I leave the tab there, in the second position, after a couple more reboots it will eventually move back to the third position where it originally was before I started moving the tabs around. 

On the upside, I activated the tab hover to activate tabs, so I've been using that instead of moving the tabs around. That works really good. 

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

Hi gizmoo2000, had any chance to check out the debug copy above? Thanks for any insights

Hi Dr W, been really busy, but I did not forget you. installed the update, V6.0.2.6, rebooted 3 times without any problems with tags moving back to previous positions, sent a report. Normally they start moving back to the original position after the first reboot. I will keep you updated over the next few days if they start moving again after booting up.

Thanks

Mike Hoida

Great! Yes based on what we saw we did find one “this should never happen” type situation that could in theory result in something like this, and improved it so that I could for-sure never happen, so with luck this will be resolved! Thank you for the report