Folder Tree and Libraries views displaying incorrect icons

Opus has taken to displaying randomly-selected filetype and application icons in the Folder Tree and Libraries views, in place of some of the normal drive/folder/etc icons.

In this case, the icons for 'Favorites', 'Alex', 'Libraries' and 'C:' are most definitely not supposed to look like that :slight_smile:

It doesn't do it immediately - at the point when the above image was taken, Opus had been running for several hours, although I don't know exactly when today it decided to change the icons.

A restart of Opus clears the problem, at least for a while. File Explorer is not affected as far as I can tell, so this doesn't look like a Windows issue. The contents of folders are also normal, with files and subfolders displaying the expected icons; similarly the 'This PC' view shows the correct icon for 'C:'.

I'm running 12.20 x64 build 7394 on a Windows 10 Home system, fully patched as of today.

Most likely is a Windows issue, as the icons come from Windows. Icons can go wrong in one process but not another sometimes.

Try clearing the Windows icon cache:

Thanks, I'll give that a go :slight_smile:

Ok, it resolved the problem, but only briefly. Repeated clearing of the cache does not help - the problem reappears immediately. I've tried several times over the past month, without success.

The issue is limited to just a few items, too - 'Favourites', the contents of 'Desktop', the contents of 'Libraries' and - occasionally - the contents of 'This PC'. It's never been observed in any application other than Opus.

The icons being displayed are taken from the set of programs I have pinned to the Windows Task Bar. No icon appears to be getting used more than once, which may explain why the problem doesn't affect all icons in the folder-tree - I don't have that many things pinned :slight_smile:

Are you using any tools that change the standard icons, or anything like that?

Not that I'm aware of. There are a few shell extensions installed which add overlays - tortoisesvn and tortoisegit - but they wouldn't affect this type of icon.

I updated Opus to the new release earlier this morning; after it restarted the icons were back to normal. I'll post here if they break again today :slight_smile:

Yeah, broke again. It survived for quite a while before going this time, but as before the Favourites, Desktop and C: are showing icons from my Taskbar.

Opus simply asks Windows for the icon IDs, which point into a cache that Windows updates. For them to become wrong like this suggests something is corrupting the icon cache. Maybe a Windows or shell extension issue.

We don't have any similar reports, so i would look at what's installed on your machine for possible causes.

Yes, I'll be doing some digging :slight_smile:

Can you tell me what prompts Opus to re-request the icons from Windows? As noted previously this problem only happens after some time has elapsed: I have never seen the wrong icons appear as soon as Opus starts.

Similarly, the issue only affects the folder-tree so presumably you never re-request the icons for the display panes?

They should be re-requested if the folders change, as well as when a folder is read.

It you close the window and open a new one, do you then see different icons for the same drive/folder in the folder tree vs the file display?

That would be very strange, since Opus would have requested the icons for both when the window opened. (There's no shared cache between windows, other than the one used by the Windows API itself.)

If I open a new window, it displays all icons correctly - at least initially. If it's left open long enough it may eventually exhibit the error.

The problem never shows up in the file display, only the folder tree. So I can see the correct icon for, say, 'C:' in the file display and a randomly-selected icon for it in the folder tree. Right now, for example, I have a lister open which is showing the contents of 'This PC' in the file display. All the icons are correct, but should the problem occur only the icons in the folder tree will change - those in the file display will remain as they are.

In terms of the re-request, so far as I recall I haven't actually touched Opus inbetween noting that it was displaying the correct icons and discovering that it wasn't. I may be wrong, however, so I will pay more attention to what I was doing the next time this happens and report back :slight_smile:

It probably wouldn't be triggered by something done in Opus. It'd happen if the shell e.g. sent a message to Opus saying the drive icons had potentially changed.

The fact the Favorites icon is changing in the tree as well is very strange, though. That seems more likely to be the (per-process) system icon cache getting corrupted in some way.

That can happen if you load a huge number of icons, since the system icon cache eventually runs out of slots and starts replacing old icons with new ones. If you're doing something that causes a huge number of unique icons to be loaded, then that could explain what's happening. The old IDs for old icons would turn into new icons, and Opus has no way to know it has happened.

(If that's what's happening, the file display continuing to show the new icons would be because it had requested the IDs from the system more recently than the tree, and the system must've loaded new copies of the icons into a new slot in the cache. The tree is still using the old, now incorrect slot, but the file display is using the new one.)

A button or hotkey which runs this command could be used to force the tree to re-get all its icons in that situation:

Go REBUILDTREE=both

(That would fix both trees in the current window, but not other windows. A script could do it to all windows at once, if needed.)

Increasing the icon cache size may be worth a try. It has to be done by editing the registry:

Note that, somewhat unusual for this kind of thing, the value has to be a String (REG_SZ) not a Number (REG_DWORD).

Microsoft also have some slightly different instructions for doing the same thing. I am not sure if the extra steps are necessary or not:

https://support.microsoft.com/en-us/help/2396571/icons-are-changed-unexpectedly-in-windows

That Microsoft KB article is also about fixing an issue very similar to the one you're seeing, which supports the theory that it's what is going wrong.

Of course, you should not normally need to do this, so it may also be worth working out what is causing so many icons to be loaded that the cache runs out of slots, and avoiding whatever it is. (You could also try doing it in Explorer to verify that the same thing then happens to icons in it.)

Ok, so, somewhere during a period of several hours this evening during which I did not touch the computer at all, the folder tree icons have done it again.

New this time: for the first time it's replaced icons of regular folders; it's also replaced icons of zipfiles displayed in the tree (interestingly, all the zipfiles got the same icon, whereas each folder is different - and not all folders were replaced, only some); and not all the icons are those of programs pinned to the taskbar - some are other applications and some look like filetype icons.

As before it's only the trees that are affected, the file displays are fine.

I've checked the registry setting - I had it set to 4096, and I've upped it to 8192, but that hasn't made any difference.

I do have a lot of files which get thumbnailed, but I have not actually viewed any of them today so they would not have been loaded into a memory cache in this session.

(Probably not surprising: the lister is a dual view, each side has a folder tree and both are getting updated in an identical fashion with the changed icons.)

More weirdness.

I'm just back in from a trip to the supermarket; when I left, all icons were normal, when I returned some of them had changed.

I've run the 'rebuildtree' command as above, which refreshed the icons back to normal. Then I expanded 'Libraries' - and found that all the icons under that were still wrong. So I ran 'rebuildtree' again - and nothing changed.

And this time, the icons displayed in the file display for the contents of 'Libraries' match the incorrect icons in the folder tree, so for the first time the problem has shown up in both panes.

Are Opus windows left open when this happens?

Have you tried leaving Explorer windows open, showing the same folders in the file display and expanded in the folder tree?

For it to happen by itself suggests some event which is causing unique icons to be refreshed repeatedly until the icon cache runs out of slots and wraps around. My guess then would be a third party (non-Windows) network drive (or cloud storage maybe) which is generating change events constantly/incorrectly, and somehow triggering its icons to be refreshed to a new icon every time. That's a pure guess, though.

Whatever it is seems unique to your system, as we haven't had any similar reports.

Yes, I have Opus running constantly with a dual lister open.

I don't run Explorer, so I don't know if the problem shows up at the same time (or at all) in there. I'll keep a window open for the rest of the day and see what happens.

I have three SMB shares connected; two of these are from Windows machines and the other is a FreeNAS box using samba. All have been part of my network for years, and none has had a recent change or update that I'm aware of.

Still not seen it happen in Explorer, although I'm still testing.

What I have found, though, is that the 'rebuildtree' command fails to sort out the icons inside 'Libraries'. Only a restart of Opus gets those back to normal.

Ok, it just happened again in Opus. I had an Explorer window open at the time, displaying the same tree, and it was not affected at all.