Win10 Pro File Explorer - frequent crashing!
Greetings all,
Since about 3-4 weeks ago, I have been encountering frequent File Explorer crashes, whenever performing normal copy, move, and/or rename file operations. For instance, 100% of the time, if I am moving files (a mix of documents, PDFs, zip files, etc.) from drive D: (internal SATA drive) to drive R: (an external eSATA RAID), it will crash some time after 2 GB (1000 files) have moved.
The error log is the same, every time.
Observations
Apparently the crashes only occur when drive D: is involved; whether it involved moving, renaming, or just navigating folders. I seem to be able to do any number of file operations on other drives without encountering a crash. I not 100% on this theory because D: is my primary working drive. Most certainly, crashes are far more frequent on drive D:
What I have tried
(none helped)
- File Explorer > View > Options > Change Folder and search options > Privacy >Clear File Explorer History
- Turned off thumbnails
- Uninstall Open-Shell (version 4.4.138) (I dearly miss this plug-in - thank goodness it wasn't the cause).
- Drive scan and repair - no faults found
- Comprehensive virus scan
- Ccleaner Pro comprehensive clean up
Finally, I attempted (and failed) to re-register ntdll.dll, as per someone's suggestion. The error: "The module "ntdll" was loaded but the entry-point DLLUnregisterServer was not found."
More details
- Windows 10 Pro (latest updates)
- Drive D used to have software-based file compression! I do not recommend this! Never ever use it because it will slow your computer and file operations!
I mention this because there are still many files that remain compressed. I only turned off-compression at the folder level (to stop any future auto-compression) because uncompressing individual files would require many days.
However, it's important to add that the file compression existed long before the File Explorer crashing began.
- I have an Intel Core i7 and 32 GB of memory. Drive D: has about 1 TB of free space (out of 3 TB).
- No unusual software installs occurred in the past 4 weeks. Maybe a Windows update?
Since about 3-4 weeks ago, I have been encountering frequent File Explorer crashes, whenever performing normal copy, move, and/or rename file operations. For instance, 100% of the time, if I am moving files (a mix of documents, PDFs, zip files, etc.) from drive D: (internal SATA drive) to drive R: (an external eSATA RAID), it will crash some time after 2 GB (1000 files) have moved.
The error log is the same, every time.
Faulting application name: explorer.exe, version: 10.0.18362.449, time stamp: 0xd3046e6b
Faulting module name: ntdll.dll, version: 10.0.18362.418, time stamp: 0x99ca0526
Exception code: 0xc0000374
Fault offset: 0x00000000000f9269
Faulting process id: 0x2cc28
Faulting application start time: 0x01d5bea86d27cbea
Faulting application path: C:\WINDOWS\explorer.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: 1d00ccbf-f927-49b7-8c48-4d1fffc16dea
Faulting package full name:
Faulting package-relative application ID:Observations
Apparently the crashes only occur when drive D: is involved; whether it involved moving, renaming, or just navigating folders. I seem to be able to do any number of file operations on other drives without encountering a crash. I not 100% on this theory because D: is my primary working drive. Most certainly, crashes are far more frequent on drive D:
What I have tried
(none helped)
- File Explorer > View > Options > Change Folder and search options > Privacy >Clear File Explorer History
- Turned off thumbnails
- Uninstall Open-Shell (version 4.4.138) (I dearly miss this plug-in - thank goodness it wasn't the cause).
- Drive scan and repair - no faults found
- Comprehensive virus scan
- Ccleaner Pro comprehensive clean up
Finally, I attempted (and failed) to re-register ntdll.dll, as per someone's suggestion. The error: "The module "ntdll" was loaded but the entry-point DLLUnregisterServer was not found."
More details
- Windows 10 Pro (latest updates)
- Drive D used to have software-based file compression! I do not recommend this! Never ever use it because it will slow your computer and file operations!
I mention this because there are still many files that remain compressed. I only turned off-compression at the folder level (to stop any future auto-compression) because uncompressing individual files would require many days.
However, it's important to add that the file compression existed long before the File Explorer crashing began.
- I have an Intel Core i7 and 32 GB of memory. Drive D: has about 1 TB of free space (out of 3 TB).
- No unusual software installs occurred in the past 4 weeks. Maybe a Windows update?
Jackie Man
When did you chkdsk for D drive last time?
or run a disk diag on D: drive - you can post the exact model if you want more help
i Always Ensure the disk is working properly - before running diskchk, because that tends to make things more complex for recovery
i Always Ensure the disk is working properly - before running diskchk, because that tends to make things more complex for recovery
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi Shawn,
A troubleshooting idea (in the "process of elimination" category) is to see if another file manager can perform the copy/move/rename operations successfully. Since you say that the problem with File Explorer is 100% reproducible, this will be easy to test. I suggest trying Total Commander, available here:
http://www.ghisler.com
It is an excellent file manager. I've been using it for more than 20 years (rather than Windows/File Explorer). It is a shareware product...you can download and try the fully functional version at no cost (and if you decide to buy it, it is reasonably priced, but, of course, no need to buy it for this troubleshooting test).
As a disclaimer, I want to emphasize that I have no affiliation with this company and no financial interest in it whatsoever. I am simply a happy user/customer. Regards, Joe
A troubleshooting idea (in the "process of elimination" category) is to see if another file manager can perform the copy/move/rename operations successfully. Since you say that the problem with File Explorer is 100% reproducible, this will be easy to test. I suggest trying Total Commander, available here:
http://www.ghisler.com
It is an excellent file manager. I've been using it for more than 20 years (rather than Windows/File Explorer). It is a shareware product...you can download and try the fully functional version at no cost (and if you decide to buy it, it is reasonably priced, but, of course, no need to buy it for this troubleshooting test).
As a disclaimer, I want to emphasize that I have no affiliation with this company and no financial interest in it whatsoever. I am simply a happy user/customer. Regards, Joe
ASKER
Greetings all. Thank you for the tremendous support!
Jackie Man, nobus >
All other tests indicated that there were no physical problems with the hard drive... so I avoided doing a slow chkdsk. However, since you ask, I ran it. It took about 14 hours to complete, and found no errors in any of the 5 stages. I am quite confident that this isn't a hardware issue. However, two puzzles remain:
1) Why did this start happening, within the past 4 weeks?
2) Why does File Explorer appear to crash only when doing file operations on this drive (D:)?
Adam Leinss >
I haven't looked at ShellExView yet. Thank you. I'll check this out tonight.
Joe Winograd >
I downloaded a trial of Total Commander. I was able to move over a 1TB/9000+ files off of drive D: without a crash. That would not have been possible with Windows File Explorer. Thanks for the suggestion.
I don't really like Total Commander because of it's rather dated UI, and most specifically because some operations take longer (more steps) to complete. If I can make it behave like File Explorer (e.g. mouse right-click > properties/extract/open with/etc operations), I might learn to appreciate it.
So, even though I was able to successfully move content off (D:) using Total Commander, I still have a perplexing problem to solve.
Thanks everyone. Even though the problem still exists, I really appreciate your help. :)
Jackie Man, nobus >
All other tests indicated that there were no physical problems with the hard drive... so I avoided doing a slow chkdsk. However, since you ask, I ran it. It took about 14 hours to complete, and found no errors in any of the 5 stages. I am quite confident that this isn't a hardware issue. However, two puzzles remain:
1) Why did this start happening, within the past 4 weeks?
2) Why does File Explorer appear to crash only when doing file operations on this drive (D:)?
Adam Leinss >
I haven't looked at ShellExView yet. Thank you. I'll check this out tonight.
Joe Winograd >
I downloaded a trial of Total Commander. I was able to move over a 1TB/9000+ files off of drive D: without a crash. That would not have been possible with Windows File Explorer. Thanks for the suggestion.
I don't really like Total Commander because of it's rather dated UI, and most specifically because some operations take longer (more steps) to complete. If I can make it behave like File Explorer (e.g. mouse right-click > properties/extract/open with/etc operations), I might learn to appreciate it.
So, even though I was able to successfully move content off (D:) using Total Commander, I still have a perplexing problem to solve.
Thanks everyone. Even though the problem still exists, I really appreciate your help. :)
Hi Shawn,
> I was able to move over a 1TB/9000+ files off of drive D: without a crash. That would not have been possible with Windows File Explorer.
Pretty much proves that the problem is with File Explorer, not the drive.
> I don't really like Total Commander because of it's rather dated UI
To each his own. I hate the Windows/File Explorer UI and much prefer TC's two-pane UI. I love the convenience of left-to-right and right-to-left file copying within the same TC window (and I don't much like drag-and-drop or cut/copy/paste for file operations).
> most specifically because some operations take longer (more steps) to complete
I find that most file operations take fewer steps with TC.
> If I can make it behave like File Explorer (e.g. mouse right-click > properties/extract/open with/etc operations), I might learn to appreciate it.
I think that a right-click in TC exposes the same context menu that Windows/File Explorer does. I just did a right-click on a JPG file in both...I don't see anything in the Windows Explorer (it's a W7 system) context menu that isn't in the TC context menu.
All of that said, my purpose wasn't to "sell" you on TC...it was to try to show whether the problem was with the file manager or the disk drive...I think this troubleshooting test shows that it is the former...and I have no clue how to fix File Explorer problems, other than the usual suggestion of SFC /scannnow and DISM, which, in my experience, rarely help. Regards, Joe
> I was able to move over a 1TB/9000+ files off of drive D: without a crash. That would not have been possible with Windows File Explorer.
Pretty much proves that the problem is with File Explorer, not the drive.
> I don't really like Total Commander because of it's rather dated UI
To each his own. I hate the Windows/File Explorer UI and much prefer TC's two-pane UI. I love the convenience of left-to-right and right-to-left file copying within the same TC window (and I don't much like drag-and-drop or cut/copy/paste for file operations).
> most specifically because some operations take longer (more steps) to complete
I find that most file operations take fewer steps with TC.
> If I can make it behave like File Explorer (e.g. mouse right-click > properties/extract/open with/etc operations), I might learn to appreciate it.
I think that a right-click in TC exposes the same context menu that Windows/File Explorer does. I just did a right-click on a JPG file in both...I don't see anything in the Windows Explorer (it's a W7 system) context menu that isn't in the TC context menu.
All of that said, my purpose wasn't to "sell" you on TC...it was to try to show whether the problem was with the file manager or the disk drive...I think this troubleshooting test shows that it is the former...and I have no clue how to fix File Explorer problems, other than the usual suggestion of SFC /scannnow and DISM, which, in my experience, rarely help. Regards, Joe
ASKER
>Joe Winograd
Please understand that I really appreciate your TC recommendation. My grumblings are probably more from the POV of ignorance of operation and lack of familiarity, rather than a qualified opinion. LOL
I'll give TC more time before I give up.
:)
Please understand that I really appreciate your TC recommendation. My grumblings are probably more from the POV of ignorance of operation and lack of familiarity, rather than a qualified opinion. LOL
I'll give TC more time before I give up.
:)
Shawn,
Another highly regarded file manager is Directory Opus (aka DOpus):
https://www.gpsoft.com.au/
Give that a spin, too (has a free 60-day evaluation). It gets rave reviews and may (or may not) be more to your liking than TC. Regards, Joe
Another highly regarded file manager is Directory Opus (aka DOpus):
https://www.gpsoft.com.au/
Give that a spin, too (has a free 60-day evaluation). It gets rave reviews and may (or may not) be more to your liking than TC. Regards, Joe
you posted : " It took about 14 hours to complete," what disk size is that?? the longest i had was about 1 hr
you can also post the drive model, and how exactly you have it connected : usb 2 or 3, with or without powersupply
you can also post the drive model, and how exactly you have it connected : usb 2 or 3, with or without powersupply
ASKER
nobus >
It's an internal 3TB SATA3 drive, model: Hitachi UltraStar 7K3000 HUA723030ALA640
This took about 14 hours to complete:
C:\WINDOWS\system32>chkdsk
The type of the file system is NTFS.
Volume label is Data.
Stage 1: Examining basic file system structure ...
2645760 file records processed.
File verification completed.
117630 large file records processed.
0 bad file records processed.
Stage 2: Examining file name linkage ...
5528 reparse records processed.
2731184 index entries processed.
Index verification completed.
0 unindexed files scanned.
0 unindexed files recovered to lost and found.
5528 reparse records processed.
Stage 3: Examining security descriptors ...
Security descriptor verification completed.
42713 data files processed.
CHKDSK is verifying Usn Journal...
38652592 USN bytes processed.
Usn Journal verification completed.
Stage 4: Looking for bad clusters in user file data ...
2645744 files processed.
File data verification completed.
Stage 5: Looking for bad, free clusters ...
54858597 free clusters processed.
Free space verification is complete.
Windows has scanned the file system and found no problems.
No further action is required.
2861458 MB total disk space.
2644231 MB in 530409 files.
160736 KB in 42714 indexes.
0 KB in bad sectors.
2845427 KB in use by the system.
65536 KB occupied by the log file.
219434388 KB available on disk.
4096 bytes in each allocation unit.
732533503 total allocation units on disk.
54858597 allocation units available on disk.
It's an internal 3TB SATA3 drive, model: Hitachi UltraStar 7K3000 HUA723030ALA640
This took about 14 hours to complete:
C:\WINDOWS\system32>chkdsk
The type of the file system is NTFS.
Volume label is Data.
Stage 1: Examining basic file system structure ...
2645760 file records processed.
File verification completed.
117630 large file records processed.
0 bad file records processed.
Stage 2: Examining file name linkage ...
5528 reparse records processed.
2731184 index entries processed.
Index verification completed.
0 unindexed files scanned.
0 unindexed files recovered to lost and found.
5528 reparse records processed.
Stage 3: Examining security descriptors ...
Security descriptor verification completed.
42713 data files processed.
CHKDSK is verifying Usn Journal...
38652592 USN bytes processed.
Usn Journal verification completed.
Stage 4: Looking for bad clusters in user file data ...
2645744 files processed.
File data verification completed.
Stage 5: Looking for bad, free clusters ...
54858597 free clusters processed.
Free space verification is complete.
Windows has scanned the file system and found no problems.
No further action is required.
2861458 MB total disk space.
2644231 MB in 530409 files.
160736 KB in 42714 indexes.
0 KB in bad sectors.
2845427 KB in use by the system.
65536 KB occupied by the log file.
219434388 KB available on disk.
4096 bytes in each allocation unit.
732533503 total allocation units on disk.
54858597 allocation units available on disk.
ASKER
Joe Winograd >
Thank you so much for your Directory Opus (aka DOpus) recommendation. I immediately loved it! In so many ways, it is vastly superior to Window's File Explorer!
Thank you so much for your Directory Opus (aka DOpus) recommendation. I immediately loved it! In so many ways, it is vastly superior to Window's File Explorer!
ASKER
> Adam Leinss
I finally installed ShellExView. Thanks for this very useful tool!
I have 356 extensions, but fortunately, I can sort them by date. I will start disabling extensions that updated around the time the crashes began.
Thanks again!
I finally installed ShellExView. Thanks for this very useful tool!
I have 356 extensions, but fortunately, I can sort them by date. I will start disabling extensions that updated around the time the crashes began.
Thanks again!
how is the drive connected to the <PC? to an usb 3 or usb 2 port ? ( latter = 10x slower than usb 3)
it should complete in less than 2 hours - so clearly something is not 100%
it should complete in less than 2 hours - so clearly something is not 100%
ASKER
> nobus
The hard drive is an internal drive on a SATA3 interface. Chkdsk ran for the expected amount of time considering that this 3 TB drive is about 85% full, with more than 500K files, in 50K folders.
The hard drive is an internal drive on a SATA3 interface. Chkdsk ran for the expected amount of time considering that this 3 TB drive is about 85% full, with more than 500K files, in 50K folders.
i have an external 3 TB drive and i guess it won't take 2 hrs; if you want me to test it , just say so -and i'll post exact results
ASKER
Nobus, if you're using the chkdsk /r option, the time required greatly depends on the number of files on the hard drive. As I mentioned, I have well over 500000 files on my drive, so I fully expected a 14 hour run (maybe a bit less, like 12 hours)... I didn't count. :P
try updating bios and all drivers then
ASKER
Thanks nobus.
My motherboard ASUS is on an automatic update schedule, using the EZ Update app.
:)
My motherboard ASUS is on an automatic update schedule, using the EZ Update app.
:)
ASKER
Thank you all for your help. The problem is solved! :)
Special thanks to:
Adam Leinss for suggesting ShellExView. This tool helped me by allowing me to quickly identify shell extensions that were updated around the time that File Explorer began crashing. Two were identified and disabled:
- Java Plug-In 2 SSV Helper
- 7-Zip Shell Extension
I suspect that the Java helper is the culprit, but I left both disabled.
Joe Winograd for suggesting Directory Opus (aka DOpus). It didn't help solve my problem, but this tool allowed me to continue working while I investigated the problem. It's a wonderful enhancement to File Explorer.
Incidentally, I found that I can still make File Explorer crash, but now, only in the specific condition where the path length exceeds 256 characters. But now that I know this, I can plan accordingly.
Thanks again to everyone!
Special thanks to:
Adam Leinss for suggesting ShellExView. This tool helped me by allowing me to quickly identify shell extensions that were updated around the time that File Explorer began crashing. Two were identified and disabled:
- Java Plug-In 2 SSV Helper
- 7-Zip Shell Extension
I suspect that the Java helper is the culprit, but I left both disabled.
Joe Winograd for suggesting Directory Opus (aka DOpus). It didn't help solve my problem, but this tool allowed me to continue working while I investigated the problem. It's a wonderful enhancement to File Explorer.
Incidentally, I found that I can still make File Explorer crash, but now, only in the specific condition where the path length exceeds 256 characters. But now that I know this, I can plan accordingly.
Thanks again to everyone!
Glad you got it working!