Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 

Sign in to follow this  

Solved - Problem with Windows system files even after repair

Recommended Posts

Hi guys!

I have a Windows 7 computer that has problems with the system files....according to gparted in linux and that is never usually wrong...

The drive originally in the computer was in a bad way....but because the customer had a lot of programs installed I decided to try and clone it on to a new Samsung SSD Evo 850 250GB hard drive

Firstly I ran chkdsk  to see if I could get some order before cloning and defrag...

For this exercise I used Macrium reflect....Macrium reflect has a couple of functions...a direct clone or creating an image...

The clone failed but I could create an image and then copy that over to the SSD...

After the restart I found it was still sluggish, so I decided to run an "install repair"

When starting the Windows 7 Home Premium Sp1 it told me there could be a problem with a couple of programs like graphics driver so I removed them as suggested....

After running the "install and repair" I went about updating it to today's date....

I did a check with sfc /scannow just to check and that comes up clean...

I know this isn't a linux forum but I ran a Ubuntu Live cd to check the state of the partitions....

If anyone is used to using gparted a formating tool in linux - then they know if you get a yellow triangle by the C: partition there is something wrong some where....

If I look at the information tied to the yellow triangle  - it shows loads of sectors damaged just like it was on the old drive...

What I am wondering is there any other checks I can do that would resolve this without reinstalling the drive....?

I know there is no problem with the SSD but maybe someone knows where linux is reading info on the drive and attributing it with the same errors as the old sata drive?

Have we any Windows/Linux gurus here that can give me some help?






Edited by bookie32

Share this post

Link to post
Share on other sites

Well, with all due respect :). the procedure you followed doesn't make much sense :w00t::ph34r:.

When you are in cases such as this  one (or similar ones) like data recovery from a failing disk, the FIRST thing you do is to make a forensic sound image (or clone), using a "plain" tool that you already verified, you are fully familiar with and that is proved to be capable of doing that, NO if's, NO but's.

Then you make a SECOND image (or clone) and:

1) leave the original disk alone
2) leave the first image alone
3) you work on the seconf image ONLY

IF the procedures in #3 above do not give the wanted results, you start again from a newly made second image.

The fact that the clone failed (provided that you already verified that the tool you used normally allows to make a clone and that you are familiar with using it) should have told you something. :dubbio:

There is no way, with all the things you did to the poor "clone," including the exact way you imaged or cloned the original, that anyone can suggest you a "proper" procedure.

Since the original disk is seemingly healthy (I mean mechanically/at sector level) you can now make the forensic sound image (or clone) and start again, and avoid having the second image or clone, but you still need to restart from a copy of the original.

You don't and I mean you DON'T run a "repair install" before having verified that both the underlying media (the hard disk or SSD) and the filesystem are "healthy".

Gparted is an extremely good tool, but this does not mean that it can be trusted unconditionally, and of course "loads of sectors damaged just like it was on the old drive" doesn't actually mean anything.

Do the sectors belong to single files?

If yes to which files? (I mean documents, OS system files, program files or NTFS file system structure)

Basically with NTFS if the file system structure is damaged, more or less the ONLY chance is running CHKDSK, if it can repair the filesystem, good, if it cannot then you are on your own, example, JFYI:


and need to perform manual checks and analysis.




Share this post

Link to post
Share on other sites

Hi Jaclaz:D

I have run chkdisk on the ssd just to see if there was errors and it fixed some file but I am getting exactly the same in gparted...

GParted 0.25.0 --enable-libparted-dmraid --enable-online-resize

Libparted 3.2

Check and repair file system (ntfs) on /dev/sda2  00:00:00    ( ERROR )
calibrate /dev/sda2  00:00:00    ( SUCCESS )
path: /dev/sda2 (partition)
start: 821248
end: 345597951
size: 344776704 (164.40 GiB)
check file system on /dev/sda2 for errors and (if possible) fix them  00:00:00    ( ERROR )
ntfsresize -i -f -v /dev/sda2  00:00:00    ( ERROR )
ntfsresize v2015.3.14AR.1 (libntfs-3g)
Device name : /dev/sda2
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 176525668864 bytes (176526 MB)
Current device size: 176525672448 bytes (176526 MB)
Checking for bad sectors ...
Bad cluster: 0x75d7f0 - 0x75d7f0 (1)
Bad cluster: 0x75d8f5 - 0x75d8f5 (1)
Bad cluster: 0x75d9fb - 0x75d9fb (1)
Bad cluster: 0x75dc34 - 0x75dc34 (1)
Bad cluster: 0x75dd39 - 0x75dd39 (1)
Bad cluster: 0x75de3f - 0x75de3f (1)
Bad cluster: 0x7711f3 - 0x7711f3 (1)
Bad cluster: 0x7712f8 - 0x7712f8 (1)
Bad cluster: 0x771531 - 0x771531 (1)
Bad cluster: 0x771637 - 0x771637 (1)
Bad cluster: 0x77173c - 0x77173c (1)
Bad cluster: 0x771841 - 0x771841 (1)
Bad cluster: 0x771947 - 0x771947 (1)
Bad cluster: 0x771a4c - 0x771a4c (1)
Bad cluster: 0x771b51 - 0x771b51 (1)
Bad cluster: 0x771d8b - 0x771d8b (1)
Bad cluster: 0x771e90 - 0x771e90 (1)
Bad cluster: 0x771f95 - 0x771f95 (1)
Bad cluster: 0x77209b - 0x77209b (1)
Bad cluster: 0x7721a0 - 0x7721a0 (1)
Bad cluster: 0x7722a5 - 0x7722a5 (1)
Bad cluster: 0x7724df - 0x7724df (1)
Bad cluster: 0x7725e4 - 0x7725e4 (1)
Bad cluster: 0x7726e9 - 0x7726e9 (1)
Bad cluster: 0x7727ef - 0x7727ef (1)
Bad cluster: 0x7728f4 - 0x7728f4 (1)
Bad cluster: 0x7729f9 - 0x7729f9 (1)
Bad cluster: 0x772aff - 0x772aff (1)
Bad cluster: 0x772d38 - 0x772d38 (1)
Bad cluster: 0x772e3d - 0x772e3d (1)
Bad cluster: 0x772f43 - 0x772f43 (1)
Bad cluster: 0x773048 - 0x773048 (1)
Bad cluster: 0x77314d - 0x77314d (1)
Bad cluster: 0x773253 - 0x773253 (1)
Bad cluster: 0x77348c - 0x77348c (1)
Bad cluster: 0x773591 - 0x773591 (1)
Bad cluster: 0x773697 - 0x773697 (1)
Bad cluster: 0x77379c - 0x77379c (1)
Bad cluster: 0x7738a1 - 0x7738a1 (1)
Bad cluster: 0x7739a7 - 0x7739a7 (1)
Bad cluster: 0x773aac - 0x773aac (1)
Bad cluster: 0x773ce5 - 0x773ce5 (1)
Bad cluster: 0x773deb - 0x773deb (1)
Bad cluster: 0x773ef0 - 0x773ef0 (1)
Bad cluster: 0x773ff5 - 0x773ff5 (1)
Bad cluster: 0x7740fb - 0x7740fb (1)
Bad cluster: 0x774200 - 0x774200 (1)
Bad cluster: 0x774305 - 0x774305 (1)
Bad cluster: 0x77453f - 0x77453f (1)
Bad cluster: 0x774644 - 0x774644 (1)
Bad cluster: 0x774749 - 0x774749 (1)
Bad cluster: 0x77484f - 0x77484f (1)
Bad cluster: 0x774954 - 0x774954 (1)
Bad cluster: 0x774a59 - 0x774a59 (1)
Bad cluster: 0x774c93 - 0x774c93 (1)
Bad cluster: 0x774d98 - 0x774d98 (1)
Bad cluster: 0x774e9d - 0x774e9d (1)
Bad cluster: 0x774fa3 - 0x774fa3 (1)
Bad cluster: 0x7750a8 - 0x7750a8 (1)
Bad cluster: 0x7751ad - 0x7751ad (1)
Bad cluster: 0x7752b3 - 0x7752b3 (1)
Bad cluster: 0x7754ec - 0x7754ec (1)
Bad cluster: 0x7755f1 - 0x7755f1 (1)
Bad cluster: 0x7756f7 - 0x7756f7 (1)
Bad cluster: 0x7757fc - 0x7757fc (1)
Bad cluster: 0x775901 - 0x775901 (1)
Bad cluster: 0x775a07 - 0x775a07 (1)
Bad cluster: 0x775c40 - 0x775c40 (1)
Bad cluster: 0x775d45 - 0x775d45 (1)
Bad cluster: 0x775e4b - 0x775e4b (1)
Bad cluster: 0x775f50 - 0x775f50 (1)
Bad cluster: 0x776055 - 0x776055 (1)
Bad cluster: 0x77615b - 0x77615b (1)
Bad cluster: 0x776260 - 0x776260 (1)
Bad cluster: 0x776499 - 0x776499 (1)
Bad cluster: 0x77659f - 0x77659f (1)
Bad cluster: 0x7766a4 - 0x7766a4 (1)
Bad cluster: 0x7767a9 - 0x7767a9 (1)
ERROR: This software has detected that the disk has at least 78 bad sectors.
* WARNING: The disk has bad sector. This means physical damage on the disk *
* surface caused by deterioration, manufacturing faults or other reason. *
* The reliability of the disk may stay stable or degrade fast. We suggest *
* making a full backup urgently by running 'ntfsclone --rescue ...' then *
* run 'chkdsk /f /r' on Windows and rebooot it TWICE! Then you can resize *
* NTFS safely by additionally using the --bad-sectors option of ntfsresize.*

There isn't any problems with this disk....



Share this post

Link to post
Share on other sites

So in a nutshell gparted is telling you:
a. I cannot repair this NTFS filesystem (or any NTFS filesystem for that matters)
b. try using CHKDSK to repair it

which is exactly QED.

Now, there are three ways to run CHKDSK, and in these cases it needs to be run THREE times once in each mode, and - sometimes the whole set needs to be run again after a reboot.

This is my personal advice, it is good, sound, and has always worked since the dawn of NTFS:

1) the first time you ALWAYS run it without ANY switch
2) the second time you run it with the /F switch
3) the third time you run it with the /R switch

Have you done the above (exactly)?

Again, no ifs, no buts, and - just for the record - the gparted advice  is inaccurate (if you use the /R switch it implies the /F), BUT it is correct that in some cases you need to reboot for some changes to take effect and re-run the CHKDSK, more than that it (the advice fparted produced) does not apply to your case.

Now the good news, since Vista there is a new option for CHKDSK, the /b one:


which is what you want to try running, let us call it the 4th way :

4) the fourth time you run it with the /B switch





NTFS only: Clears the list of bad clusters on the volume and rescans all allocated and free clusters for errors. /bincludes the functionality of /r. Use this parameter after imaging a volume to a new hard disk drive.

In other words most probably the old disk had some clusters (not sectors) listed in $BadClus and this file was imaged to the new device, and now it needs to be "reset".

You can use ntfstruncate however:



  • Like 1
  • Upvote 2

Share this post

Link to post
Share on other sites

Hi jaclaz!

I appreciate what you are saying and no I haven't done chkdsk as you state but will do that now and keep your post as a guide in the future....;)

I always appreciate your help...it is sound and most often right!


Thank you!

Will post the results after testing....




Share this post

Link to post
Share on other sites

Hi jaclaz

Well, that did the trick...no warnings now in linux!

Thank you for your time!



Share this post

Link to post
Share on other sites

All is well that ends well :)


Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.