Hello, just updated to v13.24 and now all my .exe icons are generic in Dopus but still ok in Explorer. I have checked the Icon setttngs and it is not set to generic. I have tried reboots, clearing cache, etc. No Joy, so now stumped, suggestions welcome!
In Opus, if you right-click one of the exes and choose Properties, does the correct icon appear in the Properties dialog or is it also wrong there?
That may mean something is blocking Opus from reading the files (since the Properties dialog itself is part of Windows, but affected by which process it's inside of).
I would look at antivirus and similar to see if it's restricting what Opus can do vs other processes. (Also worth checking if things like the File Open dialogs in other non-Microsoft programs are similarly affected, as another data point.)
I only use standard Windows 11 Defender and always have done. Something has changed - the only changes I know of are Windows Updates and Dopus updates.
Will check if I have other programs with fill open dialogues - pretty sure these are ok.
Very weird, things like DLL and CPL files show their embedded icons fine.
Defender is one of the worst antivirus in terms of causing problems for software, as well as not informing the user when it blocks operations and makes things look broken. I would not discount its involvement.
Try whitelisting Opus to see if it has an effect.
So I have tried a few things, none of which have worked. I have used UltraEdit, Paint.NET and a few other non microsoft apps and they all show the .exe icon and properties correctly. No other program I have tried shows generic icons for .exe files. I have tried launching Dopus.exe as admin after killing it in task manager, no change, tried launching it from shortcuts in the menu, the desktop and from within terminal, again no change. Also whitelisted (added exception) for dopus.exe in Defender, also no change. At this point I am dumbfounded/stumped/annoyed... have no clue what to do next...
Thanks for trying those things, and sorry they weren't the answer.
Something worth a try is disabling some of our internal hooks, to determine if they are involved or not.
This needs to be done via a registry setting, and then Opus needs to be exited (File > Exit Directory Opus) and restarted.
This zip has a .reg file which sets the value when double-clicked, and another which resets/clears it to return to normal after testing.
- NoShellHook.zip (640 Bytes)
Or, if you're comfortable using RegEdit and prefer to make the change by hand:
- Go to
HKEY_CURRENT_USER\Software\GPSoftware\Directory Opus(create it if needed) - Make a DWORD value named
NoShellHookand set to1 - When finished testing, delete the value.
Let us know if that gets the icons back, and we can work out which direction to look in from there. Thanks!
Hi Leo, tried the reg files and set the NoShellHook to 1 (merge the reg file) and restarted Dopus, but this did not have any effect. I also tried restarting with it set just in case but no joy.
Thanks for trying that, and sorry it didn't work again.
Something to test to see if Opus can read the contents of the exe files at all:
- Select an exe whose icon isn't showing up.
- Choose Edit > Calculate MD5 Checksums
That should turn on the MD5 column and show a value for the chosen file. (If the file is large, it might show a progress dialog first.)
Does that work, or is it also failing?
A second thing: When you cleared the shell icon cache, which method did you use? FWIW I wrote a tool a while ago which automates the task and also restarts Opus and File Explorer for you, which may be worth a try: Clear Icon Cache
Just tried the MD5 option and it calculates fine!
This is the script I use to clear the icon caches:
param([switch]$Elevated)
function Test-Admin {
$currentUser = New-Object Security.Principal.WindowsPrincipal $([Security.Principal.WindowsIdentity]::GetCurrent())
$currentUser.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
}
if ((Test-Admin) -eq $false) {
if ($elevated) {
# tried to elevate, did not work, aborting
} else {
Start-Process powershell.exe -Verb RunAs -ArgumentList ('-noprofile -noexit -file "{0}" -elevated' -f ($myinvocation.MyCommand.Definition))
}
exit
}
taskkill /IM explorer.exe /F
Start-Sleep -Seconds 1.0
taskkill /IM dopus.exe /F
Start-Sleep -Seconds 1.0
Get-ChildItem -Path C:\Users\Geoff\AppData\Local\Microsoft\Windows\Explorer -Filter "iconcache*" | Remove-Item
Start-Sleep -Seconds 1.0
start explorer.exe
Start-Sleep -Seconds 1.0
start explorer.exe "C:\Program Files\GPSoftware\Directory Opus\dopus.exe"
Start-Sleep -Seconds 1.0
I wll try yours!
Tried your ClearIconCache.exe and it runs fine but does not help unfortunately...
Process Monitor logs might reveal something blocking the files being opened, perhaps. Other than that, I am out of ideas.
That it affects the Properties dialogs as well implies something is interfering with the dopus.exe process on some level.
Checking with an older version may also be worth a try. If it worked previously but no longer does, even on older versions that worked before, then that would mean something else has changed on the system, for example.
So I have now tried the following:
(1) An old version of Dopus (13.10) - made no difference
(2) Removed latest Windows Updates (KB5094126) and left old Dopus in place - made no difference
(2) Went back to Dopus 13.24 - made no difference
(3) Went back to an image of a month ago - made no difference
(4) Restored everything to the same situation as I started from - made no difference
So I am stumped right now! The thing is I can't really identify when this started, nor what could have changed (not much has changed on my system really)...
When I get some time I will take some Process Monitor Logs....
It might be an icon (or icon overlay) handler going wrong, which would explain why it's affecting old versions.
If you want to test that theory:
- Go to Preferences / Miscellaneous / Shell Extensions
- Select everything in the Icon category and block it.
- Do the same for the Icon Overlay category.
- Click OK and restart Opus.
If the icons work again, re-enable a few at a time to narrow the problem down to a particular extension. (There's usually only a handful of those types of shell extension.)
If it doesn't make a difference, re-enable them all to avoid breaking icons/overlays that depend on them.
Just tried both of those - sounded good but made no difference....
Looking at the ProcMon logs you just sent, the only thing that stands out to me is a lot of calls to QueryRemoteProtocolInformation which fail with invalid parameter.
When I do the same thing on my system, QueryRemoteProtocolInformation is not called at all, so that's definitely a difference (although it is inconclusive).
I've never heard of that API before now, and it's not something Opus calls but rather something Windows is calling.
It seems most related to custom filesystems or cloud storage that uses them (e.g. FUSE, Dropbox). Is anything like that involved in the C drive?
From the stack traces, it also looks like it's part of a filesystem filter, which is something that could be used by custom filesystems, cloud storage or antivirus or similar security software.
The only cloud storage I use is OneDrive business and the local store for that is on the D drive. I copied an exe file to OneDrive and it shows the generic icon with the tick mark to show it is synced. When I do the same in Explorer both show the correct icon. I am totally stumped now. No clue what is happening and why!
My user account is an AzureAD account and I run Windows 11 Enterprise from a Microsoft 365 subscription, I am on version 25H2 OS build 26200.8655. Probably irrelevant.
So I have tried everything I can think of - this only happens with Dopus and no other application, that is weird. However, a clue, if I change the .exe defaulticon in Windows from %1 explorer ignores this setting (it used to honour it), so something has changed in Windows. Dopus also does not recognise the icon change (after rebuilding the cache each time.
This suggests that Windows handles the icon choice in a different way...
PROBLEM SOLVED!!
Under the registry key HKEY_CLASSES_ROOT\exefile\shellex
I had an IconHandler key with the entry {3A6B53B8-3C5D-4c60-D4E8-12B4F433BC87}
This does/did not interfere with Explorer (or any other file or save open dialogue) but does interfere with Dopus. I deleted the key and everything works fine now - I found out about this from the learn.microsoft.com website as someone had a similar issue with another third party "explorer like" tool.
Thing is that I searched the whole registry for the 3A6B53B8-3C5D-4c60-D4E8-12B4F433BC87 entries and no other entries were found.
This "change" happened some months ago, so I assume that this key must have been added by something, no clue what, but removing it worked!!
Phew, I can now relax!!
Thanks for all you help Leo, so much appreciated.
Not sure why this key affected Dopus and not Explorer but I am so pleased we have solved it. Hope is someone else comes across a similar issue they might know where to look!
Geoff.