Re: Hard drive error

On 5/19/22 6:38 PM, Paul wrote:
> On 5/19/2022 4: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 
>> 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.
> 
> 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
> 
> 
> 

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.