Slow local file open, registry ...\explorer\fileexts corrupted?

As I said, all the extensions I have tried (.txt, .jpg, .png, .zip, ...) manifest the same delay. That makes me suspect that the problem goes beyond .txt files.

Is there another way to revert the \FileExts\ tree besides importing one from another little changed computer or deleting the key first then importing?

webdove said:

As I said, all the extensions I have tried (.txt, .jpg, .png, .zip, ...) manifest the same delay. That makes me suspect that the problem goes beyond .txt files.

Is there another way to revert the \FileExts\ tree besides importing one from another little changed computer or deleting the key first then importing?

Yes, you have a good point.

Not sure of the answer to your second question. Another thought then is to take the bad tree and put it into the working test account (or maybe create another test account if you like) and see if the problem follows if you don't want to experiment in your main account until you narrow the problem down more.

ooo. I like that idea.

I transplanted the questionable \FileExts\ registry key to the working test1 profile and the slow open, openwith menu problem did not follow that key, so the problem is elsewhere.

I performed a clean boot on the problem account and the slow opening and openwith problem persists.

- - - Updated - - -

C:\WINDOWS\system32>chkdisk c: /scan
'chkdisk' is not recognized as an internal or external command,
operable program or batch file.

C:\WINDOWS\system32>chkdsk c: /scan
The type of the file system is NTFS.
Volume label is Clean10_C.

Stage 1: Examining basic file system structure ...
1265152 file records processed.
File verification completed.
Phase duration (File record verification): 6.74 seconds.
13891 large file records processed.
Phase duration (Orphan file record recovery): 0.00 milliseconds.
0 bad file records processed.
Phase duration (Bad file record checking): 0.16 milliseconds.

Stage 2: Examining file name linkage ...
14766 reparse records processed.
1658722 index entries processed.
Index verification completed.
Phase duration (Index verification): 21.52 seconds.
0 unindexed files scanned.
Phase duration (Orphan reconnection): 5.92 seconds.
0 unindexed files recovered to lost and found.
Phase duration (Orphan recovery to lost and found): 0.19 milliseconds.
14766 reparse records processed.
Phase duration (Reparse point and Object ID verification): 35.70 milliseconds.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
Phase duration (Security descriptor verification): 97.16 milliseconds.
196786 data files processed.
Phase duration (Data attribute verification): 0.91 milliseconds.
CHKDSK is verifying Usn Journal...
36922496 USN bytes processed.
Usn Journal verification completed.
Phase duration (USN journal verification): 96.35 milliseconds.

Windows has scanned the file system and found no problems.
No further action is required.

975370239 KB total disk space.
822088960 KB in 987832 files.
595492 KB in 196787 indexes.
0 KB in bad sectors.
1402267 KB in use by the system.
65536 KB occupied by the log file.
151283520 KB available on disk.

4096 bytes in each allocation unit.
243842559 total allocation units on disk.
37820880 allocation units available on disk.
Total duration: 34.43 seconds (34437 ms).

C:\WINDOWS\system32>

​

- - - Updated - - -

So non-microsoft services or startups are not the cause. The disk is not the cause. Something in the profile is triggering the problem. New profiles do not exhibit the problem. Disabling the ethernet stops the problem. It manifests both in opening various file types from explorer and hovering over the exlorer "open with" menu.

- - - Updated - - -

No user or system environment variable point to the network.



- - - Updated - - -

I also tried disabling all "windows explorer" related items in autoruns64 and that did not help.
Safe mode with networking does cure the problem.

- - - Updated - - -

Bedtime (Foundation episode 1 was excellent.)

webdove,
Thanks for the update.

Maybe this can be of use:
https://docs.microsoft.com/en-us/sys...nloads/procmon

start logging right before you try and open a file, then stop logging right after it opens and then analyze the log.

Comparing results with network enabled/disabled could be insightful too, so you might what to do the faster network disabled case first or try from your clean profile.

steve108 said:

webdove,Maybe this can be of use:https://docs.microsoft.com/en-us/sys...nloads/procmonstart logging right before you try and open a file, then stop logging right after it opens and then analyze the log.

Thanks for that tip. Problem solved.

a couple of weeks back I had cleared some numeric IP address credentials while chasing another problem. This included 192.168.0.7. Apparently one of these type of registry entries was triggering failed attempts to connect using that IP address.

Once I added the correct credentials for 192.168.0.7 the problem went away.

It surprises me that there were no events in the system log to point out the lack of correct credentials.

webdove,
Great!
Thanks for the update.