Jump to content


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.

Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.


XP File Metadata problem

  • Please log in to reply
1 reply to this topic

#1 cheebie


  • Members
  • 4 posts
  • Local time:05:38 PM

Posted 08 September 2013 - 09:27 PM

Hi Bleepers!


(Is that the correct epithet??)  :devil: 


First post for me on bleepingcomputer.


My poor computer is in a precarious state at the moment. I have studied up a bit on the current problem (including the sticky at the top of this forum.) I would just like to check in with the experts here and see if they agree with my assessment of what's going on, BEFORE I proceed with a fix that might not be appropriate (let alone successful.) I think I'm at a point that a misstep could leave me with a machine for which the only recourse is reformatting.


I apologize that this is a lot of information (maybe too much...) It's just that it's hard for ME to know what is and is not relevant to my current situation.


My "old" computer is a Toshiba Satellite something, circa 2004. It has a single processor, half a gig of RAM, and a 90 Gig EIDE drive. It runs Win XP, SP 3. So even on a GOOD day, its performance is no longer very fast (all the software has gotten more complex, while my hardware has stayed the same.) I do have a nice nifty new computer (quad-core I7, yum! Win 8, yuccckkk...), and I've just been waiting for the right opportunity to migrate things over. (Spoiler alert: I _do_ have a complete Windows backup from 8/8, which I did shortly after resolving the malware problem described below. However, I think there would be some benefits for me from actually _migrating_ (e.g. Win 8 Easy Transfer), which would require the Old computer to be working.)


However, about a month or so ago I noticed that Old Computer was behaving strangely: instances of iexplore.exe were grabbing up to 100% of the CPU time. I recognized this as Malware activity, most likely Rootkit (and in fact, it turned out to be ZeroAccess.) As is typical, I used a series of applications to try to wipe out this malware. I think I was pretty successful (the browser CPU-hogging was greatly reduced), but to the best of my knowledge there is no application that can say, "yes, you got it all." Additionally, it's my understanding (having gone through this with my WIFE's computer at the beginning of August!!) that even if you "get" all of the malware, it frequently "swiss-cheeses" various System files to the point that you have no other choice than to reformat the disk and just start over.


OK, so fast-forward to Monday August 28: I was working on cleaning out some of the old applications (through Windows' "Add or Remove Programs" facility) in order to get the machine ready for a (hopefully) nice, clean migration. My main AntiMalware program for this computer had been Microsoft Security Essentials (just like my wife's old computer!). At the recommendation of one of the "helpers" from the MalwareBytes Forum, I had also purchased a license for MalwareBytes Anti-Malware Pro (hereinafter referred to as "MBAM") which would allow me to run Malwarebytes' various "active" antimalware products as ongoing processes. Apparently, MSE and MBAM don't play well with each other (even though I had been told that they _would_), because my machine was slowing to a CRAWL. I decided to turn off MBAM's active features; and just after I did that, my computer crashed! (Might have been related, or just an accident waiting to happen. )


As I tried to get my computer booting again, it was taking a VERY long time to go through the Windows Boot screens. I was actually able to get it to boot to Windows a couple times; but it usually crashed shortly thereafter. On several occasions, I got error messages stating that this file was corrupted:




I knew that this referred to the Registry Hive file called "System" (it does not have a tail, and is typically not visible to the User.) At one point, I was able to get Windows to load, ran ERUNTgui, and (theoretically) restored the last Reg files, which were backed up on 8/8/2013 (when I ran the Windows Backup on this machine.) However, this did NOT fix the problems! (And I think I know why...)


Some time after I did the ERUNT restore, I started getting the following error message:

"Windows could not start because the following file is missing or corrupted: <Windows Root>\system32\hal.dll"


I was able to boot from a CD (BartPE), and copy a reasonably-new version of HAL.dll to the appropriate directory; but it made no difference whatsoever. I began to understand that possibly HAL.dll wasn't corrupted at all, but that maybe one of the Reg files (or some other System file) was so damaged that it couldn't even _load_ HAL.dll.


I had planned to go through a complicated procedure to restore a set of Reg files from a previous System Restore point, and then copy over ALL of the .dlls from my last backup (8/8/2013.) However, before I did that, I decided to boot from BartPE again, and try to grab a copy of all my documents that I had modified since my last backup (copying them to a USB stick.) This worked pretty well, except that one file came back with a CRC error and said that it couldn't be copied.


For some reason, this made the light bulb come on in my head that maybe the disk ITSELF was having problems, and needed a good flogging by SpinRite (www.spinrite.com). I _really_ love this utility! In case you're not familiar with it: it can boot from a CD ("FreeDOS"), and it is written in Assembler (which makes it VERY fast and efficient.) It works at the _hardware_ level of any hard drive; so it doesn't CARE what operating system you might have installed! It reads and safely writes sectors repeatedly, recovers data from bad sectors as much as possible, and marks the sectors bad if they are not recoverable. It's my understanding that SpinRite obviates the need for trying to obtain a disk-specific utility from the disk's manufacturer, since SpinRite reads the info it needs directly from the drive's firmware (although SpinRite does not get involved in reformatting or repartitioning the disk; you might still need a utility from the disk's manufacturer for THAT sort of thing.) It's not freeware; it's around $40, but WELL worth it for me! It has rescued me from MANY gruesome drive situations.


I wound up having to run SpinRite in a couple passes; but ultimately, it found (and did its best to recover) SEVERAL bad sectors!! (The manufacturer's Support person was very helpful. Thanks, Greg!) I have no idea how long these bad sectors have been present. I _don't_ attribute them to the malware infection, as I'm not aware of any malware (yet) that can do PHYSICAL damage to a disk. I think that these bad sectors were just compounding all the other problems.


So after SpinRite had completed, I had hoped that maybe some of the corrupted-file issues would go away. No such luck. Same HAL problem.

I then did a little investigation of the file system itself. I loaded BartPE again, and drilled down to C:\WINDOWS\SYSTEM32 (using Bart's version of Windows Explorer, the A43 File Management Utility.) To my surprise, it only listed a couple dozen files in System32! And HAL.dll was NOT one of them!


So I went out to a command prompt (Run|cmd). I navigated to C:\WINDOWS\SYSTEM32, and did a "dir" command. I got back the same list of files as was displayed in A43!


I then tried another command: "dir hal.dll". Poof! There it was. I tried "ren hal.dll hal.corrupt". That worked, too. I copied in a version of HAL.dll from my backup. It appeared when I did a "dir hal.dll"; however, the new HAL.dll still did not show up when I tried to do a "dir" on the whole SYSTEM32 directory.


As a final check, I booted the machine into Recovery Console (which I had fortunately installed on this machine prior to the string of problems.) When I navigated to C:\WINDOWS\SYSTEM32 and did a "dir", I got only the same short list of files, and an error at the end: "An error occurred during directory enumeration".


By this time, I had figured out that I had a problem with the file system. Since SpinRite did not address file system issues, I decided to run CHKDSK /r from the Recovery Console. Its results were not very good, either:

Microsoft Windows XP™ Recovery Console.


The Recovery Console provides system repair and recovery functionality.


Type EXIT to quit the Recovery Console and restart the computer.


C:\>chkdsk /r

Volume created 03/12/06 12:50a

The volume Serial Number is ac04-ac5f

CHKDSK is checking the volume...

CHKDSK is performing additional checking or recovery...

CHKDSK is performing additional checking or recovery...

CHKDSK is performing additional checking or recovery...

25% completed.

The volume appears to contain one or more unrecoverable problems.

97426160 kilobytes total disk space.

30043700 kilobytes are available.


4096 bytes in each allocation unit.

24356540 total allocation units on disk.

7510925 allocation units available on disk.




So I knew that I had a problem with the file system's metadata; specifically, the "Directory Tables" (hope I'm using the right term here.) In the Good Ole Days, this would have been the File Allocation Table, or FAT. But with NTFS (and filenames of up to 260 characters in length), things are quite a bit more complicated. The most I could figure out is that all the info about files, filenames and directories is stored in a folder called "System Volume Information", which is by default kept hidden from the average user. I have also heard the term "Master File Table" thrown around. However, I'm getting in over my head here!


I have no doubt that the corruption to the file system metadata occurred as a result of the failed sectors discovered by SpinRite. And even though SpinRite did its best to recover the data from those damaged sectors, even _they_ say there is no guarantee. I am satisfied that the disk is _currently_ in stable condition (after the scrubbing by SpinRite); long-term, I do not trust the disk and will be getting rid of it (and the computer), once I have migrated over to the new machine.


My further research in this new direction disclosed an article by Fred Langa ("Langa Letter"). Fred is someone I've watched over the course of several years. His advice generally seems to be good, and always based on sound technological information. His article here:




...even describes him doing what _I_ did (trying unsuccessfully to copy a fresh version of HAL.dll onto the affected disk)! However, the fixes he recommends (both in this article, and in related ones in the series) discuss using things like the "Bootcfg /Rebuild" and "Fixboot" commands from within the Windows Recovery Console. All these things seem to be dealing with the _BOOT_ part of the XP system. From my own explorations, I don't think the problems _are_ in the Boot stuff or MBR; I think they're in the file metadata!


Many "expert sources" seem to be "doom-and-gloom": do some tricks to back up whatever data you can, and then reformat the drive. I know this is an option, and it may end up being the only one.


There was a ray of hope in a Microsoft Technet article:




...however, the article seems to be mainly referring to Windows 2000! Nevertheless, they say some interesting things about XP:

"This problem occurs because the NTFS volume has an invalid or damaged record in either the $UsnJrnl file or the $LogFile file. Both of these files are internal files that are used only by NTFS; Chkdsk does not check the integrity of these two files. Chkdsk ensures only that the Master File Table (MFT) has entries for these files and that the entries are valid entries."

"Method 1

Use the Microsoft Windows XP or the Microsoft Windows Server 2003 Recovery Console to repair the $UsnJrnl file. Windows XP and Windows Server 2003 contain changes to Ntfs.sys that ignore the damaged entries in the $UsnJrnl file and automatically mount and correct damaged data stream files during a mount."


So I am hopeful that there is something out there that can repair or rebuild the necessary files (MFT?) without excessive pain. I could continue trying to Google this for the next several days (!), but I thought it might be appropriate to see if someone here had the expertise to know how to handle this problem with sharper tools than a reformat.



If it turns out that there _is_ no such easy repair available, I do realize that the best thing I could do would be to try to copy all the files off the old computer that were created or modified after 8/8/2013 (the date of the backup.) I know there used to be some pretty simple utilities (maybe even command-line) that would search the entire disk, and locate all files which matched certain criteria (like size or date.) Can anyone recommend such a utility that i might be able to either (a) burn onto a BartPE CD or ( B) run from a USB stick? (I also realize that if the file metadata is damaged, many such utilities would not be able to find the requisite files!)


Thanks bunches,







BC AdBot (Login to Remove)


#2 hamluis



  • Moderator
  • 55,405 posts
  • Gender:Male
  • Location:Killeen, TX
  • Local time:08:38 PM

Posted 09 September 2013 - 05:39 AM



Corrupted Registry, Config.sys Missing or Corrupt - http://support.microsoft.com/kb/307545


Corrupted Registry, AA Method - http://www.bleepingcomputer.com/forums/topic441257.html



0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users