Identifying damaged or corrupted files

JD, SFC will do this provided that the SFC database is reasonably current. Unfortunately MS makes no mention of this utility to the user and that it should be run once in a while to keep the database current, neverhteless, it will work. Here's the recommended procedure, but read it carefully, especially with respect to the selection of files to be examined. Pay close attention to file versions more than dates.

If you have recovered and copied "all" of the files, then this should resolve it for you.

Dennis

Have your Windows 98 CD Rom disk handy.

1.      Reboot the system and either hold the Ctrl key down right after memory post or when you see the “Starting Windows…” dialogue, touch the F8 key.
2.      Choose #5 Command (MSDOS)  Prompt only.
3.      At the dos prompt, change directories to X:\Windows\Command, with “X” being the directory where Windows is installed.
4.      Now type SCANREG/FIX <enter>
5.      Follow the dialogue and let Scanreg review your registry and make any necessary repairs.
6.      When Scanreg is done, reboot into Windows.

NEXT:

1.      Insert your Windows 98 CD Rom disk into the drive.
2.      Click Start, Run and type  SFC <OK>
3.      This will start the System File Checker.
4.      Click on the settings button and select “Check for changed and deleted files” and click OK to start.
5.      Replace any files that are detected as bad or corrupt. Also watch the file dates carefully and always try and replace older files (pre-May 1998) with newer files, and most important, always use the latest version numbers for all files. SFC will copy the old file to X:\Windows\Sysbckup in case you need it back.
6.      When SFC is done, reboot the system and note the performance.

I am rejecting dew_associates answer since it implies SFC will only detect corrupted files that could be restored from the Windows 98 CD, but my question was to find a means to check executable files from third-party applications as well. If dew_associates is indeed correct in their explanation, that SFC will find errors in third-party app files as well, I have increased the points from 50 to 100 for them to cover the "insult", otherwise, I would seek an alternate answer to the question.

From what I read of dew_associates answer it is right.

His procedure will cover all files on your hard drive.

Will SFC also check for other corrupted files such as BMP, JPG, WAV, etc. that are not important to the opperating system, and applications?  (I think this is allong the lines of what jdhelms is asking.)

Take a look on the SuRest utility at http://mivlad.virtualave.net

ftp://ftp.datafellows.com/anti-virus/free

download fp306c.zip

yes, it's virus software but it also will check all .exe, .com, .bat, etc files for corruption.  the other day, it found for me that my command.com was corrupted.  To test wether it was right, I copied a command.com to command.new on my C: and rebooted.  guess what.  no boot.  renamed command.new to command.com using a bootdisk and it booted fine.

you'll need winzip
www.winzip.com

jdhelms,

Try this old trick I learned back in the good ol' DOS days:

Start/Find/Files or Folders and search for "*.*" on C: including subfolders, and containing the text "lasjkdflkjasdf" or whatever.  This will force Windows to open every file and if any has been corrupted, a file error will occur for that file(correct me if I'm wrong, but I don't think Scandisk is as thorough - it will only find bad hardware and FAT structure problems).

Of course, Find will only search the first 10,000 files on your hard disk, but that isn't a problem for most people...

Jon

I suspect from the comments I am seeing I should clarify my question.

I am not so much trying to find out if files are READABLE, as I suspect they all are. I'm trying to be certain that EXECUTABLES in particular are OK; that they weren't copied from incorrect sectors, possibly glueing parts of an *.exe file with a *.txt file, or whatever. I should have mentioned my failing hard drive had a FAT error before I did my salvage operation. That's what makes me more concerned about the integrity of my files.

I remember seeing some information regarding checking files by their embedded CRC records, but perhaps not all files contain an internal reference, and cannot be verified. I would, however, like help in finding a method to check those files that do have some internal record that can be checked by external means. I am also more concerned about non-Windows OS files; those from third-party apps.

Thanks!

JD, indeed SFC will check the files of everything that's is present on the drive. As an example, executibles, DLL's etc all have checsum codes. These are checked against the physical file. SFC is accurate enough that it has caught Microsoft's developers where the checksum was not updated even though the file code had been, and SFC showed it as corrupt even though it wasn't. It does work JD!

I think what JD is getting at is that SFC is only for Microsoft Windows or Microsoft Products.  There is a DOS program that came with DOS 6.xx and it
comes with Windows 2000, it's called FC (file compare).  You simply run it like this: "fc C:\windows\*.* D:\windows\*.*".  You could can pipe the results it finds out to a file using > somefile or
the printer.  It will report all CRC differences.  Unforuntately, it will not tranverse subdirectories, so doing "fc C:\*.* D:\*.*" will only do CRC compares of the files in the respective root directories.

Also, might want to try ctree180.zip, fcmp200.zip or ufc10.zip from http://ftp.net.uni-c.dk/simtel.net/msdos/fileutil-pre.html

Wrong Aleiness, SFC will work with any MS product as well as any third party product ported to Windows 98/98SE. It will not examine dos files unless there is a reliance on them by the original Windows installation.

From http://support.microsoft.com/support/kb/articles/q222/4/71.asp

Sfc.exe - Scans all protected system files and replaces incorrect versions with correct Microsoft versions

I see nothing about third party products, just that it checks Microsoft stuff

you can add and remove any file type you want to from sfc

by default it includes *.386, *.com, *.dll, *.drv, *.exe, *.mpd, *.ocx, *.scr, *.sys, and *.vxd

these are not microsoft specific

you can also designate which folders are examined

Well, the thing is, it makes sense that SFC only checks MS products.  Think about it.  MS knows what the CRC values of its files are suppose to be.  That's what SFC checks against. Unless you are saying that SFC has a plug-in feature where you can download a SFC type list from a non-MS company and plug it into SFC to check non-MS applications for integrity.

You've learned well grasshopper!

check sums are check sums, you don't need a database

(if 1+1=2)=known good

aleinss, what's it going to take, a 2x4, it check the values in the file signature against the file itself. Not a difficult concept here.

Blocks of wood have nothing to do with CRC values <BG>. You guys might be right, but I'm not convinced when I see statements like:

The SFC baseline for the retail version of Windows 98 => comes populated with Windows 98 file information <=. The baseline is backed up and selectively updated during Windows 98 Setup. Running SFC for the first time establishes a profile of the system.
(http://support.microsoft.com/support/kb/articles/Q188/1/86.asp).

This seems to suggest CRC lookup is done via a table not from the file. I don't see how you can compute a CRC check on a file without a known good value for that particular file.  I'm not a cyprtologist (sp), but why not clone the CRC value, modify the file and patch the CRC value back it?  A CRC value is simply a polynominal value made when you pass the file through the algorithm.  If the file never changes, the CRC value should say the same.  If it's not the same as the published file, it has be tampered with.

For example, let's say I have a file called FOO.BAR.  The valid CRC value for this file is CA54643.  I embed this into the file.  My computer catchs a virus, the virus in turn clones the CRC value, modifies the file and embeds the orginial CRC value back into the file.  You "CRC value" is now useless, because it's going to give the value it did before the virus.

I must be missing something big here.

I am going to credit dew_associates for their efforts. I wish I could "divide the spoils" amongst all who replied, but, alas, I am a first-timer here and not too sure of the way this system works. I hope I don't "kill the thread" after awarding points, as it appears others have an interest in continuing this subject as well.

Perhaps there is no "magic bullet" answer to my question. I'm sure the first time I try to run a corrupted executable file, I'll know it! <G>.

Thanks, guys!

Thanks for the help.

Hi JD,

By accepting an answer, the thread remains open to all who have participated. All others pay 10% of the posted point value, in this case 10 points.

When accepting answers, there is a method that can be followed. Normally the first complete comment or proposed answer that resolves the issue or provides the requested information is the answer to accept. If the issue is extremely complex and several participated in stages, we can request that E&E handle a points split.

As for this issue, indeed there is no magic bullet as the issue is extremely wide and varied. SFC, generally, will examine all files across the system provided that you maintain its database from month to month to keep it accurate, which leads back to my statements above. If the first time you run SFC is when there is a problem and Win98 has been loaded for a year or more, doing so can be quite confusing as there are thousands of files on the system beyond those developed by the initial baseline. There is also another drawback to this otherwise fine tool, in that while it will detect corruption in files from third party applications, it is unable to tell you the exact application where that file originated. The reason why it can't is that the file may be unique to that application or merely just a shared file that is used by many applications and is provided to developers by Microsoft etc.