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 application 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).
Best Answer
You cannot, but you can secure against happening this again.
This is possible if you have your cloud path set in Preferences:
After the breakdown, immediately turn off syncing with the cloud and restore the original file from there. If your cloud has file versioning, then it is simpler: just retrieve the older version of the
sessions.xml
.This also works for all other setting files, see the link above for details.
Also be sure that you updated to at least Notepad++ 7.5.9.
In its list of fixed bugs, there is
So yes, this has been addressed in October 2018.