Reformatting 2nd Partition on HD Question

[SuperBusa]

As some of you know, I had major computer issues a while back but was able to get it running again. After I got my computer able to boot up into Windows XP, I ran CHKDSK on both my HD partitions (C:\ and D:\) from an ISO image boot disk with Windows XP Recovery Console on it and CHKDSK took ~58 GB of the 66 GB total space on my D:\ drive (the 2nd, non-bootable partition) and decided to mark the 58 GB as 'bad clusters' to the "Bad Clusters File".

Message seen in CHKDSK report:
-----------------------------------------------
Adding 15284615 bad clusters to the Bad Clusters File.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.

69529319 KB total disk space.
1964348 KB in 1367 files.
616 KB in 109 indexes.
61138460 KB in bad sectors.
-----------------------------------------------

Before this happened, I had ran SeaTools Desktop diagnostics (I have a Seagate HD) more than once on the whole HD and it said every sector was physically good.

I don't recall exactly what a "bad cluster" is and why CHKDSK would want to disable these areas of the HD. But it looks like I can do a reformat on this 2nd partition in:

Start > Control Panel > Administrative Tools > Computer Management > Disk Manager.

I can see both partitions, and their size is what I originally specified when I put this HD in. If I highlight dirve D:\, and right click I see the "Format ..." option.

I've backed up all my files on D:\ ... so wondering if I can simpley do a reformat as described above without effecting my C:\ in any way?

 

[OVERKILL]

You can try it, though I'd do a chkdsk /r on it after using a new cable for the drive first..... You may find that was the source of your problem.

 

[SuperBusa]

Originally Posted By: OVERK1LL
You can try it, though I'd do a chkdsk /r on it after using a new cable for the drive first..... You may find that was the source of your problem.


New cable? ... that's strange. I can run SeaTools full HD diagnotics on the drive and it comes back clean with zero errors.

I ran CHKDSK /R on both C: and D: drives in Windows XP and it never found "bad clusters", but when I ran CHKDSK /P from the Recovery Console is when this happened. Note that CHKDSK /P is not an available switch in Windows, but only in Recovery Console.

Any other ideas before I try a different HD cable ... I just don't think it's the cable at this point. If the cable was bad, wouldn't there be other symptoms with the HD?

 

[OVERKILL]

Not necessarily, though usually a bad cable shows itself under Windows NOT in safe mode/recovery console, due to the use of DMA under regular use.

It's just odd that it would flag bad clusters if there wasn't causing it to do so......

Also, how come you used /p instead of /r in recovery console? /r is more thorough.

 

[SuperBusa]

Originally Posted By: OVERK1LL
Not necessarily, though usually a bad cable shows itself under Windows NOT in safe mode/recovery console, due to the use of DMA under regular use.

It's just odd that it would flag bad clusters if there wasn't causing it to do so......


Yes, it is very strange that it flagged 58 GB worth of 'bad clusters' for some reason. Like I said earlier, I ran CHKDSK /F (and /R I think) many times via "Command Prompt" in Windows and it never flagged bad clusters. Only when I ran it via Recovery Console. My machine seems to run fine in Windows now, but CHKDSK always seems to find a few errors on the C:\ partition and if fixed they seem to return again. These errors are usually something like this:

Cleaning up minor inconsistencies on the drive.
Cleaning up 2 unused index entries from index $SII of file 0x9.
Cleaning up 2 unused index entries from index $SDH of file 0x9.
Cleaning up 2 unused security descriptors.

Originally Posted By: OVERK1LL
Also, how come you used /p instead of /r in recovery console? /r is more thorough.


I ran both /P and /R in Recovery Console on both partitions.

 

[SuperBusa]

For what's it's worth, here is the log of what CHKDSK /R reported when ran from Recovery Console and it flagged 58.3 GB worth of bad clusters:


For HDD Partition 2 (D:\)
========================================
Checking file system on \DosDevices\D:
The type of the file system is NTFS.

The volume is dirty.
The attribute of type 0x90 and instance tag 0x27 should be after
attribute of type 0x90 and instance tag 0x24 in file 0x9.
All attribute of type 0x90 and instance tag 0x27 should be indexed
in file 0x9.
Sorting attribute records for file record segment 9.
The multi-sector header signature for VCN 0x0 of index $I30
in file 0x5 is incorrect.
e0 64 fb ae 05 2f cb 15 4b 60 3a 1f 41 73 fa 40 .d.../..K`:.As.@
ab f1 aa e7 4c 16 a2 5d e4 31 a2 e7 26 d3 6f d8 ....L..].1..&.o.
Correcting error in index $I30 for file 5.
The index bitmap $I30 in file 0x5 is incorrect.
Correcting error in index $I30 for file 5.
The down pointer of current index entry with length 0x70 is invalid.
21 01 00 00 00 00 01 00 70 00 52 00 01 00 00 00 !.......p.R.....
05 00 00 00 00 00 05 00 5c 67 5c 79 de 1f c6 01 ........\g\y....
b2 78 52 78 38 3e c9 01 b2 78 52 78 38 3e c9 01 .xRx8>...xRx8>..
e4 81 81 18 54 9e ca 01 00 00 00 00 00 00 00 00 ....T...........
00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 ................
08 02 47 00 55 00 4e 00 49 00 4e 00 46 00 7e 00 ..G.U.N.I.N.F.~.
31 00 67 00 20 00 52 00 ff ff ff ff ff ff ff ff 1.g. .R.........
00 00 00 00 00 00 00 00 18 00 00 00 03 00 00 00 ................
Sorting index $I30 in file 5.
The index root $SII is missing in file 0x9.
Correcting error in index $SII for file 9.
The multi-sector header signature for VCN 0x0 of index $SDH
in file 0x9 is incorrect.
6a 0b c8 b7 6c 45 5d 0a fc a5 a0 a6 81 08 20 4d j...lE]....... M
1c 41 c5 6c bd b9 79 63 4d 41 cb 72 54 17 fa b7 .A.l..ycMA.rT...
Correcting error in index $SDH for file 9.
The index bitmap $SDH in file 0x9 is incorrect.
Correcting error in index $SDH for file 9.
The down pointer of current index entry with length 0x18 is invalid.
00 00 00 00 00 00 00 00 18 00 00 00 03 00 00 00 ................
ff ff ff ff ff ff ff ff 5c 67 5c 79 de 1f c6 01 ........\g\y....
b2 78 52 78 38 3e c9 01 b2 78 52 78 38 3e c9 01 .xRx8>...xRx8>..
Sorting index $SDH in file 9.
The multi-sector header signature for VCN 0x0 of index $I30
in file 0x1b is incorrect.
7a 6b 3e c2 5d 87 74 4d 1d cd 61 ff 1a 21 97 69 zk>.].tM..a..!.i
89 95 68 e4 92 3f 0d b4 6d bb e6 1c 75 fa 90 a3 ..h..?..m...u...
Correcting error in index $I30 for file 27.
The index bitmap $I30 in file 0x1b is incorrect.
Correcting error in index $I30 for file 27.
The down pointer of current index entry with length 0x18 is invalid.
00 00 00 00 00 00 00 00 18 00 00 00 03 00 00 00 ................
ff ff ff ff ff ff ff ff 01 02 00 00 00 00 00 00 ................
00 00 00 00 6e 47 d2 28 85 16 c6 01 ff ff ff ff ....nG.(........
Sorting index $I30 in file 27.
The multi-sector header signature for VCN 0x0 of index $I30
in file 0x209 is incorrect.
c5 af 5b d4 c8 17 c2 6b 26 1e 7c 65 b0 22 67 cc ..[....k&.|e."g.
fa fe c0 49 c0 bf 53 4b 6e c6 fc 41 23 76 82 4d ...I..SKn..A#v.M
Correcting error in index $I30 for file 521.
The index bitmap $I30 in file 0x209 is incorrect.
Correcting error in index $I30 for file 521.
The down pointer of current index entry with length 0x18 is invalid.
00 00 00 00 00 00 00 00 18 00 00 00 03 00 00 00 ................
ff ff ff ff ff ff ff ff 6e fd 11 e2 63 29 c6 01 ........n...c)..
00 73 ad ce 1a 29 c6 01 aa cf cd 5d 0b 8d ca 01 .s...).....]....
Sorting index $I30 in file 521.
Cleaning up minor inconsistencies on the drive.
CHKDSK is recovering lost files.
Recovering orphaned file $MFT (0) into directory file 5.
Recovering orphaned file $MFTMirr (1) into directory file 5.
Recovering orphaned file $LogFile (2) into directory file 5.
Recovering orphaned file $Volume (3) into directory file 5.
Recovering orphaned file $AttrDef (4) into directory file 5.
Recovering orphaned file . (5) into directory file 5.
Recovering orphaned file $Bitmap (6) into directory file 5.
Recovering orphaned file $Boot (7) into directory file 5.
Recovering orphaned file $BadClus (8) into directory file 5.
Recovering orphaned file $Secure (9) into directory file 5.
Recovering orphaned file $UpCase (10) into directory file 5.
Recovering orphaned file $Extend (11) into directory file 5.
Recovering orphaned file MOUNTP~1 (28) into directory file 27.
Recovering orphaned file MountPointManagerRemoteDatabase (28) into directory file 27.
Recovering orphaned file tracking.log (37) into directory file 27.
Recovering orphaned file DIGITA~1 (106) into directory file 5.
Recovering orphaned file Digital Pix (106) into directory file 5.
Recovering orphaned file Gun Info (289) into directory file 5.
Recovering orphaned file FUJIE5~1 (369) into directory file 5.
Recovering orphaned file Fuji E550 Info (369) into directory file 5.
Recovering orphaned file DELL44~1 (373) into directory file 5.
Recovering orphaned file DELL4400 Info (373) into directory file 5.
Recovering orphaned file F1040-~1.PDF (522) into directory file 521.
Recovering orphaned file f1040--2004.pdf (522) into directory file 521.
Recovering orphaned file F1040S~1.PDF (561) into directory file 521.
Recovering orphaned file f1040sab--2004.pdf (561) into directory file 521.
Recovering orphaned file I1040-~1.PDF (564) into directory file 521.
Recovering orphaned file i1040--2004.pdf (564) into directory file 521.
Recovering orphaned file I1040S~1.PDF (569) into directory file 521.
Recovering orphaned file i1040sa--2004.pdf (569) into directory file 521.
Recovering orphaned file 1098LA~1 (582) into directory file 5.
Recovering orphaned file 1098 Launch 2007 (582) into directory file 5.
Recovering orphaned file DUCATI~1 (615) into directory file 5.
Recovering orphaned file Ducati 1098 (615) into directory file 5.
Recovering orphaned file LOCALS~3.PDF (990) into directory file 521.
Recovering orphaned file LocalSlsUseFlyer_04_Q1.pdf (990) into directory file 521.
Recovering orphaned file LOCALS~4.PDF (991) into directory file 521.
Recovering orphaned file LocalSlsUseFlyer_04_Q2.pdf (991) into directory file 521.
Recovering orphaned file LO97E2~1.PDF (992) into directory file 521.
Recovering orphaned file LocalSlsUseFlyer_04_Q3.pdf (992) into directory file 521.
Recovering orphaned file LO97EE~1.PDF (993) into directory file 521.
Recovering orphaned file LocalSlsUseFlyer_04_Q4.pdf (993) into directory file 521.
Recovering orphaned file LOCALS~1.PDF (1006) into directory file 521.
Recovering orphaned file LocalSlsUseFlyer_04_A.pdf (1006) into directory file 521.
Recovering orphaned file LOCALS~2.PDF (1007) into directory file 521.
Recovering orphaned file LocalSlsUseFlyer_03_A.pdf (1007) into directory file 521.
Recovering orphaned file LOCALS~1.URL (1021) into directory file 521.
Recovering orphaned file Local Sales and Use Tax Rates and Changes Flyer.url (1021) into directory file 521.
Recovering orphaned file FEDERA~1 (1064) into directory file 5.
Recovering orphaned file Federal Income Taxes (1064) into directory file 5.
Recovering orphaned file 3RDGEN~1 (1339) into directory file 5.
Recovering orphaned file 3rd Gen RX-7 Info (1339) into directory file 5.
Creating index $SII for file 9.
Inserting an index entry with Id 256 into index $SII of file 9.
Inserting an index entry with Id 256 into index $SDH of file 9.
Inserting an index entry with Id 257 into index $SII of file 9.
Inserting an index entry with Id 257 into index $SDH of file 9.
Inserting an index entry with Id 258 into index $SII of file 9.
Inserting an index entry with Id 258 into index $SDH of file 9.
Inserting an index entry with Id 259 into index $SII of file 9.
Inserting an index entry with Id 259 into index $SDH of file 9.
Inserting an index entry with Id 260 into index $SII of file 9.
Inserting an index entry with Id 260 into index $SDH of file 9.
Inserting an index entry with Id 264 into index $SII of file 9.
Inserting an index entry with Id 264 into index $SDH of file 9.
Inserting an index entry with Id 265 into index $SII of file 9.
Inserting an index entry with Id 265 into index $SDH of file 9.
Inserting an index entry with Id 266 into index $SII of file 9.
Inserting an index entry with Id 266 into index $SDH of file 9.
Inserting an index entry with Id 267 into index $SII of file 9.
Inserting an index entry with Id 267 into index $SDH of file 9.
Inserting an index entry with Id 268 into index $SII of file 9.
Inserting an index entry with Id 268 into index $SDH of file 9.
Inserting an index entry with Id 269 into index $SII of file 9.
Inserting an index entry with Id 269 into index $SDH of file 9.
Inserting an index entry with Id 271 into index $SII of file 9.
Inserting an index entry with Id 271 into index $SDH of file 9.
Repairing the security file record segment.
Replacing missing or invalid security descriptor for file 5.
The MFT mirror is different from the MFT.
Correcting errors in the Master File Table (MFT) mirror.
The upcase file content is incorrect.
Correcting errors in the uppercase file.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.

69529319 KB total disk space.
1964328 KB in 1366 files.
628 KB in 109 indexes.
0 KB in bad sectors.
69715 KB in use by the system.
65536 KB occupied by the log file.
67494648 KB available on disk.

4096 bytes in each allocation unit.
17382329 total allocation units on disk.
16873662 allocation units available on disk.


Checking file system on \DosDevices\D:
The type of the file system is NTFS.
CHKDSK is verifying file data (stage 4 of 5)...
File data verification completed.
CHKDSK is verifying free space (stage 5 of 5)...
Free space verification is complete.
Adding 15284615 bad clusters to the Bad Clusters File. span>
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.

69529319 KB total disk space.
1964348 KB in 1367 files.
616 KB in 109 indexes.
61138460 KB in bad sectors. span>
69727 KB in use by the system.
65536 KB occupied by the log file.
6356168 KB available on disk. span>

4096 bytes in each allocation unit.
17382329 total allocation units on disk.
1589042 allocation units available on disk.
=======================================

 

[OVERKILL]

For future reference, running /p then /r is redundant. /r implies /p.

Always just use /r.

SO, if you run chkdsk /r on that drive from within Windows now it does what?

 

[SuperBusa]

Originally Posted By: OVERK1LL
For future reference, running /p then /r is redundant. /r implies /p.

Always just use /r.


Yes, I found that out later ... but bottom line is I ran /R in the end.

Originally Posted By: OVERK1LL
SO, if you run chkdsk /r on that drive from within Windows now it does what?


I did a CHKDSK /R on the D:\ drive from 'Command Prompt' in Windows and the result was no errors were found, and it showed that there is still 61138460 KB in bad sectors.

 

[OVERKILL]

Originally Posted By: SuperBusa
Originally Posted By: OVERK1LL
For future reference, running /p then /r is redundant. /r implies /p.

Always just use /r.


Yes, I found that out later ... but bottom line is I ran /R in the end.

Originally Posted By: OVERK1LL
SO, if you run chkdsk /r on that drive from within Windows now it does what?


I did a CHKDSK /R on the D:\ drive from 'Command Prompt' in Windows and the result was no errors were found, and it showed that there is still 61138460 KB in bad sectors.


Hmmmmm, very peculiar behaviour. What model is the drive?

 

[javacontour]

I'm a Unix guy, but willing to learn, so what I'm saying/asking is due to Unix knowledge.

Is chkdsk checking the whole block or cluster, or is it just checking the metadata and making a decision.

In Unix based system, such as Solaris, fsck checks the file system structure. It doesn't read each data block, but reads the metadata such as directories, inode tables, the super block and all it's copies and makes sure the file system is logically correct. You can still have data corruption, and fsck will not find it. Why? Because it's not reading all the data blocks in the file system. Plus, how would it know what you should have in your database table, or any other file?

In Solaris, the format utility has an option to analyze the disk. From that sub-menu, you can read every block, or even read it, write it back and read it again. Or if you want to be destructive (or wipe the data) you can write first, then read to verify the drive works. But again, this only tells you if the disk is working. You can still have corruption because the file is no longer in the format it was originally written. Unlikely because of the checksums used. But ultimately the application that wrote the data has to verify it before one can say with confidence the data is good.

So my question about chkdsk is what is it doing to determine a cluster is bad? Given how much time is used to chkdsk, I don't think it's reading or verifying each physical block on the disk, but looking the logical structure of the file system as a whole.

So, if chkdsk works in a fashion similar to fsck, you could have a perfectly good disk, but the file system is trashed, causing it to mark many things bad.

So I'm with the first suggestion, format the drive. Not a quick format, and see if it passes.

I think you can check the mode used to access the drive to see if you have DMA and what mode to confirm the cable, etc.

You don't mention if this drive is a slave on the same IDE channel as the first drive, or the master on the secondary IDE channel. If it's a slave with the other drive, then the cable is likely fine. If it's on the other channel, then either a new cable, or isolation from any other IDE device such as your CD/DVD drive would be a good troubleshooting step to take.

 

[OVERKILL]

chkdsk with the /r parameter checks every block.

Originally Posted By: Microsoft

Manual steps to run Chkdsk at the command prompt

1. Click Start, and then Run.
2. In Open, type cmd, and then press ENTER.
3. Use one of the following procedures:
* To run Chkdsk in read-only mode, at the command prompt, type chkdsk, and then press ENTER.
* To repair errors without scanning the volume for bad sectors, at the command prompt, type chkdsk volume:/f, and then press ENTER.

Note If one or more of the files on the hard disk are open, you will receive the following message:
Chkdsk cannot run because the volume is in use by another process. Would you like to schedule this volume to be checked the next time the system restarts? (Y/N)
Type Y, and then press ENTER to schedule the disk check, and then restart your computer to start the disk check.
* To repair errors, locate bad sectors, and recover readable information, at the command prompt, type chkdsk volume:/r, and then press ENTER.

Note If one or more of the files on the hard disk are open, you will receive the following message:
Chkdsk cannot run because the volume is in use by another process. Would you like to schedule this volume to be checked the next time the system restarts? (Y/N)
Type Y, and then press ENTER to schedule the disk check, and then restart your computer to start the disk check.

 

[SuperBusa]

Originally Posted By: OVERK1LL
SO, if you run chkdsk /r on that drive from within Windows now it does what?

Originally Posted By: SuperBusa
I did a CHKDSK /R on the D:\ drive from 'Command Prompt' in Windows and the result was no errors were found, and it showed that there is still 61138460 KB in bad sectors.


Hmmmmm, very peculiar behaviour. What model is the drive?


There is only one HD inside the computer .... a Seagate Barracuda 7200.7, model ST3200822A (200 GB).

The one HD is partitioned ... C:\ @ 120 GB (the bootable partition) and D:\ @ 66.3 GB for my personal files.

 

[SuperBusa]

Originally Posted By: javacontour

So, if chkdsk works in a fashion similar to fsck, you could have a perfectly good disk, but the file system is trashed, causing it to mark many things bad.


I think it's the file system that's trashed. I've checked the Seagate HD with 'SeaTools Desktop' (Seagate's full diagnotics sofware for hard drives) many times and it always passes the full blown tests with zero errors.

What is very strange is that I've checked the D:\ drive more than once with CHKDSK, and did a CHKDSK /R a couple of times using the 'Command Prompt" in Windows and it came out clean. Then the one time I ran CHKDSK /R through the Windows XP Recovery Console, CHKDSK went and claimed there were all these bad clusters on D:\ and marked them as such. I'm wondering if running CHKDSK through Recovery Console on a secondary partition isn't a good thing to do?

Originally Posted By: javacontour
So I'm with the first suggestion, format the drive. Not a quick format, and see if it passes.

I think you can check the mode used to access the drive to see if you have DMA and what mode to confirm the cable, etc.


I've also ran diagnostics to check the motherboard, IED controller, RAM, etc ... all the hardware passes every time.

Originally Posted By: javacontour
You don't mention if this drive is a slave on the same IDE channel as the first drive, or the master on the secondary IDE channel.


As just mentioned in a few posts above, this is the only HD in the computer, and is partitioned into C:\ and D:\.

 

[SuperBusa]

So I did another CHKDSK /R on the C: drive tonight, and this is the results.

=======================================================
Event Source: Winlogon
Computer: DELL4400
Checking file system on C:
The type of the file system is NTFS.

A disk check has been scheduled.
Windows will now check the disk.
Cleaning up 8 unused index entries from index $SII of file 0x9.
Cleaning up 8 unused index entries from index $SDH of file 0x9.
Cleaning up 8 unused security descriptors.
CHKDSK is verifying Usn Journal...
Usn Journal verification completed.
CHKDSK is verifying file data (stage 4 of 5)...
File data verification completed.
CHKDSK is verifying free space (stage 5 of 5)...
Free space verification is complete.

125829080 KB total disk space.
32565640 KB in 53685 files.
19140 KB in 4572 indexes.
0 KB in bad sectors.
174472 KB in use by the system.
65536 KB occupied by the log file.
93069828 KB available on disk.

4096 bytes in each allocation unit.
31457270 total allocation units on disk.
23267457 allocation units available on disk.

Internal Info:
a0 8b 01 00 9d e3 00 00 3d 20 01 00 00 00 00 00 ........= ......
ab 0d 00 00 00 00 00 00 4b 06 00 00 00 00 00 00 ........K.......
4e cc b5 02 00 00 00 00 ae cd 48 2c 00 00 00 00 N.........H,....
16 3e c0 09 00 00 00 00 a8 1f 66 ca 02 00 00 00 .>........f.....
b0 5b fb 07 05 00 00 00 02 d8 3d 12 08 00 00 00 .[........=.....
99 9e 36 00 00 00 00 00 a0 39 07 00 b5 d1 00 00 ..6......9......
00 00 00 00 00 20 a6 c3 07 00 00 00 dc 11 00 00 ..... ..........

Windows has finished checking your disk.
Please wait while your computer restarts.
=======================================================

Seems once CHKDSK has corrected these types of errors, they just come back after using the computer for a day. Drive D: came up clean, but of course I have the 58 GB in 'bad sectors' that I can probably get back when I reformat the D: partition.

So what might be causing these unused index entries and unused security descriptors?

I also ran 4 different malware scanners while in Safe Mode and they came up with no malware detections.

 

[OVERKILL]

It is somewhat usual for the index entries to occur.

I would try deleting the D partition, re-creating it, formatting it, and then see where you stand.

BTW, I may have missed it, but what motherboard is this drive attached to?

 

[SuperBusa]

Originally Posted By: OVERK1LL
It is somewhat usual for the index entries to occur.

I would try deleting the D partition, re-creating it, formatting it, and then see where you stand.


Yes, that's my next step. Do you think I need to delete it or just reformat the already existing D: partition?

Originally Posted By: OVERK1LL
BTW, I may have missed it, but what motherboard is this drive attached to?


Not sure exactly what the motherboard is ... a Dell Dimension 4400 is the model of the computer. I looked in Control Panel > System > Hardware > Device Manager and didn't see any motherboard info, but did find:

"Intel 82801BA Bus Master IDE Controller"

 

[OVERKILL]

For fun, pull the side of the case off and check for any caps with the tops of them bulging. I am not aware of this model being prone to this failure, but it is always good to check when you have issues such as these.

I had a Gateway about a month ago that had shaky video. The video was on-board. Found that both caps for the RAM, and a couple for the Northbridge were swelled and had failed.

The machine ran fine otherwise.

Replaced those caps and the video issue was gone.

Not saying this IS your issue, because it probably isn't, but it is always something to check when you have a problem that, at first glance, doesn't make sense.

I would definitely delete the partition under Administrative Tools -> Computer Management in the Control Panel and re-create it.

 

[SuperBusa]

Originally Posted By: OVERK1LL
For fun, pull the side of the case off and check for any caps with the tops of them bulging.

Found that both caps for the RAM, and a couple for the Northbridge were swelled and had failed.

The machine ran fine otherwise.


"Caps" ... ? Not sure what those are exactly. If this was happening, I would of thought some of the hardware diagnostics would have failed (?).

OK, will delete the D: partition (it will probably then show up as "unallocated disk space", and then will recreate D: and format it.

This should have no effect on C: partition or the files on C: ... right ??

 

[OVERKILL]

Correct. No effect.

Caps are capacitors. They are on the motherboard. The tops of them should be FLAT. If they are swelled, or leaking fluid, they have gone bad.

 

[javacontour]

Originally Posted By: OVERK1LL
Correct. No effect.

Caps are capacitors. They are on the motherboard. The tops of them should be FLAT. If they are swelled, or leaking fluid, they have gone bad.


Really thinking this is not hardware since, if I understand correctly, that the C:\ and D:\ drives are simply partitions on the same physical disk.

C:\ is not having issues, but D:\ is.

If my understanding is correct, then things like cables and controllers are unlikely suspects.