High CPU usage (and other issues) when folder tree locked

[Heraes]

Hello,

I've spent all the day trying to configure Opus Directory.
Suddently, it went bugging for no reason except DO itself.

Here's the steps :

1. I've tweaked it to change the toolbar. I save it with that technic : Image toolbar position doesn't get saved

2. I've tweaked the middle-clic following that technic : Middle-click to open in new tab - #10 by gasper.alemao

3. I've tweaked tons of other stuffs. Can't track those changes, but they are minor.

4. I've saved windows of DO ("list" feature).

Then :

5. I tried to open several windows, and it start bugging.
   5.1 : Firstly, the default window was never saved, and instead it was a NOT CORRESPONDING window with absence of the TABS I had choosed to be opened by default.
   5.2 : Secondly, the CPU was highly used (~11%) with W10 lagging as hell.
   5.3 Thirdly, using the BUTTON called "Saving the list as default" is systematically making an ERROR ALERT (windows' error sound) and nothing pops up. A menu seems to be hidden BEHIND the DO window, and I can't click on it, and clicking on the DO window does nothing more than replaying the sound. It's stuck, and I have to KILL the DO process.
   5.4 I tried restarting DO but nothing changed.
   5.5 My keyboard became stuck.
   5.6 I restarted my computer, and my keyboard was like deactivated during logon. I switched to another keyboard in USB and still, nothing typed was taken into account (no character typed).
   5.7 I was ready to call people to help while trying to figure how to start in SAFE MODE (but wasn't able, because for that you need to ENTER Windows10 and to go into MSconfig, wich I was unable to perform because of the ■■■■ing keyboard disabled), and restarted a second time, then the keyboard went back to normal.

To debug :

6. During one of the previous steps, I used PROCESS EXPLORER, and found the DLL of DO that was involved :

Now help me to understand how a software development can be THAT CATASTROPHIC, please.

[Leo]

@Heraes

5.1 : Firstly, the default window was never saved, and instead it was a NOT CORRESPONDING window with absence of the TABS I had choosed to be opened by default.

How did you save the window?

How are you opening the new window?

(Which menu items or actions, and what are those actions configured to do in Preferences, if applicable.)

@Heraes

5.2 : Secondly, the CPU was highly used (~11%) with W10 lagging as hell.

If you're seeing high CPU usage with Opus, send us some process snapshots made during the heavy usage and we'll take a look.

@Heraes

Thirdly, using the BUTTON called "Saving the list as default" is systematically making an ERROR ALERT (windows' error sound) and nothing pops up. A menu seems to be hidden BEHIND the DO window, and I can't click on it, and clicking on the DO window does nothing more than replaying the sound. It's stuck, and I have to KILL the DO process.

Do you have anything installed that might be modifying other programs' windows? Anything that changes the way other programs look, or adds elements to window titlebars, or that helps move/resize other programs' windows?

@Heraes

5.5 My keyboard became stuck.
5.6 I restarted my computer, and my keyboard was like deactivated during logon.

There is no way that Opus could affect your keyboard, especially after a reboot and before you've even logged in.

That kind of thing sounds like a more general issue with the computer or drivers, or even a loose cable.

Whatever's causing that may be involved in the other issues.

[Heraes]

There is no way that Opus could affect your keyboard, especially after a reboot and before you've even logged in.

I know perfectly when a software is involved in a massive bug. I've never lost my keyboard input in 17 years of computing. Don't discharge yourself from the responsability.

If you want, I can show you IN LIVE how your software is buggin.

We have several options

1. Discord screen sharing.
2. VNC like AnyDesk.

Chose your horse.

How did you save the window?

With the button you offer in the toolbar edition.

How are you opening the new window?

You kidding me ?

If you're seeing high CPU usage with Opus, send us some process snapshots made during the heavy usage and we'll take a look

I precise that those 11% are accompanied with complete W10 GUI stuttering / being stuck.

Do you have anything installed that might be modifying other programs' windows? Anything that changes the way other programs look

No.

[DesertDwarf]

Bear in mind, there are thousands of us using DOpus (and have done so for many years) without the issue you are experiencing.

If you supply them (Jon and Leo, the developers) with the data they requested, 99% of the time they will find the problem and have a solution. Following their suggestions is key to solving the issue that only you are having.

@Leo

send us some process snapshots made during the heavy usage and we'll take a look

If you click the link Leo provided and follow the instructions, you'll be providing them with the data they need to resolve it. The snapshot he requested is not a screenshot.

[Heraes]

Oh yes, sorry, I confused the term "snapshot" (I'm french).
I'm gonna make the correct snapshot as requested. Is it necessary to wait for the bug to reappear, or can I send it now (right now DO is not bugging) ?

[Leo]

@Heraes

Don't discharge yourself from the responsability.

Equally, don't blame Opus for hardware issues it couldn't possibly be involved with.

Please also link your account if you want to argue with us like this.

@Heraes

If you want, I can show you IN LIVE how your software is buggin.

The process snapshots I asked for would be more useful, at least for the CPU issue.

(The keyboard issue is categorically not Opus. It's impossible for Opus to do that. Opus isn't even running before you've logged into the machine, and Opus has no way to affect the keyboard across a reboot. It's simply impossible.)

@Heraes

With the button you offer in the toolbar edition.

That isn't the default toolbar, but it looks like the Set as Default Lister button (Prefs SETDEFAULTLISTER) that's usually in the Settings menu.

Make sure Preferences / Launching Opus / Default Lister / Update Default Lister automatically when closing a Lister is not turned on, as that would cause the default lister to be overwritten when a window was closed.

But the issue may also be that the default lister isn't what's being opened...

@Heraes

You kidding me ?

No, I am not. There are about 10 different ways you can open windows in Opus, and they can all do different things depending on the configuration or the action being performed. They may be configured to open a layout or to open a single, specific folder rather than the default lister.

[Leo]

@Heraes

Is it necessary to wait for the bug to reappear, or can I send it now (right now DO is not bugging) ?

The snapshots need to be made while the high CPU usage is happening. We can use them to see which code is executing and using the CPU.

It's important to make more than one snapshot while the issue is occurring. The instructions I linked have full details.

[Leo]

@Heraes

During one of the previous steps, I used PROCESS EXPLORER, and found the DLL of DO that was involved :

Another thing to note: That just shows that the thread using the CPU was started by Opus. Most threads in the process will be, of course.

You need to select that thread and click the Stack button to see which DLL is currently executing, which may indicate where the problem is. (How to find components causing high CPU usage has instructions.)

But the process snapshots will contain the same information, so we can do that investigation for you as well.

[Heraes]

File transfert completed (912,8Mo). Could not compress it with 7zip in ultra, took ages for no size benefit.

[Heraes]

Still cannot save a window of DO as a default window even by using the menu "Settings" > "Define as the default list" : it produces the same bug (stuck with error sound) than when using the button in the toolbar. Have to kill the process.

Make sure Preferences / Launching Opus / Default Lister / Update Default Lister automatically when closing a Lister is not turned on

I want it to be turned ON, because i want to save the last closed window as the next one to reopen next time I launch DO.

The "default window option" should NOT conflict with the "reopen last one" : it's two different things.

1. When I use an explorer, wether it is Windows' explorer with QtTabBar or anything, I always organize myself to close one of my explorer windows in the last order (I close all other ones, then I close the one wich I considere to be the most "common" one in last). So the next day, I reopen my "main" window (the last one) by just cliking on the software icon (it reopens automatically the last window, and it's useful).

2. Opening a new window/list, should NOT be related to that mechanism : I want a blank window to be opened, with only one tab per vertical view. In that purpose, in DO I create a new window (in DO, it opens the same window as the one already opened with all the tabs) then I close all the tabs except one (I position its content on "my computer" so it's neutral) and try to save it. But because of the bug, I can't save it, it stays STUCK and I have to kill DO.

[Leo]

@Heraes

Do you have anything installed that might be modifying other programs' windows? Anything that changes the way other programs look, or adds elements to window titlebars, or that helps move/resize other programs' windows?

No.

I don't know if it's involved, but the snapshots show you have RBTray installed, which helps to move/resize other programs' windows. It also installs a mouse hook DLL into the process.

It may not be involved, and we haven't run into problems with it before, but we have seen similar tools get confused by Opus's windows/threads in the past, and cause strange issues. For example, if it's minimising the confirmation dialog when it doesn't expect it to happen then it might cause the issue you're seeing with the dialog being hidden and beeping.

@Heraes

File transfert completed (912,8Mo).

There are only two snapshots in the zip we got. (The instructions suggest making 5.)

The first snapshot indicates the whole process is idle and waiting for input. Can't see any issues with that one, at least of the type that we can see via snapshots.

The second snapshot indicates the Prefs command is running and showing a confirmation dialog, which fits what you're describing. The dialog should be visible, so if it isn't something on the system seems to be breaking or hiding the dialog. (The beep most likely indicates that the window with keyboard focus isn't visible/enabled, or similar.)

Other than that the snapshot shows that there are a couple of listers open. One that's showing the confirmation dialog and repainting some toolbar buttons while it is open. The other lister is in the responding to a resize or layout change, which seems odd, actually; that would not normally happen in response to the Set as Default Lister command.

Are any scripts installed which might be triggering events? That's another possibility.

Was the high CPU issue happening when either of these snapshots were made? Or are the snapshots for the other issue with the invisible confirmation dialog box? (Or is the high CPU usage only triggered at the point the confirmation dialog should appear? Are there two issues, or just one?)

More snapshots taken during the high CPU usage would be useful, so we can see if it's always executing the same code.

I'd also recommend testing whether uninstalling RBTray makes any difference, in case it is involved. It may not be, but it's worth a try.

[Leo]

@Heraes

I want it to be turned ON, because i want to save the last closed window as the next one to reopen next time I launch DO.

The "default window option" should NOT conflict with the "reopen last one" : it's two different things.

If you want it on then you don't need to save the default lister, because it's being saved every time you close the window.

If you want to open something other than the default lister sometimes, you can use a layout for that.

[Heraes]

The other lister is in the responding to a resize or layout change, which seems odd, actually; that would not normally happen in response to the Set as Default Lister command.

Yeah, the list opening when I first click on DO icon (after a reboot for instance) was broken : not only it was not containing any of the tabs I want, but the toolbar set was not loaded.

I solved it by opening a predefined list, closing the first list (the "default" one), then closing that second list : then, when relaunching DO, it opened the second one because it was the last one closed.

Still, opening a new list when one is already launched opens... the one who is already launched, wich is unexpected. I think I'm gonna use your technic of saving a blank list as a layout. But it's a shame that the default list/layout doesn't work.

If you want it on then you don't need to save the default lister, because it's being saved every time you close the window.

No no no, this is two different things : I won't rewrite what I already perfectly explained. Please re-read the two paragraphs with 1 and 2 numbers in the bullet list. It's really two different and non-redondant things (you don't have to stop using one when using the other, both can be expected to be used in parallel).

Are any scripts installed which might be triggering events? That's another possibility.

No, no script running.

Was the high CPU issue happening when either of these snapshots were made?

I don't remember if the first snapshot was in normal condition or was already consumming 11% of CPU. Sometimes the CPU usage is triggered randmly by just clicking on the tabs / opening new lists, sometimes it's when the UI is stuck as during the popup problem.

Are there two issues, or just one?

Clearly, there is two problems (that can occur both at the same time) :

1. CPU usage of 11% + stuttering of the GUI of W10.
2. DO is stuck (popup problem).

When 2 occurs, 1 occurs too. But I don't manage to make 1 to appear again consistantly.

I'll give a try with closing RBtray and testing.

[Leo]

@Heraes

Yeah, the list opening when I first click on DO icon (after a reboot for instance) was broken : not only it was not containing any of the tabs I want, but the toolbar set was not loaded.

We've seen that happen when the config file gets corrupted during shutdown.

The way the code is written, it should not be possible for this to happen on a normal system. (It is completely written out to a temp file, then the old and new files are renamed to swap them. A partially written file should not be possible.) But something sometimes breaks things.

We aren't sure if it's due to antivirus or Windows itself but for some reason XML config files written just as Windows is shutting down can sometimes be corrupted, at least for some people. We've never run into it ourselves, but it also seems to happen quite rarely even for people who have seen it, so maybe we've just been lucky.

@Heraes

No no no, this is two different things : I won't rewrite what I already perfectly explained. Please re-read the two paragraphs with 1 and 2 numbers in the bullet list. It's really two different and non-redondant things (you don't have to stop using one when using the other, both can be expected to be used in parallel).

I don't understand in that case, sorry. But this should be in a separate thread anyway. Let's stick to one thing at a time, and keep this thread to your CPU / dialog issue.

@Heraes

I'll give a try with closing RBtray and testing.

Please do and let us know, and send us more snapshots if the CPU issue happens again.

It might also be worth checking if you see problems when using a default config with default toolbars (after backing up your current config, of course). The second snapshot indicated that toolbars were being repainted, so if there is something unusual in the toolbars which is causing them to keep repainting themselves, that might explain things. But it could just be a coincidence; we can't make many judgements from a single snapshot as we don't know if it just happened to be repainting a toolbar at that one time, or if it was constantly repainting toolbars (which more snapshots would show).

[Leo]

Thanks for the new snapshots and video.

I noticed a big detail in the snapshots: Opus is responding to a message telling it that its toolbar icons have changed size, which causes it to do a lot of expensive calculations. That message seems to be happening repeatedly, which should not happen unless:

• The toolbar icons keep being changed on disk. I don't think that is happening, as we can see the date/time on the icons folder in the video and it's not changing.

• Something is generating incorrect filesystem change events telling Opus the icons are changing when they aren't. That is possible, but not something we've ever seen before, except when certain NAS devices are involved. Assuming Opus and the user profile are both on a normal, local drive, we can probably rule this out. (We have seem Kaspersky mess up the notification system in other ways, FWIW, but it caused missing rename events, not phantom extra events, so I doubt it would be doing this.)

• Something is sending/broadcasting private window messages in the WM_APP range to other program's windows. This is something we see occasionally, and seems the most likely explanation, at least from what I know so far. Some programs do this, usually because they're trying to send a message from one part of themselves to another and just use HWND_BROADCAST instead of finding their window properly. The effects are completely random, since message numbers in this range mean something different to every programs (or even different versions of the same program). Usually, the message doesn't mean anything to most programs, or causes something to happen that is not noticeable, so the problem goes undetected, but if it means something to another program then it can cause pretty much anything to happen. Windows also provides no general way to block the messages or to find out which process they came from.

To test if the last thing is happening, I've written a tool which logs the window messages it receives. If it receives any messages within the private ranges (WM_USER and WM_APP) it will add a special note at the top of the window. If that is happening, something on the system needs fixing.

(Unless it's triggered by Opus itself. I've made the test program pretend to be an Opus window, in case something is looking for Opus specifically. Opus itself may therefore see the window and think it's a part of Opus and send it a private message, but you can test if it's coming from Opus by closing Opus.)

Normal situation:

After sending an illegal message via another program, the illegal message stays as the top line so it can't be missed if other messages scroll it off the screen in the main list:

WindowMessageReporter_v1b.zip (107.2 KB)

By the way, config reset options for Preferences are in the File menu of the Preferences dialog. For toolbars, right-click the empty space on the toolbar for them. You can also uninstall the program and reinstall it to get back to a default config.

[Leo]

(I've replaced the program above with a standalone re-compile that doesn't need any Visual Studio packages installed.)

[Heraes]

Hello @Leo ,

Sorry for the late answer, and thank you to have taken some time to built that tool. It's very professional, and I appreciate it.

I've performed a new double test, everything has been send by email. Nothing seems to interact with the window, DO may be bugging by itself because of a conflict in its options.

As I forgot to give you my DO settings (I think it could be useful), I add it here in attachment.

full_configuration_bugging.ocb (69.4 KB)

Assuming Opus and the user profile are both on a normal, local drive, we can probably rule this out.

Yes, all my softwares are either installed on C:, or in portable version and "installed" on D:, and both are on the same local SSD. However, I have a HDD mounted as a network drive (P:), but I don't see how it could interact.

[Leo]

Thanks for the config!

I was able to reproduce the problem using the config, which revealed both the high CPU and dialog issue happened if:

• The folder tree was locked, and
• Two toolbars shared the same row, and
• One toolbar had the Thumbnail Size field while the other had the Search field (or some other combinations of fields).

If all three were true then the problem happened.

(Trivia: Alt-tabbing to another window and back to Opus would make the dialog appear if it was not visible, but didn't affect the CPU usage. Turning off the tree lock or changing toolbar layouts would immediately stop both issues until the old state was restored.)

Here's a test version which includes a fix (as well as everything in the current 12.24.3 beta):

https://leo.dopus.com/temp/DOpusInstall_12.24.3_treelock_toolbar_fix.exe

(Edit: I've modified the thread subject so it might help anyone else with the same problem.)

[Heraes]

Awesome ! I'm proud we finally found the origin of the problem.
We keep in touch in this topic is for any reason I find anything else in the next days (I'm actually testing to reconfigure everything almost as exactly as before).