So. Anyone else have their system insisting on a drive check every single reboot? I'm a little vexed and perplexed here, so if anyone can offer me some insight, please do:
1) The drive in question is showing no signs of failure; It is consistently recognized by the OS and has never had read/write issues. The disk check itself always comes up error free.
2) Drive in question is an older SATA2 500 gb Seagate. I'm afraid I do not remember the specific model serial offhand, but the hardware identifier is ST3500418AS.
3) I've previously tried a dirty query on the drive (fsutil), to see if the 'dirty' flag is set. It isn't.
4) I've manually tried a chkdsk (with options /f and /r)
Goddamn thing is showing up clean and fully functional. Any of you have any idea what gives? It's that specific drive it's bitching about. I'm guessing this is some quirk of Win7 using pre Win7 hardware (Hell, in this one's case, almost pre-Vista).
Is it NTFS or FAT32?
If it's FAT32, it will wind up with a free space count problem every time you unplug it without unmounting/ejecting it from the system.
Furthermore, there are problems that chkdsk doesn't fix. You can try other disk scanning programs such as Norton Disk Doctor.
If that doesn't solve your problem, use a 0 bit wipe program on it, repartition, format, and load the drive again. That will work every time.
It's an internal NTFS drive. If it's getting unmounted, there's other fairly severe problems afoot, given that the OS is installed on it. I should have specifically mentioned that chkdisk is not the sole scanning utility I've run it through (I will not run it through Norton; none of their products have any business being within ten feet of my computer, nevermind installed on it; I use Gizmo (not the coyote, amusing as it would be to plug things into him, the tool fleet), Kaspersky, and a good hardware firewall instead). In this particular case, formatting and bitwiping the drive is an unacceptable solution. If the drive is failing in some fashion, I do not want to nuke and pave it simply to fix what may be an incorrect setting or a bus issue. The drive itself has come up clean to all forms of inspection, which is peculiar. The only other thing I can personally think of is a firmware issue on both the mainboard (Windows Vista era) and the drive itself (Windows XP era). Google comes up negative on specific possible problems, however, for the hardware combination (first generation eVGA X58 mainboard + ST3500418AS SATA2 drive).
Gnaaah. I do not need this happening with my workstation right now, though the drive IS starting to get near the age of possible failure (Purchased in 2006, I believe). Already have its contents backed up to an external, thankfully, and anything important workwise is on the SVN.
Ahh, I misread and thought it was an external removable drive.
I did have a similar case once, with Windows XP on a computer that had a SATA controller installed into a PCI slot.
In that case, the card had to be in a certain specific slot so that it wouldn't share IRQ's with anything else, before it would stop insisting the drive needed to be scanned. Same thing with Vista on that machine.
It also mattered on that computer, which order each driver was installed for all the hardware. You even had to remove the secondary video card just to install the sound driver or the whole machine would freeze up.
That computer was a monster. Every slot filled, every drive bay filled.
....Crazy enough, I may actually want to eyeball that. All 10 SATA ports on the motherboard are filled, and there's 14 USB ports on it (10 of which are filled at all times), in addition to two GPUs. It may be a tad busy on the addressing front. :P
Good luck. Let me know how it turns out.
: Selkit January 19, 2011, 01:07:34 -07:00
....Crazy enough, I may actually want to eyeball that. All 10 SATA ports on the motherboard are filled, and there's 14 USB ports on it (10 of which are filled at all times), in addition to two GPUs. It may be a tad busy on the addressing front. :P
Good lord, what are you doing to that poor computer? :)
This might help
http://social.technet.microsoft.com/Forums/en/w7itprogeneral/thread/a7d5c759-c8c6-49cc-80af-589e28f13a65 (http://social.technet.microsoft.com/Forums/en/w7itprogeneral/thread/a7d5c759-c8c6-49cc-80af-589e28f13a65)
While I'm tempted to say "lol-Seacrate", it sounds like an issue is at hand.
Acronis your drive, since it's your OS drive, ASAP.
With all that stuff plugged in, is your PSU able to handle the load well enough?
Maybe it's a motherboard issue. Update the Bios and see if there's new chipset drivers?
It does sound kind of like the OS isn't able to gracefully park the drive, making it think that Windows wasn't shut down properly. That could easily be either a driver/bios issue, or a fauly within Windows.
Yeah, it's a Seacrate. At least it's not one of those Hitachi DeskStars (lol deathstars) from a few years back. Those things were hideous. PSU-wise, I would be very, very surprised if that's the issue; I'm running a 1 kW PSU. On the other hand, mainboard firmware? That's a likely culprit, given that the mainboard is now two years old, predates Win7 and has not had a BIOS update since it left the factory; I'll be giving it one shortly as a Hail Mary step. I've already taken a ghost image of the drive (Failure is now an option, and anything actually important on the drive has been backed up). Regarding the technet link (WKoot's post), I've already run it through fsutil and chkdisk with a few different parameters to probe for issues. I'm relatively sure it isn't the drive itself anymore.
: Selkit January 20, 2011, 04:09:21 -07:00
Yeah, it's a Seacrate. At least it's not one of those Hitachi DeskStars (lol deathstars) from a few years back. Those things were hideous.
Yeah, I lost several years' worth of irreplaceable data to one of those things. >:(
: Silvermink January 20, 2011, 09:55:34 -07:00
: Selkit January 20, 2011, 04:09:21 -07:00
Yeah, it's a Seacrate. At least it's not one of those Hitachi DeskStars (lol deathstars) from a few years back. Those things were hideous.
Yeah, I lost several years' worth of irreplaceable data to one of those things. >:(
Hence why I have all 10 SATA ports filled, Minky. Multiple redundant backups. Only 1 tb space, but double redundant storage.
: Selkit January 20, 2011, 04:50:51 -07:00
Hence why I have all 10 SATA ports filled, Minky. Multiple redundant backups. Only 1 tb space, but double redundant storage.
I've stored all my irreplaceable data on a RAID 1 NAS since then, myself. I should probably do DVD backups off it, too.
If I did DVD backups of my work, I'd have an archive of hundreds before long. No joke. One single texture file (the working files, not the finished result, which is usually only 2-3 mb with lossless compression), is anywhere from 40 to 200+ mb. 2048x2048x uncompressed images with a 48 bit HDR layer with at least 1 alpha channel and up to 10 layers, are not lightweight.
One word: LTO4.
Silly Kay, necro'd thread is necro'd. I actually finally determined what the root cause of this issue is. It has to do with the Windows Indexing service, virtual drives, and version control software; It's the result of a process conflict occurring when the Windows Indexer attempts to access a file that version control is currently juggling, because it spots an opclock change with the file, then attempts to re-index it. As the version control isn't a system process, it causes multiple access collisions, then has to back down. The OS assumes that the issue with that particular file is not actually a process collision (owing to the way it happens), but a corrupt entry. Thus, it marks the volume dirty. Thankfully, service pack 1 included a patch for this particular issue.
Welcome to Windows.
Also, as for the thread being old, Im not used to forums considering a thread to be dead quite that soon, but I guess its common these days with information being dead in a month.