Hard drive error

[philo]

I'm working on a Win10 machine that occasionally crashes on startup with
the message: Windows has encountered an error.

If I run CHKDSK /F I see that CHKDSK on
Win10 givers no annunciation as it did with previous Windows
versions...all it does is say that the drive was repaired, then in
reboots, but it did not actually fix anything.


As a precaution I ran both a memory test and the mfg's full HD
diagnostic ...no errors found>

I then booted the machine from a Win7 live cd and ran CHKDSK /F and this
time I was able to now see what CHKDSK was doing.

Here is the message of note:


Index entries referring to file 777285 will not be validated because
this file contains too many file names.



I Googled this error and most of the forums I've seen advise running a
utility called diskedit.exe , then cite some complex instructions.

All the responses post back saying: Tried that but it didn't work.


Now I am stumped and would appreciate some help.

[Paul]

What is the physical health of the disk like ?

https://arstechnica.com/civis/viewtopic.php?f=17&t=68605

I would start with the nfi.exe utility. At least
it hasn't been "chased down and ruthlessly eliminated" :-)

https://web.archive.org/web/20070104083656if_/http://download.microsoft.com:80/download/win2000srv/utility/3.0/nt45/en-us/oem3sr2.zip

I cannot find a copy of diskedit.zip . It's been removed
from archive.org . As for the notion the file is in the
Win2K SP4 ISO, it must be well hidden, because I looked in
my copy and while I see utilities with diskXXXX names, there
is no diskedit.zip in there. Maybe it was some original or
beta version of the file that had it. I suppose the public
version "diskedit.zip" is diskedit.exe plus DLLs, and it
wasn't actually shipped as a ZIP. I still could not find
a diskedit.exe on the SP4 ISO.

The Google search seems suspiciously "lean".

*******

In nfi.exe output, normally each filenum, is followed by a path.

The path could be contained in one of the two $FILE_NAME entries.
nfi.exe does not show us both paths at the same time. It
should do this, but it does not.

File 59272
\Windows\Installer\$PatchCache$\Managed\68AB67CA330133017706CB5110E47A00\21.1.20135\acrotextextractor.exe
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 88751496-88751615 (0x54a3d88-0x54a3dff)

File 59273

Linux, if you use the "ls -i" option, shows inode numbers.

If two items reside in filenum 59272, then Linux should
list both of them, with the same "inode number". So maybe
you would see

inode = 59272 filename = dog.txt
...
inode = 59272 filename = cat.txt

That's because Linux stuffs the inode field in the stat()
info for an NTFS file, with the filenum number.

The problem with Linux is, the NTFS filesystem driver (there are
at least three of them), it has problems with Reparse Points, and
we don't know which file system driver does the very best job.
The default one, would cause "I/O Error" to be printed on the
screen, for any item which has a Reparse Point. Every "new compression"
file in the Windows directory, would throw an "I/O Error", when
in reality it is a "I do not know how to parse this information"
error. It is not a physical problem with the drive, like a CRC
error or something. The first time I saw those errors listed,
I was kinda freaking out :-)

The Paragon NTFS driver, is the latest on offer. A quick test
of it, found it to be defective and not ripe. You need a
very recent kernel (5.13, 5.15, it was some high number like that).

The objective of getting the Paragon driver, is just so it
does not spray the screen with error messages and not a lot
of help for you.

So if we saw this...

File 59272
<=== blank line for path
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 88751496-88751615 (0x54a3d88-0x54a3dff)

in principle, the file at one time had a path.

*******

The Search Indexer keeps the Windows.edb file. And that is a Jet Blue
database. And it has a neat little mechanism for compressing
path info for files. It uses simple integer numbers.

\Windows\Installer\$PatchCache$\Managed\68AB67CA330133017706CB5110E47A00\21.1.20135\acrotextextractor.exe
23 37 417 652 1058 2894 54678

There are two tables in Windows.edb, and you walk back and forth
between the two tables, until you rise up to the top of the
hierarchy. This is my report on the little project.

http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cpa7oma%2491q%241%40dont-email.me%3E

But given this secondary source of info (would require the user
to have properly set up Indexing Options... which never happens!),
how would you profit from that info ?

I don't know.

You still don't know what the "blank" item is. If you did not
have the "acrotextextractor.exe" tidbit, you could not walk the tree.

Unlike in my example, where I knew of an existing item, and
I was able to traverse the table dumps to get the info I wanted.

You can list every file contained in Windows.edb, if you have
the intestinal fortitude (just writing some code would do).

But if the indexer only indexed the users "Downloads" folder,
there will be little useful info in the Windows.edb file. And
that is the most likely outcome.

I do have a fully functional Windows Search on my Windows 7 machine,
but it took a lot of work, poking and prodding, to get it stable.
No ordinary end user will put up with the amount of aggravation
I went through to do that. The index seemed to "blow out" a couple
of times, and dump what it had done and started over again.

*******

Summary: diskedit.exe would be of little solace, if the root cause
of these errors is some "not logical" set of conditions.

Maybe CHKDSK would have orphaned these defective files...
if the media was good enough to accept writes.

Paul

[philo]

Thanks Paul, I will see what I can do with nfi.exe .
I ran the manufacturer's long test on the drive and it passed.


I think that what I'll do is just replace the drive and reload the OS
and run the machine for a while and see what happens.

[philo]

On 5/19/22 3:47 PM, philo wrote:
> I'm working on a Win10 machine that occasionally crashes on startup with
> the message: Windows has encountered an error.
>
> If I run CHKDSK /F I see that CHKDSK on
> Win10 givers no annunciation as it did with previous Windows
> versions...all it does is say that the drive was repaired, then in
> reboots, but it did not actually fix anything.
>
>
>

<snip>


Replaced the mechanical drive with an ssd and reloaded the OS.


Used the machine today with no problems.

It's just a backup machine but might as well keep it in as best
condition as possible.

[philo]

Now the the laptop is working better than ever with the SSD, figured I
can put the old drive in an enclosure.

From another Win10 machine, I ran CHKLDSK /F on the drive and not only
did it see MANY errors and correct them, I also got messages as to
exactly what was going on which is exactly as I would expect.


Now I am wondering why CHKDSK /F was not working originally/

[Paul]

It's possible the CHKDSK used is not working the same
as it used to.

Windows 10 (and possibly some earlier OSes) have "robust" NTFS.
This means there is a background scan being done for NTFS. I
suspect it is a background scan of "recently carried out operations",
rather than a thorough evaluation.

Then, if you request CHKDSK from Properties, can that be run
while the robust stuff runs in the background ? Dunno. Since
I've never seen any documentation for the robust NTFS feature,
I can't point you at a reference.

All I can tell you, is that Windows 7 remains the best place
to be doing a CHKDSK. For whatever that is worth. Windows 7
does not "understand" why there are Extended Attributes all
over the place on the NTFS you ask it to fix. But, all the
features are there to mechanically fix it. Even if it is
slow as molasses in springtime. Win7 CHKDSK will eventually
fix your file system.

And always do:

chkdsk /?

to make sure you aren't missing some of the newer repair flags.
On some occasion, I found a new option, and it actually helped me.

Paul

[philo]

Yes. There indeed were options I never heard about.

Anyway, the machine seems to be fine now and I will keep the old drive
for additional backups

[philo]

On 5/19/22 3:47 PM, philo wrote:

> I'm working on a Win10 machine that occasionally crashes on startup with
> the message: Windows has encountered an error.
>
> If I run CHKDSK /F I see that CHKDSK on
> Win10 givers no annunciation as it did with previous Windows
> versions...all it does is say that the drive was repaired, then in
> reboots, but it did not actually fix anything.
>
>
> As a precaution I ran both a memory test and the mfg's full HD
>

<snip>


Popped the drive into another machine and the performance is
terrible...so I'm not going to put it back into service.


Also: it was from a Lenovo laptop and the disk label said Windows SSD
even though it was a mechanical drive. My opinion of Lenovo is a bit
diminished now

[Paul]

My experience is, an HDTune abnormal read benchmark may make
an appearance, before the Reallocated raw data field goes off 0.

Things like SmartMonTools rely on the SMART for their determination
of "Healthy". And you as the user, can use things like HDTune
to determine "it is not Healthy".

In my case, it was a drive with an obvious 50GB-wide "bad spot" on
the disk, which was likely wear-related. (An OS used to sit there.)
HDTune would measure 5MB/sec to 10MB/sec or so, through that
region. The rest of the disk formed part of a more normal-looking
curve.

It's especially hard to get a "noise-free" environment for HDTune.
Win2K was my favorite for "noise-free" benching. It didn't have a
lot of scanning going on, in the background.

Gnome-disks can do a read-bench as an option, but you have to be
careful to not select the "write" option by accident. And the results
don't appear to be "smoothed" quite like HDTune. The thing is, the
caching on Linux is pretty hard to defeat, and there have been
programs that claim to defeat the cache while measuring, where
the cache schemes were still evident in the results.

If you want, you can use the Command Prompt in the Troubleshooting
section of a Windows installer DVD, and call HDTune from there.
As long as it's sitting on some storage you have access to. Typically,
32-bit installer DVDs have 32-bit install environments and are good
for running a 32-bit application like HDTune 255. Not every thing
you would like to run, works that way. But a few things do. And the
32-bit DVD is the place to test them. Since Windows 11 has no 32-bit
option, you won't be using a Windows 11 DVD for this purpose. But
earlier versions would be fine.

The theory being, a WinPE environment is less likely to have
background noise while it is running. The OS is loaded into X:
and X: is a RAMDrive provided by Microsoft. This also implies
the DVD can be popped out, once the Command Prompt window is open
(in theory at least, YMMV...).

Paul

[philo]

What I finally did was pop the drive in a spare computer I had in my
workshop, format it and perform a fresh install of Win10.

The machine is a single core 3ghz cpu with 4 megs of ram.

It's actually running ok.

Sooner or later a friend will need a free machine, so I'll have one all
ready. I used to keep at least six spares