Thanks for the explanation. I am running chkdsk /r now. It'll take a while as it is a 500GB disk. I don't think the anitvirus software is an issue. I have been running Norton Antivirus for years on the XP machine where this drive was originally attached and it worked just fine. I am running Norton Antivirus on my Vista machine as well and have had no issues of any kind.
I'd suggest not ruling out possible culprits too early. You're currently doing that in two ways:
- The fact that the drive used to work under XP is significant, but not conclusive. All hardware eventually breaks down, especially hardware with moving parts. Weeks or months or years ago the drive may have been OK, but by now it could have developed a fault. Hence, it would be useful to test it on another machine in the present. If it still fails to display any evidence of abnormality, then you can truly be reasonably certain the hardware is not at fault (it's not conclusive though!).
- The fact that a different extremely complex software mechanism (older versions of NAV) used to work without causing this issue when interfacing with another completely different and extremely complex software mechanism (Windows XP), pause for breath, doesn't prove anything in particular. Unfortunately, new bugs ("regressions") are routinely introduced in newer software versions, and both your AV and our OS have gone through many revisions since this all worked.
I have absolutely no proof that your hardware or your AV is in any way involved, but I'd hate to see you spend many hours looking in the wrong direction because something was discounted too early
What on earth is a filter driver? And what would the problem be if it is this thing whatever it is? Assuming the chkdsk runs clean, what would be the next thing to look at?
A "filter driver" is a software shim in between applications and the resource they are trying to access. For example, without a filter driver, a (very) simplifed relationship might look like this:
[application] <---> [OS] <---> [disk]
In other words, the app makes a read/write request and the OS accesses the disk and does the app's bidding. Now if you were, say, an anti-virus utility, you'd want to be inspecting all file activity to check for infections. In terms of architecture, the way you'd do that is by inserting a filter driver into the path:
[application] <---> [OS] <---> [FILTER DRIVER] <---> [disk]
The filter driver (FD) then "sees" all attempts to interact with the disk. At its sole discretion, a FD can completely ignore a request and pass it along in its original format, it can modify the request in whatever way it sees fit, or it can unceremoniously delete the request thereby denying the app. Obviously, a FD is in a powerful position, and indeed many parts of the OS itself are implemented as FDs.
Since all apps seem to be equally affected and at the same time too, if this is a software problem it will likely come down to corruption of the OS - or a 3rd-party FD which has a bug that sometimes manifests itself as unintentional denial of write requests. That's why I'm suggesting you try to simplify the configuration temporarily and remove as many security and "inspection" utilities as possible. If it happens even once with your AV completely out of the picture, obviously the AV is not involved. Same with any anti-malware or non-default firewall utilities on there.