I am working on one of our clients servers remotely, and I ran a chkdsk, with no attributes. It would get into stage 2, and then the entire server would become unresponsive, and the client had to do a hard shutdown and restart. When I logged back into the server, there were no event log errors. Thinking it may have been a fluke, I did the same thing remotely a few days later, and the same thing happened. I've checked for SMART errors and have not found anything, and all the SMART tests point out to be fine.

I don't dare do this again during normal business hours and if I'm not onsite. Any suggestions for where I could look?

Why are you running check disk?

Why are you not using parameters? /f for example? Maybe it needs to fix something.

Also try:

fsutil dirty query C:

The company I work, its a standard of our practice that every quarter we defrag and do a chkdsk on all volumes for our customers server. We do a chkdsk first, then if something needs repair we do that.

Was the volume dirty?

I would run chkdsk /f and if that fails run the manufacturers diagnostic on the hard drive.

Not a dirty volume, checked for that right after.
Chkdsk /f yields the same results
Manufacturer diagnostic was run and they all come back and say the drive is fine.

You may have to make a road trip or get a trusted user to run chkdsk in Safe Mode. FTR, I always use chkdsk /r - it implies /f and provides a more thorough check.

MSKB 315265

I figured out the problem. I dug a little deeper and found out that the BIOS version on the RAID adapter wasn't matching up with the RAID driver version. Apparently, the RAID array was still working, but just... acting slightly odd. Once I uploaded the new firmware and updated the drivers, it works fine now. Thanks!

Hmmm - I am glad you got it figured out and thanks for posting your findings. But I am curious - your previous posts give the impression you previously had no problems logging in and running your quarterly chkdsk/defrag sessions. Yet it seems to me with the BIOS set as it was, you would have always had this problem. Were you able to run these before? If not, it appears something got changed, and perhaps not documented. If you never were able to run these, then that is something that would have been good to know in your opening post.

I thought the same thing, so I went hunting for the engineer who did the last quarterly. The engineer aparently could not run the chkdsk last time a quarterly was conducted, however, he passed it off as a fluke... but just didn't try it again or try to solve the problem -_-. I agree... that woul have been VERY helpful to know before.

And he thought the fluke would go away on it's own?

Oh well. Live and learn. Thanks.