Hard drive acting weird

I would give Crystal Disk Info or Hard Disk Sentinel a go and see what they say. If one or both programs concur with Seagate's Seatools, it could be a failing power supply, power supply connection, bad cable, or bad motherboard port.

Might be interesting to look at the power cycle count and start stop cycle count for the drive both before and after the issue occurs to see if the drive is losing power or perhaps being put to sleep by Windows.

I would assume that the interruption in writing or reading to the drive is after you've had data transferring to the drive for some time. If the interruption happens within seconds of starting a transfer, make certain the drive isn't spun down and simply waiting to spin back up. It's fairly easy to see when a drive is spinning up due to it sitting at 100% in Windows 8 / 10 Task Manager for a few seconds.

Dawned on me, I do believe Seagate has an SMR (Shingled Magnetic Recording) hard drive in the 4 TB capacity range. If the drive you're using happened to be one of those, it would immediately explain the issues you're having. SMR drives are unsuitable for both random access writing, and really unsuitable for more than one write stream of any significant size (I'm going to guess in the hundreds of megabytes range) as it will overrun it's internal buffer and cause the drive to pretty much have a bad day, operating very slowly until it can finish all of the writes that exceeded it's internal buffer. The best example I can think of off the top of my head is the old Lucy episode where Lucy and Ethel can't keep up with the conveyor belt.

If you can find your way into Device Manager, you can see the model number for your drive in the Disk drives category. Otherwise, both recommended software programs should show a model number for your drive. It should be possible with a model number to reference whether your drive is using SMR technology.

To answer your question about cycle counts for the drive, both Hard Disk Sentinel and Crystal Disk Info will show a number that represents those counts, along with a bunch of other metrics that modern drives record. Just look in one of the programs for the number before you have the issue with the drive, then after you experience the issue. I honestly can't say if either program will automatically refresh the cycle count number, so it may have to be reopened to see an updated number. Never tested that before. The raw numbers for SMART info reported by some disk software is often in Hexadecimal, so if it looks funny, it may need to be converted to Decimal.

The ST4000DM000-1F2168 is definitely not an SMR drive. I happen to have one of those on hand so I ran a transfer test on it. The transfer included up to 5 separate streams at times, hitting a low of 20 MB/s each for each stream, over an extended amount of time, but the streams always added up to just over 100 MB/s.

Crystal Disk Mark and Crystal Disk Info are separate products by the same company. One is an information tool, the other is a benchmark tool.

Here is a comparative screen shot of a Crystal Disk Mark run on the same drive I tested. Your limited capacity due to partitioning the drive may be resulting in the low scores you are getting with the 1 GiB test file size. You might try running the test again with a smaller test size that fits within your partition's free space.

The same tests run again at the 100 MiB size.

If Hard Disk Sentinel is mentioning seek errors, that is likely related to the issues you're having. Looking at online reviews for this model shows it to have a bad habit of unannounced failures. I would consider the drive to be on it's way out and look at transitioning to a different drive. I wouldn't necessarily stop using it personally, but I would treat it as an unreliable drive and only use it when I was transferring data that I otherwise have backed up. I would also change my usage pattern and not perform more than a single write at a time, so the drive doesn't have to perform any more seeking than necessary.

You can swap the data cable to the drive, and possibly the SATA port used on the motherboard and re-run the test to see if it returns errors still. I would still consider the drive the most likely culprit.

did you check the drive and google to see if there were any firmware issues?? if not i would contact drive vendor for a replacment. if it not a power issue it may be the drive controller.

I'm not a hard drive guy, but doing a search on "Device SCSI\Disk&Ven_&Prod_ST4000DM000-1F21\4&e937c7&0&030000 was not migrated due to partial or ambiguous match" brings up a not uncommon problem. Could very well be a driver issue. In device manager, uninstall driver for the drive, reboot, windows will reinstall the correct driver. Could be that simple.

For what it's worth: the fact that you're still getting that error leads me to believe the hard drive issue is a symptom of something else. If this is the boot drive and if you're in a position to do so, make sure that you have the latest drivers for your motherboard, make sure your motherboard is running the latest BIOS version, and reinstall Windows. During the reinstall process, make sure that your remove all partitions from the drive before installing Windows. I suspect that with a fresh install of Windows and the latest motherboard drivers, the problem will be resolved. If this drive is not your boot drive, I would still recommend the same process. The fact that when you turn on your system, your system hangs and then your have to turn it off and back on again to get it to boot tells me that you have file corruption on the system drive. Good luck.

Might not be a firmware issue. You can see your drive's current firmware by opening it's Property dialog under Device Manager and looking at the Hardware Ids property on the Details tab. Firmware is the last number on the first line.
There are several different firmware versions used on ST4000DM000-1F21 drives, but according to Seagate, not all firmware versions for a model number drive product are upgrades, but instead are there to support different parts used in manufacturing runs and, using incorrect firmware can make a drive inoperable.

Firmware is determined by date of manufacture rather than model number, so requires the drive's serial number. You can use Seagate's Drive Detect tool to retrieve the serial number and check for Firmware updates on internal drives. External support, such as eSATA docks isn't guaranteed. Hard Disk Sentinel can however still read the serial number from those.

If you are in the process of adding, moving, or deleting files from your volume when it's host disk disconnects from the system or performs an unscheduled stop / start cycle, the volume's file system is very likely in an inconsistent state due to uncommitted, outstanding changes, which should cause it to be marked dirty. This can also happen if corruption is detected.

Windows checks the dirty bit on storage volumes during boot and schedules an immediate chkdsk run if a dirty volume is found.

A successful chkdsk completion should clear the dirty bit from a volume.

The problem your drive seems to be experiencing, disconnecting from the system, doesn't seem to be an error that is being detected by SMART routines built into the drive. From the devices' point of view, it may just appear to be a random, unsafe removal of the drive, either temporarily or permanently. Since the failure condition is happening outside of what SMART for the drive is able to ascertain is a problem, it makes sense that the drive could still be reporting a 100% healthy status.

The drive may remain connected with the SATA controller bus, but due to a malfunction of the drive or it's internal controller, be in a state where it cannot respond to some or all of the commands from the system. Windows should be able to handle this, within reason, but during the boot process the system can very easily be in a state where it simply waits for the response from the drive rather than being able to run simultaneous processes. The system may also time-out and stop waiting if left for a long enough period of time.

You've already found the simply solution which is to, power down both the drive and controller it's attached to and then power them back up.

It's hard to ascertain what the drive is doing from your graphs. Clearly they are inconsistent, but the graphs alone can't decisively indicate why.

It could be due to the drive malfunctioning or from normal seeking, such as when transferring many small, randomly located files, or even heavy file fragmentation. It could also be caused by any temporary interruption between the source drive and the target drive, including the target drive being unable to maintain the same data rate.

I trust you're probably correct about most of the inconsistencies being due to the drive malfunctioning.
If the partition has been scanned due to Windows marking it as dirty, the chkdsk scan may have saved any file fragments found. The files found will likely be marked as hidden (Microsoft logic!) You will want to modify the Folder Options in Windows Explorer to ensure you can see hidden files and folders on your drive, and then go to the partition that appears to have space missing to see if there is a FOUND.000 or similar hidden folder.
Inside the folder will be any recovered files. It's possible they will be useless, as most users won't know what the files are based on a random file name plus file size, and there is no guarantee the files are complete or otherwise incorrupt. Shouldn't hurt to rename some of them and seeing if they open. 3rd party commercial software can usually be used if you think you have lost data that chkdsk has put into a found folder and is likely more practical than trying to go through and rename files manually.

This isn't a problem. You can have up to 4 Primary partitions on one drive when using the MBR partitioning scheme and Microsoft's implementation of GUID Partition Table allows 124 partitions for data use.

Possible corruption on the drive.

You can run chkdsk on it manually if you like, but as the drive is still semi-functioning, this is not the most immediate issue. Also, depending on the nature of the failure, excessive scanning could lead to further deterioration, so you have to decide which is worth more, your data or scanning the drive. I wouldn't worry about this error until you have all of your data off of the drive as the most likely fix is to remove all partitions from the drive and then partition it as you see fit, which is going to require wiping the drive.

This is not a driver issue as Microsoft has been using the same generic storage drivers for over 10 years and isn't in a hurry to update them. If you needed drivers for your storage controllers, you would have long since known about it as you would have been experiencing issues from day one. The only instance I can imagine where it would be a driver issue is if Windows 10 replaced a specific storage driver with an incorrect one, but even this would likely have happened long before now.

if it not the drive controller then the drive getting unclean power from his power supply.

Very sequential workload, so agree with you that the inconsistent transfer rate is a definite symptom of a problem.

GUID isn't a Mac only format, it's sometimes used as an abbreviation for GUID Partition Table (GPT), the replacement for MBR. Any system that can read and write the format should be able to work with it, which should include Windows versions as old as Vista.

The reason for the change is MBR only allows up to 32-bits for addressing a partition, limiting them to 2.2 TB or smaller. You were able to get away with MBR on your 4 TB drive because you went with smaller partitions that easily fit within a 32-bit address space. GPT allows 64-bits for addressing so has a size limitation which won't be a hindrance for some time still.
Unless Windows was installed to the drive that was malfunctioning or has otherwise been directly damaged by your failing drive, which would be hard to do, there is little need to reinstall Windows except for the exercise. If you already have other reasons for wanting to reinstall, those might make more sense.

If you're concerned with whether your Windows files have corruption, you can check them using an elevated or administrative command prompt using the command dism /online /cleanup-image /restorehealth, followed by sfc /scannow. If you're not already familiar, these usually take a few minutes so perhaps run them when you go for a coffee or lunch break. It's normal for the scans to stop for a longer period of time on some percentage points, so give it time before you decide the scan has frozen.

Only thing I would try with that drive is wiping out the partitions and recreating one or more to test it. Rerun your random seek test and see if you still show errors. Moving data to and from the drive should give you a good indication as well. A drive having only seek errors may not be enough for warranty service, but I would certainly see what Seagate says.

Well, Windows Explorer certainly thinks that there is something on those drives. Why, I can't say. You can run chkdsk on them, but if it's not due to a filesystem inconsistency I doubt it's going to fix the problem.

Have you ever had System Restore active on any of those drives? You might wander through the system protection settings for each drive and see what it reports for the current usage size. Even if disabled, you can still have old restore points being stored on them. You should be able to delete them on a per drive basis if you happen to see anything.