5

Any file I open on my [very fast] PC via File->Open is extremely slow to open, as of the past 3 weeks. This includes (but I'm sure is not limited to):

  • Windows Notepad
  • Notepad++
  • Visual Studio
  • Adobe Photoshop
  • MS Word

Strangely: If I open a file via double-click in file explorer, or open via "recent files list" in any app, it opens instantaneously. The slowness only occurs when doing File->Open from within any application.

Saves are very slow the first time also. Subsequent saves (within the same app session) are very fast.

It takes consistently about 7 seconds each to open any of these small files.

But as described in more detail below, after a file has been opened, then closed in the same session, it opens again instantly. And the slow save only happens on the first-time save, never on subsequent saves.

This problem may coincide with a few events, but may be completely unrelated:

  • the installation of a new M.2 SSD PCIe drive that is widely regarded as blazing fast. I cloned my slower SSD drive and made this new (faster) SSD drive my primary/boot/C drive. That was a few weeks ago. This morning I reverted back (temporarily) to my old SSD (after cloning) and it made no difference. The problem remains. (I even removed the new M.2 drive, booted to the old, and it made no difference.)
  • I upgraded windows 10 to the 2004 version.
  • I enabled Windows Subsystem for Linux (Ubuntu 20.04)

I have found similar posts, but always more understandable scenarios:

Here are a few comparisons and details:

  • Slow to open first time in same session. Slow to save, first save only. Slow saves even happen in Adobe Photoshop, but only on the first save.
  • Windows Defender firewall is running, but realtime protection is turned off, and I don't have any other AV running.
  • Within a given NPP session, if I close a file and then reopen it, it opens instantly. But if I close NPP, relaunch, then open the same file again - it takes 7 seconds. Similar in windows notepad and other text editors.
  • When I open an NPP file from the "recent files" list, any/all those open instantly. It's only when I open files from File->Open that the slowness occurs.
  • If I close NPP and re-launch it, any files that were open in the previous session re-open by default, and it's instantaneous - no delays. It's only when I manually open a file in a new session that the slowness occurs. This is bizarre: I can have 15 files open in NPP and close the app. Then when I relaunch NPP, all 15 files open instantly/automatically in 15 different tabs. But as soon as I do File -> Open and open a file that isn't already opened, it takes 7 seconds and it acts like the whole OS is hung and straining.
  • I uninstalled all my NPP plugins and restarted - still takes 7 seconds to open small text files.
  • I have rebooted my PC several times.
  • I ran chkdsk on the drive where the text files are, no bad sectors.
  • I ran procmon, got results, but don't know what I'm looking for amidst the thousands of entries.
  • I ran wpr - it begins a recording session successfully, but when I run it again with -stop + filename, I get the error cannot change thread mode after it is set.
  • I uninstalled NPP and re-installed it. For about 1 day this solved the problem and files opened instantly. Then the next day the original problem was back again.
  • I ran Optimize against all my drives as per Bob Denton's suggestion below - it made no difference.
  • I did a clean boot (disabled all non-MS services) - no change.
  • I switched the boot sequence to the original SSD drive, shut down, physically removed the brand new M.2 SSD, and booted back up. Same problem. No difference. So it has nothing to do with this new drive. The last culprit I can think of is the Windows 2004 update - nothing else major has changed in the past few months.

This is so annoying. Any ideas?

13
  • Have you run a chkdsk on the ssd lately?
    – Moab
    Aug 15, 2020 at 13:45
  • Process Monitor (Microsoft/Sysinernals) might offer something, so I would run that first while reproducing the problem. Otherwise, get an ETL trace. wpr.exe -start GeneralProfile reproduce, wpr.exe -stop C:\gp.etl. You can get Windows Performance Analyzer (WPA) from the Store to analyze it. Maybe provide a link to the etl zipped if you need help. Aug 15, 2020 at 19:42
  • Moab: I ran chkdsk, no bad sectors. HelpingHand: I ran procmon64 while opening the file - reproduced the slow open - but the procmon results have thousands of entries and I have no idea what I'm looking for. Aug 16, 2020 at 5:02
  • Next I ran wpr, and it started recording successfully. But when I ran the stop command with file save location, I get: Cannot change thread mode after it is set - and the recording keeps running, forcing me to finally run -cancel. What next? Aug 16, 2020 at 5:13
  • 1
    I've never had an issue running WPR, did you try a few times? Maybe reboot and try again, do you always get Cannot change thread mode after it is set? Very odd. I can take a look at the PML if you are able to zip and share it somehow? I would suggest include the system process and capture all events to the .pml file. Aug 16, 2020 at 13:04

6 Answers 6

2

According to my experience, Windows is quite good in reporting disk hardware errors. Hence, the first thing I would do is opening the event viewer, go to Windows Logs -> System and carefully scroll through through the event list at least a few days in the past, looking at each error. If there is a hardware problem with the disk where the files are located, chances are very good that they will be revealed there.

The second thing that might be worth a try is disabling the virus scanner (just for a short time for a test). I once had a similar problem where it turned out that Windows Defender itself was the problem. You make the impression of an advanced user, so for sure you don't have two or more virus scanners installed, do you?

The third thing I would try is moving a few of the (text) files in question onto your new SSD and to work with them from there. If the times needed for opening / saving are normal then, the old SSD is the problem.

When doing that test, you should remove all other HDDs and SSDs: As noted in one of the comments above, the Windows File Open Dialog might query all drives in the system, and that alone might delay things although you don't open files from one of the other drives.

In the device manager and in the energy management options, you can check whether your drives are always active or whether they are going to sleep. If the latter is the case, you could disable that behavior and test whether the situation changes.

Finally, there eventually is a virus on your system; extreme delays with normal actions would be a typical sign of it. But I actually don't believe this in your case, because (if I got you right) boot times are normal and opening the files is normal as well as soon as they are cached. However, just out of caution, I would boot from a clean read-only medium and check whether there is anything suspicious on the system.

UPDATE (as an answer to the OP's comment)

Your wrote in your comment below:

When I double-click any text file it opens instantly. But when opening it via an app it is very slow.

and

I moved some text files to my [supposedly fast] C drive and the time it takes to open is identical to my other drives.

Both statements support the theory that the standard Windows file open dialog (which applications nearly always use to let the user choose a file) has problems when querying the drives.

Therefore, I now recommend to remove all drives (including network drives and USB keys!) except the system drive from the system and re-test. Chances are very good that the problem goes away then. Then you can start re-adding the other drives one by one and identify which one is responsible for the misbehavior.

Of course, you should start with the network drives, because this doesn't require opening the PC. Regarding the network drives, it might not be enough to remove the drive letters for the shares; instead, remove the drive letters, deactivate the network hardware and pull the network cable. Then check whether your application has a non-local file (i.e. a file which is on the network) in its MRU (most recently used) list. If possible, delete the MRU. You need to be sure that the application does not try to search or preload something from the network when opening files from within that application.

If that does not help, proceed with removing the physical drives (USB keys, HDDs, SSDs).

6
  • Windows Defender has been disabled for a long time and I have no other virus scanner. No errors of consequence in the event log. I moved some text files to my [supposedly fast] C drive and the time it takes to open is identical to my other drives. Interesting: When I double-click any text file it opens instantly. But when opening it via an app it is very slow. Aug 22, 2020 at 19:12
  • @HerrimanCoder Two of the statements in your comment are quite important IMHO. Please see the update of my answer.
    – Binarus
    Aug 23, 2020 at 16:22
  • I tried cloning the new/fast SSD to my old/slower SSD (still inside the PC) and booting to the old one. Booted up fine. Problem remains - still crazy-slow to open even the smallest text files when opening from File->Open. But when I open from "recent files" list, always opens instantaneously. Just FYI - I haven't removed drives yet - will try that next. FYI: I have no mapped/network drives. All my drives are internal + 1 external storage drive that plugs into USB port. I'm not opening/saving files to/from that drive at all. Aug 23, 2020 at 20:39
  • This observation (opening from recent files is fast) perhaps also supports the theory that there is a problem with the standard Windows File Open Dialog. I am looking forward to your observations after having removed all drives.
    – Binarus
    Aug 23, 2020 at 21:34
  • I switched the boot sequence to the original SSD drive, shut down, physically removed the brand new M.2 SSD, and booted back up. Same problem. No difference. So it has nothing to do with this new drive. Aug 28, 2020 at 4:32
1

Personally i believe this is one of two things, either:

  1. The app is installed on your SSD but it seems Notepad++ is waiting for my other drives, which are regular HDD to spin up before it launches.

or

  1. some of the recent file history was on your network

for fix 1 you would need to doing the follow (Note: if this does not apply to you as you ONLY have the SSD installed then please skip this fix):

easy way to find out if you are loading data from another disk is looking into your config.xml file ( C:\Users%USERPROFILE%\AppData\Roaming\Notepad++ ) Or even better do a Find in Files on that directory and search for your different drive letters like D:\ or E:\

as for the 2nd fix it would be:

look in the config.xml and delete those lines, save the .xml, and opened Notepad++ which should be back to normal speeds

6
  • My C-drive, where NPP is installed, is SSD (M.2 - very fast) and my E-drive (where all my text files are) is also SSD, but not M.2, so not quite as fast. I do have a standard old school hard drive, but it doesn't factor into this equation at all. Aug 18, 2020 at 20:35
  • is the hard drive plugged into your PC?
    – quimantha
    Aug 19, 2020 at 8:59
  • Yes, all internal local drives. No network drives, and my portable/external drives are not in the equation - not opening/saving files there. Aug 20, 2020 at 15:28
  • I think quimantha is suggesting that the seven-second delay is waiting for the old-school drive to spin up from sleep. This is possible even if nothing you're doing would require access to it. Put your ear up to the drive and listen (or just unmount / remove the drive) while you reproduce the issue.
    – JakeRobb
    Aug 20, 2020 at 19:05
  • 2
    @JakeRobb yes this is exactly what i'm saying, if you could unplug the HDD and try booting up notepad++ i think this could be a potential fix for your issue.
    – quimantha
    Aug 21, 2020 at 9:18
1

We are here shooting in the dark, so I will guess. I suggest you gradually narrow down the problem. It will surely take your valuable time, but in the end it might prove profitable.

If you suspect the culprit might be the new disk, try moving away from it in various forms. The OS may have something to do as well. Try:

  1. Using a Live linux, e.g., USB (relatively quick).
  2. Using your old disk (relatively quick, if you still have it).
  3. Setting up another bootable partition (Linux/Win) in the same disk (requires longer).
  4. Setting up a virtual machine (e.g., VirtualBox) under your Win 10.

EDIT: As a general recommendation with problems which are far removed from being understood, my experience (among others, of several years of dealing with PC hardware/software installation and setup) indicates that you have to start with a working system, and gradually incorporate the components of the system that does not work. You are working the opposite way.

Extending the list above:

  1. Make some room in one of your disks and install a new Windows (preferably) or Ubuntu OS. If you consider this might end up being your base OS in the case it performs well, do this at the beginning of the disk so you can later extend the partition to take up the whole disk. YMMV, depending on how you want your final configuration, etc.
4
  • I tried cloning the new/fast SSD to my old/slower SSD (still inside the PC) and booting to the old one. Booted up fine. Problem remains - still crazy-slow to open even the smallest text files when opening from File->Open. But when I open from "recent files" list, always opens instantaneously. Aug 23, 2020 at 20:36
  • @HerrimanCoder - I understand you might not have the time to test all suggestions you receive, for example those in this answer. As I understood, with your old disk you did not see any problems, at least before changing disks, is that correct? If you cloned your new disk into the old one (that is not what I meant in my #2, but only reverting to what you had before, assuming you still had the old OS installation), you may be inheriting the problem. Please see edited answer. Try starting with a system as clean as possible. Aug 24, 2020 at 9:21
  • I switched the boot sequence to the original SSD drive, shut down, physically removed the brand new M.2 SSD, and booted back up. Same problem. No difference. So it has nothing to do with this new drive. Aug 28, 2020 at 4:33
  • There was a bloody shortcut to another PC on my WAN that is inaccessible when I'm not on the VPN. I had forgotten about it. I deleted that, problem INSTANTLY GONE. All files open fast now in all apps. Thanks for all your ideas and time. Aug 28, 2020 at 5:04
0

I am assuming you have Win 10. There is a problem with the application or timing of the Trim function (aka Optimize) for SSDs. See https://www.tenforums.com/performance-maintenance/159489-windows-10-ver-2004-ssd-trim-defrag-glitch.html On the Win 10 task bar, enter Optimize in the search box, then select Defragment and Optiimize Drives. Select the drive you wish to Trim (optimize) and click the Optimize button. Repeat for each drive that you want to trim and then test with NPP.

2
  • Tried this, made no difference. Aug 19, 2020 at 22:06
  • Trimming typically would have an effect on writing to the SSD, but not on reading from it (I assume that the OP does have enough RAM so that opening a small text file won't cause a write to the page file). Defragmenting an SSD does not make any sense at all; rather, it increases wear for nothing.
    – Binarus
    Aug 22, 2020 at 15:28
0

Is Notepad++ allowed out through the firewall to the WWW?

I've noticed similar things when installing it on application servers with a Mail Marshall web traffic controller before, NP++ attempts to communicate with the outside world when it's opened and if it's connection is blocked it takes a few seconds longer to start.

1
  • NPP starts fast, that is not the problem. It's very slow to open files, as mentioned in original post. Aug 19, 2020 at 23:10
0

There is very little data and requests for more data are not being answered, so I need to guess by the fact that the previous SSD was slow and the new one is even slower.

Possible causes:

  • The disk cloning method you are using doesn't respect page boundaries on the SSD
  • The BIOS/UEFI is not updated
  • The motherboard is set to use SATA instead of AHCI or RAID
  • Windows uses a generic disk driver but a driver from the manufacturer may exist
  • The M.2 adapter is an addition, meaning not generic to the motherboard, so it uses a much slower interface than it should.
3
  • harrymc: your suggestions are the most plausible I have heard. But I don't know what you're suggesting I do in order to learn whether any of these are the problem. If it's a driver or adapter problem, how can I tell? Aug 27, 2020 at 1:00
  • Go over the list item by item. For ones you don't know add to the post more info about hardware models.
    – harrymc
    Aug 27, 2020 at 5:54
  • I switched the boot sequence to the original SSD drive, shut down, physically removed the brand new M.2 SSD, and booted back up. Same problem. No difference. So it has nothing to do with this new drive. Aug 28, 2020 at 4:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .