I just installed beta 17, on a new Win 10 x64 Pro laptop:

1) You are installing 48 language files when just one is required.

2) When did you start using the #*@#$!!@&#@!! WebView2? If the answer isn't at least several years ago, does the bug/problem count correlate to that switch?

3) As a curiosity, what are all the xxx.dll.config files for? All but 2 seem to be identical.

4) I imported a DF backup from an earlier beta. When I try to apply the "4K_Top_Centered_Split_Laptop_Bottom" profile, I get the following error:

An error has occurred while applying your new Monitor configuration.
Please check your settings and try again.
Error: Failed to call SetDisplayConfig. [HR: ERROR_INVALID_PARAMETER]
[System.Exception]

I have attached the settings backup I imported.

5) With just DF running, with no profile applied, no triggers, simple stuff:
a) The DisplayFusion.exe PID is averaging over 4000 page faults per second.
b) With multiple apps open, and doing nothing but letting ProcessMonitor run, DF is running over 7% of all registry hits. As always they are just a bunch of spamming of the same items.
c) One thing that may be new, I cannot recall for certain, but around 35-40 percent of all reg reads result in a buffer overflow. This seems to trigger a second - successful, call to the same item (although that could be an artifact of ProcMon). Is this something you can avoid?
d) There are more than a few NOT FOUNDS too.
e) Capture Start: 9/11/2022 10:57:54.6935843 AM
Capture Stop: 9/11/2022 10:58:43.2866472 AM

Not quite 49 seconds, 53652 accesses captured, or a fair bit over 1000 per second. Eyeballing them, I would say that at least 95% of them are complete duplicates - all within less than 1 minute.

6) The DisplayFusion.exe process has maybe 20-25 threads on start address coreclr.dll+0x33400. One of them eats CPU constantly and by itself seems to chew through more CPU cycles than all others combined, a handful seem to run constantly but with much lower CPU cycles, and most are idle excepting the occassional quick flare-up. Here is the stack trace for the main thread, although the look mostly similar from what I saw:

ntoskrnl.exe!KeSynchronizeExecution+0x5b96
ntoskrnl.exe!KeWaitForMutexObject+0x1460
ntoskrnl.exe!KeWaitForMutexObject+0x98f
ntoskrnl.exe!KeWaitForMutexObject+0x233
ntoskrnl.exe!ExWaitForRundownProtectionRelease+0x7dd
ntoskrnl.exe!KeWaitForMutexObject+0x3a29
ntoskrnl.exe!KeWaitForMutexObject+0x1787
ntoskrnl.exe!KeWaitForMutexObject+0x98f
ntoskrnl.exe!KeWaitForMutexObject+0x233
ntoskrnl.exe!KeWaitForMultipleObjects+0x45b
win32kfull.sys!xxxUpdateInputHangInfo+0x10d2
win32kfull.sys!xxxUpdateInputHangInfo+0xca5
win32kfull.sys!+0x2268
win32k.sys!EngSaveFloatingPointState+0x45a2
ntoskrnl.exe!setjmpex+0x7c75
win32u.dll!NtUserWaitMessage+0x14
System.Windows.Forms.Primitives.dll+0x2630e
System.Windows.Forms.dll+0x75d88f
System.Windows.Forms.dll+0x75fd1d
System.Windows.Forms.dll+0x75fa08
System.Windows.Forms.dll+0x454a31
0x0000000000000000

7) I would think that the lion's share of the app is based on registering event watchers, likely with a smattering of event timers as well. In my quick review of some thread stacks I didn't see many *Event* threads. The couple I came across were on threads that were using no CPU, as expected.

On the hole, I think that the performance may be a bit better. I cannot be certain because I don't want to pull out the ProcMon traces I have sent in the past. Also, my new laptop has a FAR more powerful CPU than my last laptop did. I think the IO may be down a good bit? But there is clearly just way too much registry spamming going on.

I am going to do a reboot and see if I can successfully switch to the Profile I had saved. I hope I don't lose all of those!! Because I (used to) travel a good bit, I have a wide array of monitor configs created.

Oh, I attached the DF Troubleshooting text. Let me know if you need more info/debugging.