Error 0x80070571: The disk structure is corrupted and unreadable ?

When I try to clean up my C:\Users\[userID]\AppData\Local\Temp
directory, I keep getting "Error 0x80070571: The disk structure is
corrupted and unreadable".

Sounds self-explanatory, but my system seems to be running OK.

This is post-reimaging and the System drive is an SDD.

ChkDsk C: was not happy:
------------------------------------------------------------
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Batchkdsk c:
The type of the file system is NTFS.
The volume is in use by another process. Chkdsk
might report errors when no corruption is present.
Volume label is System.

WARNING! F parameter not specified.
Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...
1 percent complete. (16743 of 167424 file records processed)
Attribute list entry with type code 128 in file 23196 is corrupt.
Deleted corrupt attribute list entry
with type code 128 in file 23196.
Attribute record (128, "") from file record segment 61902
is corrupt.
Attribute record (128, "") from file record segment 66570
is corrupt.
Attribute record (128, "") from file record segment 80173
is corrupt.
167424 file records processed.
File verification completed.
File record segment 61902 is an orphan.
File record segment 66570 is an orphan.
File record segment 80173 is an orphan.
967 large file records processed.

Errors found. CHKDSK cannot continue in read-only mode.
------------------------------------------------------------

Am I in the market for a new SDD?

Before I go back and try ChkDsk C: /F...

Any thoughts?
--
Pete Cresswell

(PeteCresswell) wrote:
When I try to clean up my C:\Users\[userID]\AppData\Local\Temp
directory, I keep getting "Error 0x80070571: The disk structure is
corrupted and unreadable".

Sounds self-explanatory, but my system seems to be running OK.

This is post-reimaging and the System drive is an SDD.

ChkDsk C: was not happy:
------------------------------------------------------------
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Batchkdsk c:
The type of the file system is NTFS.
The volume is in use by another process. Chkdsk
might report errors when no corruption is present.
Volume label is System.

WARNING! F parameter not specified.
Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...
1 percent complete. (16743 of 167424 file records processed)
Attribute list entry with type code 128 in file 23196 is corrupt.
Deleted corrupt attribute list entry
with type code 128 in file 23196.
Attribute record (128, "") from file record segment 61902
is corrupt.
Attribute record (128, "") from file record segment 66570
is corrupt.
Attribute record (128, "") from file record segment 80173
is corrupt.
167424 file records processed.
File verification completed.
File record segment 61902 is an orphan.
File record segment 66570 is an orphan.
File record segment 80173 is an orphan.
967 large file records processed.

Errors found. CHKDSK cannot continue in read-only mode.
------------------------------------------------------------

Am I in the market for a new SDD?

Before I go back and try ChkDsk C: /F...

Any thoughts?

What's your backup situation like ?

Don't let CHKDSK go ripping through there,
because CHKDSK can make minor errors better,
but it can also make a major mess.

To back up a corrupted drive, you need a
sector-by-sector method of some sort. The Acronis manual
mentions such a thing. The reason a sector-by-sector
method is needed, is a lot of backup softwares, they
do a "consistency" test as a step just before the backup.
And in your case, the consistency test is going to fail,
and the backup will stop dead. And then you get no backup.
Whereas dumb programs like dd or ddrescue, they don't
care about consistency, and they will backup up or
clone, anything.

http://www.chrysocome.net/dd

http://www.chrysocome.net/downloads/dd-0.6beta3.zip

As long as you have some means to restore the data,
then you can be as careless as you want with the
attempted recovery procedures. All I'm trying to
encourage, is having a "Plan B" if things get worse.

A couple of people report needing four CHKDSK
runs to clear a problem like that.

You can run CHKDSK from the recovery console, by say,
booting your Win7 installer DVD, and getting to
the recovery console that way.

"Command Prompt", at the bottom...

http://fixexe.com/pictures/Recovery-Console.png

Paul

Per Paul:
What's your backup situation like ?

Don't let CHKDSK go ripping through there,
because CHKDSK can make minor errors better,
but it can also make a major mess.

To back up a corrupted drive, you need a
sector-by-sector method of some sort. The Acronis manual
mentions such a thing. The reason a sector-by-sector
method is needed, is a lot of backup softwares, they
do a "consistency" test as a step just before the backup.
And in your case, the consistency test is going to fail,
and the backup will stop dead. And then you get no backup.
Whereas dumb programs like dd or ddrescue, they don't
care about consistency, and they will backup up or
clone, anything.

http://www.chrysocome.net/dd

http://www.chrysocome.net/downloads/dd-0.6beta3.zip

As long as you have some means to restore the data,
then you can be as careless as you want with the
attempted recovery procedures. All I'm trying to
encourage, is having a "Plan B" if things get worse.

A couple of people report needing four CHKDSK
runs to clear a problem like that.

I went ahead with CHKDSK /F and things *seem* to be ok now - at least
the sys seems tb running normally and revisiting CHKDSK C: gives no
errors.

I have moved from a file-oriented backup utility to Macrium for my data
backups.

For System backups/restores I use something called StorageCraft
ShadowProtect and only back up "Good" systems.

So if a data partition gets wacked, I restore via file copies from
Macrium's virtual drive. If the System goes South I restore from my
last "Good" system backup.

I guess the jury is still out as to whether the problem was:

- Inherent in the SDD's hardware

- Introduced by a somehow-flawed re-imaging

- Caused by re-imaging with an image that had the problem already

Right now, I am making another image of the fixed-up system - hoping
that I am not violating my "Only 'Good' Systems Get Imaged" rule.
--
Pete Cresswell