Two local user profiles that simultaneously use DisplayFusion cause CPU usage / access issues

WARNING: You currently have Javascript disabled!
This website will not function correctly without Javascript enabled.

Legoguy

8 discussion posts

I'm editing this post to reflect further troubleshooting that I did.
I have a Personal user profile and a Work user profile on my home machine. I flip between them when necessary. Both are set to fire up DisplayFusion when the profile logs in.
I often log both profiles in simultaneously so I can switch between them quicker based on my current task. This used to work perfectly fine, but sometime recently something changed (like, between 10.0 Beta 12 and Beta 17). After upgrading to Beta 17 I noticed that if I log in both user profiles simultaneously (by using the lock screen), the two instances of DisplayFusion don't play well together. The first-launched instance is fine. The second-launched instance consumes 5 logical cores of CPU and fills the log with this:

Code
Copy
Select All

2022/11/28 10:13:38.0131##_##INFO:L3##_##displayfusion.exe:51288##_##BFCache:GetItemTHROWS:155##_##-##_##[BFCache:Cache_GetProcessMainFileName] Item Load From Cache [67.788s]: 51492##_##-
2022/11/28 10:13:38.0131##_##FAIL:L1##_##displayfusion.exe:51288##_##BFIpc.Server:StartIpcHandlerWorkerTHREAD:141##_##-##_##Access to the path is denied., [System.UnauthorizedAccessException]##_##-

sprinkled with some other bits as well that were much less frequent.
It seems like they are trying to both operate on the same file at the same time; I'm not sure which file, though. It was my understanding that most of the storage used while the application is running is in the %LOCALAPPDATA% directory, which is where log files and other information are stored, and would be unique to each user. Is there something else afoot? Debug logs of the "second launched instance" attached.

• Attachment [protected]: DisplayFusionDebugInfo.zip [116,448 bytes]

Nov 28, 2022 (modified Nov 28, 2022) • #1

Interesting, you can find our older beta versions on this page: https://www.displayfusion.com/Download/Beta/.

If you roll back to Beta 12 again, can you confirm this issue goes away? You can run the installer directly overtop of your current install.

Thanks!

Nov 29, 2022 • #2

Legoguy

8 discussion posts

Quote:

If you roll back to Beta 12 again, can you confirm this issue goes away? [...]
Thanks!

Yes. I rolled back through the beta releases one by one (starting with 17) and ended up with a working (no conflicts between logged in users) setup at Beta 13. So something between Beta 13 and 14 caused this. I have yet to try 18 (given its very recent release), but I will try that next.

[edit] Beta 18 is still prone to this issue.

I don't see anything specific in the changelog between 13 and 14 that screams "caused this issue", but two thing stand out as possibilities... .NET 6, or the UWP app path update stuff. Just some speculation from a fellow developer. Let me know if you need anything more!

P.S., I notice some strange behaviour when switching profiles for logged-in users (this is on all the Betas I've tested including 18 ). If I open the start menu and switch to another logged in profile via the user right-click menu, oddly the user that I switch to already has the start menu "open" when the switch is complete. This occurs regardless of how I open the Start menu, be it with the Windows key or by clicking it. Odd...

Dec 2, 2022 (modified Dec 2, 2022) • #3

Thanks for confirming, we're going to see if we can reproduce this locally. We'll let you know if we need any other info.

Thanks!

Dec 9, 2022 • #4

This issue should be fixed up in the latest beta, available here: https://www.displayfusion.com/Download/Beta. Please let me know if you still run into any trouble after updating.

Thanks!

Jan 13, 2023 • #5

Was this helpful?

(-)