Slow folder changes (PDF-XChange shell extension)

Tried both. No luck. Disabled antivirus, disabled all file and folder icons. Disabled secondary sort and additional columns. No improvement.

Keeping the config backup made earlier, please try uninstalling Opus (this will delete any existing config), reboot if prompted, then reinstall Opus.

Using the default config, does the problem still happen then?

(After testing, you can restore the config backup, of course.)

It worked-- sped things up. When I restored my config, it slowed down again, but I am not sure what about the config is making it slow.

I tried going through my config and disabling just about everything, but nothing helped.

Which columns are displayed in the file display? (Assuming it's in details or power mode.) They could be a factor.

Name, size, modified, attr. If I just use name, it doesn't seem to help.

If you want, attach the config backup via private message and I'll see if I can find a possible cause.

Thanks for sending the config!

I loaded it into a test machine and changing folders is completely instant, so it must be a combination of the config and the machine/environment.

My bet is that something is pointing to a device or network drive which is very slow or inaccessible.

Something thing to try, along those lines, is clearing the recent list and favorites:

  • For the Recent list, right-click the path field and choose Clear History.

  • For Favorites, go to Preferences / Favorites and Recent / Favorites List and right-click the root node for an option to clear the whole list.


Of course, make sure you still have your config backup, or make a new one, so you can restore the list afterwards.

Those are the only things that stand out to me.

(There's also the folder-change script, but it's disabled and so shouldn't do anything. And the other script should only do anything when a new window opens, so that can be ignored.)

If clearing the favorites list is what fixes things, it's probably going to be an entry in the list that's pointing to something that is no longer (or not always) there, and which takes Windows a long time to give up looking for. (Inaccessible network drives can do that.)

It could also be tied to the Jump List settings, which are configured to add all the favorites to the jump list. I'm not sure if jump list would be reevaluated on every folder change (at least with the other settings in play) but it could be involved. But maybe you already tried turning all of that off. (Windows will only show a maximum of about 10 items on the jump list anyway, although it doesn't provide a way for us to know when we add items.)

If you still see the problem, it might be worth creating a Process Monitor log of what happens when changing folders. That should reveal what is being accessed, assuming it is triggering some kind of filesystem activity. It may also reveal which part of Opus, or potentially a 3rd party shell extension, is causing the access/delay.

Thanks for the help. Clearing history, favorites, & jump did not help. I more or less gave up after that. I will keep an eye out to see if I identify anything else.

Try the Process Monitor log if you want. I'm happy to look through it.

Maybe it's caused by a shell extension plugin?

Thanks. I had tried disabling all plugins.

Based on the log, try using ShellExView* to disable any instances of C:\Program Files\Tracker Software\Shell Extensions\XCShInfo.x64.dll, then reboot. Does the problem still happen then?

Loading that DLL is blocking Opus for about 2.5 seconds after the folder is read, for an operation that should take a tiny fraction of a second.

*The link you want on the ShellExView page is "Download ShellExView for x64". Extract it to wherever is convenient, then run the exe and sort the list of extensions by name to find all the entries related to XCShInfo.x64.dll

Setting Preferences / Miscellaneous / Advanced [Compatibility]: flush_com_libraries = False may also reduce the frequency that the delay is triggered, by allowing their DLL to remain loaded for longer, but would not fix things entirely. Their DLL is taking a ridiculous amount of time just to load each time it is called. (Whether it is actually a fault in their DLL, or something else, I can't say. Updating or reinstalling the related software may repair things.)


Fixed! I actually just uninstalled the Tracker Software. Thanks for a big success!



I was just about to report long folder load times and to ask for solutions.

That's when I found this thread. I disabled XCShInfo.x64.dll, restarted Dopus and it seems that the delays are gone. Somewhat unfortunately, this also disabled PDF thumbnails for me.

I shall monitor this and report the issue to Tracker Software, if applicable.

Thanks and best regards,
also to AutoHotkey guru Mikey.


1 Like

The bug is still known for longer time and already reported to Tracker Software. They are actually working on a fix, but it seems it will take a while.

What I have found out is, that the shell extension slows down after first access after reboot (up to 5 seconds here e.g. on right click on a PDF or when opening DO) and then it's normally fast again.

Unfortunately I still see severe delays when viewing certain folders.

The problem is also independent of enabling or disabling the various handlers of PDF-XChange:

For example, it takes several seconds for the folder shown below to be listed, every time it is displayed. Other folders with fewer or even many more items on the other hand appear without delay in a fraction of a second.

If such folders with delayed display are moved or copied somewhere else, then sometimes the delay disappears completely.

It is also not due to the enabled folder size calculation, since many folders appear instantaneously, which also have numerous subfolders of various sizes.

These are the only shell extensions I still have enabled at all:

Please let me know what else could be the reason for this issue.

You have PDF-XChange installed and parts of it enabled in your screenshots. Try completely uninstalling it and rebooting. If you no longer see the problem, then it's related to PDF-XChange and you should chase them up about it. OTOH, if you still see the problem, please start a new thread with details.

OK will do

So I have now uninstalled PDF-XChange Editor and even removed all possible traces using Martau Total Uninstall in several different ways.


I still see delays of 3 to 5 seconds when opening certain folders. The delays also occur when opening the same folder again within, say, the same minute. After opening the same folder several times, the delay disappears for a while, but then comes back again.

I have opened a new thread here.

PS: Solved! Issue was was due to