Maybe, but in this case I am more and more convinced that my problems were the result of cascading consequences of some corruption that occurred in Windows. The fact that everything is working normally since the  image restore adds credence to that. Again, time will tell.

I'm not really sure what to think, though it still feels like a Windows issue. It started when I tried to move some folders around and change keyboard shortcuts to them. Explorer became unstable and I started getting errors that it had stopped responding. Then most disk access slowed way down, which is what panicked me about the SSD, since I don't have much experience with them. In the course of trying to clear up whatever was going on, I rebooted a few times and each time something different happened. At some point I couldn't reboot at all and had to do a repair. That fixed some things, made others worse, and everything was still super slow. Finally checkdisk kicked in on one reboot and spent a long 
time listing hundreds and hundreds of errors. At that point I decided to restore the image I had made a few days earlier and that fixed everything. This is a summary. It doesn't cover everything that happened (I can't remember it all) and the sequence may be a little off. What I can say is I started having problems for whatever reason, and they escalated into a continuously increasing mess until I finally just did an image restore, which put everything back to where it was before the problems started. If this doesn't happen again, and the drive keeps working okay, I will have to conclude that it was another typical Windows meltdown a la Windows 98, which used to do this kind of thing a lot.

I will certainly keep an eye on it and do some other research to see what I can find out, but any event logs are gone since I restored the entire drive. It will be interesting to see what happens over the next couple of weeks.

Seen similar thing on a PC that I fixed for a friend who had just cloned over and was using legacy boot, partition table and not AHCI drivers so no trim support, was running in IDE mode

Any writes to the drive were taking forever, and since there was no command queueing etc the whole thing just stalled for ages.

Changed it to use AHCI, which took forever and restarted, and it gradually came right, then fixed it up to do UEFI booting. I guess as windows was now triming as things were deleted it was gradually improving as the drive started to have lots of slack space to work with.

Typical problem from cloning an incorrectly done windows install onto new hardware by software that should be smart enough to alert the user to the problem and let them correct it before making the change. At least AHCI is now the default on most motherboards so it should be a rare problem going forwards.

As you say it is used for recording, there is probably a lot of stuff written to the disk, read once as you play back and then deleted which without trim will mean the drive has no way to know that the space is no longer needed and it is preserving it until windows then writes new data to that logical space. Recipie for the drive to be constantly wear leveling and not servicing your writes in a timely manner.

How did the OP migrate his system onto the Sandisk SSD? (the correct method aligns the clusters correctly)

This was a clean install on a new drive from an official Win 7 DVD. It is an older PC so wouldn't have UEFI booting. I didn't check the BIOS before the install, just went with the defaults. More than that I cannot say.

joker97:

 

How did the OP migrate his system onto the Sandisk SSD? (the correct method aligns the clusters correctly)

 

Most tools will align it, but I have yet to see one that warns you if your OS/controller combo will not do trim.

Trim is essential, particually in a write heavy situation like a DVR PC. Mine ran for years with no drop in performance because it had trim support, a friends one which was an older mobo that didnt do it was running like trash after a couple of months. Ended up going back to a noisy spinning HDD in that machine because it was the easiest way to get it solved.

Rikkitic:

 

This was a clean install on a new drive from an official Win 7 DVD. It is an older PC so wouldn't have UEFI booting. I didn't check the BIOS before the install, just went with the defaults. More than that I cannot say.

 

Well have a look in device manager and see what the controller shows as, AHCI is needed to have trim, if you dont have it then there are plenty of tutorials on changing it on an existing installation.

I will certainly do that. Thanks for the tip.

richms:

 

Seen similar thing on a PC that I fixed for a friend who had just cloned over and was using legacy boot, partition table and not AHCI drivers so no trim support, was running in IDE mode

 

Any writes to the drive were taking forever, and since there was no command queueing etc the whole thing just stalled for ages.

 

Changed it to use AHCI, which took forever and restarted, and it gradually came right, then fixed it up to do UEFI booting. I guess as windows was now triming as things were deleted it was gradually improving as the drive started to have lots of slack space to work with.

 

Typical problem from cloning an incorrectly done windows install onto new hardware by software that should be smart enough to alert the user to the problem and let them correct it before making the change. At least AHCI is now the default on most motherboards so it should be a rare problem going forwards.

 

As you say it is used for recording, there is probably a lot of stuff written to the disk, read once as you play back and then deleted which without trim will mean the drive has no way to know that the space is no longer needed and it is preserving it until windows then writes new data to that logical space. Recipie for the drive to be constantly wear leveling and not servicing your writes in a timely manner.

 

@richms I checked fsutil and trim is set on my machine. However, the BIOS is fixed on IDE with no option to change it. I have found a procedure for changing this via the Registry but this is over my head (not editing the Registry; I am comfortable with that). What I am unsure of is what the procedure will do. I have already had one near-death experience with this and I don't want to risk killing it completely. Can you advise if this is something I should attempt?

If you wish to continue using a SSD in the machine, then you need AHCI to have trim actually work.

You edit the key, and it enables the AHCI driver, nothing else. It is not enabled because you had it set to IDE in the BIOS setup when you installed windows.

Once you edit that and reboot, you can change to AHCI in the BIOS setup, then _power off_ the machine and start it up again. You may need to re-setup the boot order if you leave USB HDD's or sticks connected to the computer as they will possibly now be furthur up the order than the drive.

Once in windows it will just re-detect the controller and possibly the drive. Reboot again, it may detect the drive again after the second reboot, then reboot again if it does.

You will then have trim enabled, so you will not have the drive constantly scavanging for writable blocks after its had a few capacities worth of writes done to it.

If the bios setup doesnt let you change from IDE, then possibly you are looking at the wrong one, there are sometimes different options for the first ports and the others, and the first ports have to be on AHCI before the others will let you change, or you need to go into an advanced option or something. I have old core 2 duo era machines that have ACHI so if its not there then I hate to think how old it is.