Sometimes stuck in automatic restore (red)

[SciLor]

Once a while, when I start my computer from hibernation, PW sometimes is stuck in the restore. To fix it, I'll have to restart PW, but lose all my window positions.

[Rassi]

I've experienced VS Code being the reason why PW sometimes can't restore, when it tries to update in the background. You can identify the blocking program via Task Manager or Resource Monitor by running "Analyze wait chain" as described in Readme.

[SciLor]

It may make sense, that PW detects, that a window cannot be restored due to that. Those windows could be put onto a blacklist after prompting a warning to the user.

[kangyu-california]

@SciLor I have yet to find out the API to accurately tell whether a window can be restored, so far I have used User32.IsHangAppWindow() API and process.Responding attribute, none of them can forecast that the vscode window will be blocking PW restore.

[SciLor]

What about starting restore of each window in a thread. If it takes to long, it can be aborted. The restore of all windows could be done in parallel (if not already)

Where does the code hang on detail? https://github.com/kangyu-california/PersistentWindows/blob/2ae0c12bdbb181415626cc9bc7095419f35010d2/Ninjacrab.PersistentWindows.Solution/Common/PersistentWindowProcessor.cs#L3191

[kangyu-california]

@SciLor PW hangs on calling Windows APIs such as SetWindowPos() etc.

The issue occurs monthly on my side, mostly due to vscode pending upgrade. The workaround provided in readme is totally acceptable by most users, I don't understand why you would like me to revamp the whole restore algorithm to address this minor issue without fully understanding its root cause and proper risk assessment for your proposal.

[SciLor]

The issue occurs multiple times a week for me. From the user perspective, it is not feasible to open another tool to find out the source. Solving it could be closing the application, bring it to foreground or ???. If someone is tech-savy this may be a workaround, but for people not understanding this it will just end in: This app is not reliable.

The root cause is, that the window is not reacting to the Window Messages / API Calls and blocking the calls.

There would be two ways to fix this:

Synchronous workflow (no workflow changes needed)

• Find the easiest window message / call that hangs
• Implement a IsHangAppWindowTimeout with the help of that call
• Call IsHangAppWindowTimeout if IsHangAppWindow is true

Risks:

• Restore could be slower, depends how long the IsHangAppWindowTimeout would need for the check.

Refactor the method and have a RestoreWindow() method

• Put the window restoration in its own method RestoreWindow()
• Call the RestoreWindow() asynchronously
• Wait for RestoreWindow() to finish, or stop it after a timeout.

Possible variant:

• Restore all windows asynchronously, don't do one after the other.

Risks:

• More code to work on means more possible bugs and testing.

[kangyu-california]

@SciLor Any chance you turned on -fix_zorder=1 switch on command line, which would call EndDeferWindowPos() API for every auto restore to adjust z order in batch (changing z-order for windows in parallel) this command option has side-effect of higher chance of hitting this issue.

Your proposal is good, but i really don't have luxury to do more experiment, I have already spent a lot of hours on resolving various issues (many of them should not be attributed to PW at all). At some point, we have to agree Windows OS is a magic box that nobody should claim to be an expert for all aspect of it. It is just too harsh to expect PW to work well on every corner case to achieve 100% success.

[SciLor]

No, I am using PW in the default configuration. I'll do some experimenting and create an PR on success for variant 1.

[kangyu-california]

Windows OS may occasionally fail to update PW icon back to idle color, even though the restore has finished. To force restore PW icon back to idle color, click mouse middle button on PW icon.