valinet
ExplorerPatcher breaks file refresh on Windows 11
It appears that ExplorerPatcher may have broken my file explorer. Although I have since uninstalled ExplorerPatcher, I am left with a very annoying bug in Windows 11, whereby file explorer is not automatically refreshing after any file operation such as rename, move, delete, etc. After every file operation I have to hit F5 for the change to be visible. From Googling, I have found that others have hit this same problem, and it seems to be linked to a combination of Windows 11 and ExplorerPatcher:
- https://www.reddit.com/r/Windows11/comments/r5lb02/folder_and_file_icons_not_updating_have_to_f5_to/
- https://www.elevenforum.com/t/file-explorer-and-copy-and-paste.23185/
Note that this second link mentions OneDrive (which I do use), so that is another possible culprit, however ExplorerPatcher seems more likely to me. What's more, I see this problem even in folders that are not linked to OneDrive.
Is it possible that my ExplorerPatcher installation made some change to Windows that caused this bug, and that uninstalling it did not undo that change?
Any input would be much appreciated, as I'd rather find a solution that does not require reinstalling Windows!
Note that it was a while ago that I installed (and subsequently uninstalled) ExplorerPatcher, so this may not necessarily be an issue with the most recent version.
You may need to repair your windows install. Please run the following in an elevated command prompt or elevated powershell:
chkdsk C:
If it tells you there are errors, then run this:
chkdsk C: /F
Reboot to run it on boot. Keep running that command until it reports no errors. Then run this to repair windows:
sfc /scannow
dism /online /cleanup-image /scanhealth
dism /online /cleanup-image /restorehealth
dism /online /cleanup-image /checkhealth
dism /online /cleanup-image /analyzecomponentstore
dism /online /cleanup-image /startcomponentcleanup
Then reboot your computer.
IIRC you can't run chkdsk with the /F flag on the OS drive unless you reboot into some sort of recovery mode. This should work though (/V so it gives a little more info, /perf so it uses more resources to run faster):
chkdsk C: /V /scan /perf
also I'm pretty sure sfc relies on the component store being valid, so it should be run after dism:
dism /online /cleanup-image /scanhealth
dism /online /cleanup-image /restorehealth
sfc /scannow
I don't think you need /checkhealth (reports whether the component store was flagged as corrupted), /analyzecomponentstore (checks how much junk and wasted space is in the component store) or /startcomponentcleanup (cleans up the component store), though that last one might be a good idea as a little cleanup can't hurt.
No, you can run this on the OS drive:
chkdsk C: /F
It will just prompt you to reboot and run it then because the volume is in use.
I finally got round to trying this, but it did not fix the problem. Here's the full output from running those commands:
------------------START-----------------------------------
PowerShell 7.4.5 PS C:> chkdsk C: The type of the file system is NTFS. Volume label is System.
WARNING! /F parameter not specified. Running CHKDSK in read-only mode.
Stage 1: Examining basic file system structure ... 1370880 file records processed. File verification completed. Phase duration (File record verification): 33.76 seconds. 24138 large file records processed. Phase duration (Orphan file record recovery): 11.86 milliseconds. 0 bad file records processed. Phase duration (Bad file record checking): 0.56 milliseconds.
Stage 2: Examining file name linkage ... 125064 reparse records processed. 1883208 index entries processed. Index verification completed. Phase duration (Index verification): 23.55 seconds. 0 unindexed files scanned. Phase duration (Orphan reconnection): 12.44 seconds. 0 unindexed files recovered to lost and found. Phase duration (Orphan recovery to lost and found): 0.70 milliseconds. 125064 reparse records processed. Phase duration (Reparse point and Object ID verification): 231.77 milliseconds.
Stage 3: Examining security descriptors ... Security descriptor verification completed. Phase duration (Security descriptor verification): 37.58 milliseconds. 256165 data files processed. Phase duration (Data attribute verification): 0.93 milliseconds. CHKDSK is verifying Usn Journal... 38656904 USN bytes processed. Usn Journal verification completed. Phase duration (USN journal verification): 114.60 milliseconds.
Windows has scanned the file system and found no problems. No further action is required.
494465023 KB total disk space. 374319648 KB in 1090470 files. 728876 KB in 256166 indexes. 0 KB in bad sectors. 1519275 KB in use by the system. 65536 KB occupied by the log file. 117897224 KB available on disk.
4096 bytes in each allocation unit.
123616255 total allocation units on disk. 29474306 allocation units available on disk. Total duration: 1.16 minutes (70170 ms). PS C:> sfc /scannow
Beginning system scan. This process will take some time.
Beginning verification phase of system scan. Verification 100% complete.
Windows Resource Protection found corrupt files and successfully repaired them. For online repairs, details are included in the CBS log file located at windir\Logs\CBS\CBS.log. For example C:\Windows\Logs\CBS\CBS.log. For offline repairs, details are included in the log file provided by the /OFFLOGFILE flag. PS C:> dism /online /cleanup-image /scanhealth
Deployment Image Servicing and Management tool Version: 10.0.22621.2792
Image Version: 10.0.22631.4169
[==========================100.0%==========================] No component store corruption detected. The operation completed successfully. PS C:> dism /online /cleanup-image /restorehealth
Deployment Image Servicing and Management tool Version: 10.0.22621.2792
Image Version: 10.0.22631.4169
[==========================100.0%==========================] The restore operation completed successfully. The operation completed successfully. PS C:> sfc /scannow
Beginning system scan. This process will take some time.
Beginning verification phase of system scan. Verification 100% complete.
Windows Resource Protection did not find any integrity violations. PS C:> dism /online /cleanup-image /checkhealth
Deployment Image Servicing and Management tool Version: 10.0.22621.2792
Image Version: 10.0.22631.4169
No component store corruption detected. The operation completed successfully. PS C:> dism /online /cleanup-image /analyzecomponentstore
Deployment Image Servicing and Management tool Version: 10.0.22621.2792
Image Version: 10.0.22631.4169
[===========================99.5%========================= ]
Component Store (WinSxS) information:
Windows Explorer Reported Size of Component Store : 12.80 GB
Actual Size of Component Store : 12.00 GB
Shared with Windows : 6.68 GB
Backups and Disabled Features : 4.77 GB
Cache and Temporary Data : 542.96 MB
Date of Last Cleanup : 2024-10-28 11:04:17
Number of Reclaimable Packages : 1 Component Store Cleanup Recommended : Yes
The operation completed successfully. PS C:> dism /online /cleanup-image /startcomponentcleanup
Deployment Image Servicing and Management tool Version: 10.0.22621.2792
Image Version: 10.0.22631.4169
[===== 10.0% ] [==========================100.0%==========================] The operation completed successfully. PS C:>
------------------END-----------------------------------
After all this, I restarted my machine, but still the problem persists. I moved (via drag and drop) a file from one folder to another, and the file appeared in both places. Only after hitting F5 on the source folder did it disappear from there.
Any other suggestions?
I've experienced this on windows vista, so I doubt it is caused by EP.
Before windows vista was released, file system changes use to be recognized immediately. But after windows vista, and in windows 7, file system changes would only be recognized after I clicked on the refresh button in file explorer.
yeah, here it is: https://superuser.com/questions/315853/file-explorer-doesnt-refresh-automatically-when-files-are-added-by-some-program
so this is not a bug with EP, but a long standing bug that started in windows vista due to changes made to the NTFS file system.
Windows 11 File Explorer auto refresh was working perfectly before the last update, 22621.4317.67.1 and to test it I've downgraded it to 22621.3880.66.6 and auto refresh is now working again so it seems (not 100% guarantee of course that it is EP). Tried a few fixes such as adding the following 2 keys in the Registry, however after restarting Windows Explorer it did not fix.
~HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Background\Refresh. In the right pane, double-click "Enabled" and set the value data to "1"~
~HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Background\Refresh. Look for a DWORD value named AlwaysRefresh. If it exists and is set to 0, double-click it and change the value to 1. If it doesn't exist, right-click in the empty space on the right pane, select New > DWORD (32-bit) Value, name it AlwaysRefresh, and set the value to 1~
Updated:
Found the Solution. While I'm not 100% sure that what caused the issue was or wasn't EP I think what really matters is the solution which is:
Delete all the files inside %AppData%\Microsoft\windows\recent\automaticdestinations Delete all the files inside %AppData%\Microsoft\windows\recent\customdestinations
Restart Explorer or Reboot the Computer
No, that is not the solution because that removes your history of recently opened files and directories.
Weird...it fixed for me after the previous ones didn't, including the link you post it...and honestly? That's what I need, which was the File Explorer Auto Refresh fixed... I don't care about recent opened files or directories since it will be rebuilt anyway...oh...and I guess that is the reason it's called recent, I guess. Here is the link with all the comments.
https://www.tenforums.com/general-support/131250-file-explorer-stopped-refreshing.html
Well I said this has been around since windows vista and is not caused by EP. I've experienced this on multiple windows versions since windows vista.
Maybe removing all the recent files and directories causes less work afterwards for when windows refreshes the file system, as it detects changes made to it. But that means it will come back as your recent files and directories is rebuilt.
And your link https://www.tenforums.com/general-support/131250-file-explorer-stopped-refreshing.html points to https://github.com/valinet/ExplorerPatcher/issues/url
Indeed, the bug it's been around since Vista and because it's a bug there is nothing I can do, so I need to rely on the Internet to find the best solution. After trying a LOT such as the two registry keys mentioned before, removing networks shares from Quick Access and many others, the only one that really worked is the removal of the automaticdestinations and customdestinations.
As for the link the issue seems to be I use the add link option so all you need to do is to copy the link as text but let me try again
https://www.tenforums.com/general-support/131250-file-explorer-stopped-refreshing.html
and the original solution link is from here
https://scootercomputers.wordpress.com/2018/12/23/how-to-fix-it-when-the-file-explorer-desktop-doesnt-automatically-refresh-in-windows-10-8-7/
Please close this then as this isn't something for EP to fix.
I can't because wasn't me that opened it.
OK I am closing this ticket.
It seems like the problem has mostly gone away for me, although I am not sure why/how.
Before the solution by @Galthariel was posted, I tried a purported solution that involved deleting the explorer entry from the registry. I do NOT recommend this - it caused me more problems that it solved. I managed to recover the situation. Then the original problem seemed to have gone away, but occasionally came back! It now seems to mostly have gone away, but occasionally rears its ugly head.
I don't really know what to make of this. The solution from @Galthariel is a non-starter for me, as my %AppData%\Microsoft\windows\recent\ folder is empty.
I am now just looking forward to the next time I do a clean OS install, to ensure I am working from a clean slate, but it may be some time before I get round to that.
Although I'm not entirely convinced that EP has not played a part in this, I am happy to close this on the basis of innocent until proven guilty 😊
Thank you all for all your help, and especially to @pyrates999 for warning me about that malware.