Boot failure on XP, various errors, missing hal.dll etc...

OK here is my boot.ini from a backup, I'm pretty sure it is the same as the one on the problem drive. In fact it was copied form there.



[boot loader]
timeout=15
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Home Edition" /fastdetect /NoExecute=OptOut /usepmtimer
C:\CMDCONS\BOOTSECT.DAT="Microsoft Windows Recovery Console" /cmdcons
c:\wubildr.mbr="Ubuntu"


now, there used to be a wubi on my computer at one point, but it got deleted,
but the entry has always remained in the boot.ini as it has been copied each time I clone the drive to up grade, hence there have always been the following
two files in the root folder.

wubildr.mbr
wubildr

However when I connected the drive in question in a USB drive to this machine
I saw very little apart from those two files and a folder, there may have been another file as well I am not sure and I can't remember the folder name but there was nothing in it as I recall.

So that was pretty weird as when I connect that drive to the linux machine I
see the full C: drive I am familiar with, that two should contain wubildr files,
I didn't bother looking because I know they will be there, I am 99% sure they would be but they would be the old files.

Also I used another DVD disc utility to look at the drive and I saw the c: and d: partitions I am familiar with. (d: does not show up under linux mint).

The d: partition is something created by HP as a recovery partition, which is different to the windows restore I think, I always got confused by the two
as they perform the same function essentially, ie recover a bad system.

I am pretty sure that is way only after I tried the HP recovery process that
I started getting this blue screen missing or corrupt hal.dll error, before that
it was different, it used to appear to do something before failing, the screen would go dark for a while and then it would crash.

So it seems the HP recovery screwed things up even more, what ever it did.

What confuse me is the two lines in the boot.ini file ie:-

multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Home Edition" /fastdetect /NoExecute=OptOut /usepmtimer

C:\CMDCONS\BOOTSECT.DAT="Microsoft Windows Recovery Console" /cmdcons

Well OK it might help to look at the the third line which is never use ie
c:\wubildr.mbr="Ubuntu"

now wubildr.mbr must tell the system what to and must bootsect.dat
but ther first line just seems to point to the windows folder, ie

multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Home Edition" /fastdetect /NoExecute=OptOut /usepmtimer

so which file does it look at?


I'm basically trying to find the starting point.

 

OK what I am thinking of doing is looking at the files modified at the timeof the problems, which is the 20th 21st of this month, I may have run the hp recovery a little after that, but it might be interesting to see whta has change, I am assuming the dates will have change if something was modified, might not be true if it was replaced.

I can see in /windows that system.ini and win.ini were changed around than.
as did bootstat.dat and bthservsdp.dat plus some log files, nothing has changed after that.

I would like to look at the files but kaspersky is running and although I can see the files, there does not see to be a way to view the contents.

I will have a look for other system type files.

 

Looking at my backup I too here is the bootex file, it shows the chkdsk run I believe, never worked after that!!



Checking file system on C:
The type of the file system is NTFS.
Volume label is HP_PAVILION.


One of your disks needs to be checked for consistency. You
may cancel the disk check, but it is strongly recommended
that you continue.
Windows will now check the disk.
The object id index entry in file 0x8146 points to file 0x3e5
but the file has no object id in it.
Deleting an index entry from index $O of file 33094.
The object id in file 0x187a does not appear in the object
id index in file 0x8146.
Inserting an index entry into index $O of file 33094.
Index entry A0065366.cfg of index $I30 in file 0x9f9a points to unused file 0xe023.
Deleting index entry A0065366.cfg in index $I30 of file 40858.
Cleaning up minor inconsistencies on the drive.
Cleaning up 7210 unused index entries from index $SII of file 0x9.
Insufficient disk space to correct errors
in index $SII of file 9.
Cleaning up 7210 unused index entries from index $SDH of file 0x9.
Cleaning up 7210 unused security descriptors.
CHKDSK is verifying Usn Journal...
The remaining of an USN page at offset 0x3c2893338 in file 0x7370
should be filled with zeros.
The USN Journal entry at offset 0x3c2894000 and length 0x5604c394 crosses
the page boundary.
Repairing Usn Journal file record segment.
Usn Journal verification completed.
CHKDSK discovered free space marked as allocated in the
master file table (MFT) bitmap.
CHKDSK discovered free space marked as allocated in the volume bitmap.
Windows found problems with the file system that could not be corrected.

482078516 KB total disk space.
332427032 KB in 343177 files.
314620 KB in 27488 indexes.
0 KB in bad sectors.
1142388 KB in use by the system.
65536 KB occupied by the log file.
148194476 KB available on disk.

4096 bytes in each allocation unit.
120519629 total allocation units on disk.
37048619 allocation units available on disk.

Internal Info:
60 81 0b 00 f3 a7 05 00 14 5d 09 00 00 00 00 00 `........]......
2d 45 03 00 02 00 00 00 fc 23 00 00 00 00 00 00 -E.......#......
70 d5 a2 3a 00 00 00 00 b6 3e 53 55 0d 00 00 00 p..:.....>SU....
12 14 c9 05 01 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 84 a9 7d b9 0e 00 00 00 ..........}.....
99 9e 36 00 00 00 00 00 80 35 08 00 89 3c 05 00 ..6......5...<..
00 00 00 00 00 60 bc 41 4f 00 00 00 60 6b 00 00 .....`.AO...`k..

Windows has finished checking your disk.
Please wait while your computer restarts.

 

OK I have gone back to the 250 gig drive which does actually boot up and run windows of a sort, I get a different windows and it seem to think I am a new user every time, put me in a temporary desktop I think.

I mnot sure if it save data to the drive but I have written a test file I will see
if it is there when I reboot.

Running an AVG scan on it at the moment.

This looks to be the best disk to work with at the moment.

I mean it will actually boot into windows, although it did say drive failure imminent earlier, but I just turn the dick upside down and carried on!!

 

You can run this. This gives disk health info. See the "Health tab":

http://www.hdtune.com/files/hdtune_255.exe

The ones marked in red boxes are the important ones.
I drew the red boxes around the ones I think are important.
The yellow marks here are bogus. Both of my important
indicators are zero, so I'm good at the moment.

http://imageshack.us/a/img10/2134/cffn.gif

When the disk has accumulated errors, you see this. These
three lines were collected over a period of several days,
and show the disk getting worse and worse. It's at 98% health,
and could get much worse, but the fact it's going downhill,
means it is time to replace it. The disk that replaced
it has the top line displayed right now (A-OK).

Current Worst Threshold Data Status
Reallocated Sector Count 100 100 36 0 OK <--- This is OK
Reallocated Sector Count 100 100 36 57 OK
Reallocated Sector Count 98 98 36 104 OK <--- Going downhill

There is nothing that says that scale is linear. Disk death could
be any time. Or data loss from the "bad patch" could happen too.
Once it comes off the rails, buy another...

*******

With regard to the hal.dll missing error, I was able
to reproduce that, by renaming wubildr.mbr and selecting
"Ubuntu" when the Windows bootloader comes up. I think what
happens here, is the C:\wubildr program starts to run, can't
find the wubildr.mbr, and tries to run Windows from inside
the virtual Linux disk. Or something like that.

http://imageshack.us/a/img845/7238/c6c.gif

As I still haven't managed to find definitive details
on how the WUBI loader stuff works, I can't really comment
further on it. I get the impression it isn't triggered
unless you select "Ubuntu" from the boot menu. As long
as you select the Windows entry in the Windows boot loader,
the WUBI stuff should not do anything. Neither should the
contents of C:\ubuntu (which holds two large partition files).
It's when you "leave half of WUBI in place", then select Ubuntu
from the boot menu, that it makes a mess.

Also, when I booted into Ubuntu in my virtual setup, I could *not*
see the contents of the Windows C: partition. As suspected, the
Windows partition holding the large Linux partition files, would
not normally be visible while those files are being loopback mounted.
I have other environments here with loopback mounts, and you generally
can't look inside that partition while they're being used.

Paul

 

Thanks, well I am very confused about a lot of things at the moment,
I have been running fairly smoothy disc error wise on the 250gb drive
at the moment, I turned it upside down and it seems to like it that way.

But the software side of it is another kettle of fish, I can't seem to get
my old desk top back, it's there but when I log in I am put in a kind of
temporary desktop. I have created a new admin user with a permanent desktop
but I would rather have my old one back though.

I also go a reply back in the original forum I asked with a potential solution
but I am suffering form information overload at the moment.


But........... I think I have solved one mystery!!

I was about to back up d: on the 250 meg drive as it shows up under windows XP
However when I look in there it shows the following:-

RECOVERY (a padlocked folder)
wubildr
wubildr.mbr

That is exactly what I saw before when the 500gb drive was in the
USB enclosure. That was a sata enclosure.

So that explains that to a certain extend.

However I just seem to be getting layer upon layer of complexity!!

The sata usb enclosure does not seem to work anymore, well it does not
show up as a drive when you connect it.

Also I don't think those wubildr files should be there at all,
HP would not have then on their recover partition surely?
I guess Linux must have put them there sometime.

Also the d: drive shows up as over 3gig in windows but the
individual files only total to about 1/10 of that, another problem.

 

I think I might try connecting the 500gb drive as a slave when booting on the
250gb drive. Although I am not too sure how to do this with it being sata and the 250 being IDE.

Well I just shut down to do that but it has started installing updatea
all 49 of them, that could take a very very long time!!

 

In fact I would be surprise if the drive actually boot up again
after the updates with all the bad sectors on the drive!!!

 

What I think happened was the HP recovery somehow screwed up the boot records, either their location of their contents.

It's installed all 49 updates and rebooted by the way, I though it would take months!!

 

Connected the 500gb drive as a slave to the machine booted on the 250gb drive,
started a chkdsk but I quit it, if only showed the recovery partition, the main parturition would not show up.
Might explain why it will not work in the enclosure, I guess I will have to run the recovery on it, I don't know what other option I have really.

Will try it again later.

 

The information I could find, said an earlier version of WUBI,
puts those files all over the place. The maintainer at Ubuntu,
made some changes so at least when Ubuntu does software updates,
it only does updates to the one instance of those files. He didn't
attempt to have WUBI erase all the extra copies. So finding

RECOVERY (a padlocked folder)
wubildr
wubildr.mbr

is not a surprise. HP put RECOVERY there. You put those other
two there, by accidentally running WUBI at some point.

Paul

 

The fact that Windows Update runs, tells me your
WinXP is patched to SP3 service pack level. Windows Update
isn't supposed to provide support for earlier versions.

Somewhere around WinXP SP1, the OS got support for >137GB.
That's the only thing I can think of that might be an issue
with a really old OS installation.

You can use PTEDIT32 to display the partition table. If you
were expecting two primary partitions, you might see two
entries in the partition table using this. Using this
is not a priority right now, but I like to have a tool
like this handy.

ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PTEDIT32.zip

It's too bad the following tool is so complicated to use.

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

Testdisk does a couple things for you. It scans a hard drive,
looking for partitions. This comes in handy if you lose the
partition table (say, you ran diskpart, did a "clean" and blew it
away). But once TestDisk finds the partitions, it has a
file inspection page, where you can look at a few of the
files in a partition, on the top level. You can use this
to see if the partition is really there or not. If Testdisk
doesn't like what it sees, it'll probably bow out and not
display anything there.

This is a picture of Testdisk displaying the files in a partition.
You would try this on your "invisible" partition.

http://www.cgsecurity.org/mw/images/List_files.gif

Now, if that worked, it may imply Windows is confused,
two partitions are so alike that one of them is not
being mounted when the other disk is present (or something).
I would be willing to entertain other possibilities, if
I can see the partition under other circumstances.

Sometimes, USB flash drives can't be seen, and it's because
of a network mount. This tool provides a way of managing that.
This probably isn't your problem, but it is an instance where
something won't appear, because another thing took its "slot".

http://www.uwe-sieber.de/usbdlm_e.html

Another tool I like, is "disktype" in Linux. Unfortunately,
that one is not in the standard Repository. And in package
manager, you have to turn on all the Repository options,
do a "reload" to get up-to-date Repository info, all so
you can download a tiny binary. I have had to do that many
times, while booting LiveCD distros, and I'm sick of it

http://disktype.sourceforge.net/

You don't have to build that yourself. It is available in package
manager, if you look hard enough. I'd hoped by now it would
become a standard utility and just be included, but I suppose
that's too easy.

Disktype uses a "voting" scheme. It looks for as many as
five aspects of the file system, before saying "/dev/sda1
is NTFS" or the like. If you got a vote rating of 4/5
or 3/5, that would imply some form of damage to the partition
header.

So those are a few toys you can play with.

It's too bad nobody has done a better version of CHKDSK.
About all that Linux can do for us, is set the dirty bit
and force CHKDSK the next time Windows is booted, which
isn't of much good. In some cases, doing such a thing
would be a terrible idea.

What's really needed, is a partition diagnostic that
can walk through the data structure, not repair it or
write to it, and just tell you how bad it is.

Paul

 

Thanks that's very helpful, I will have to decide on a plan of action.
Chkdsk has been run on the 500 GB before, it seemed to make things worse,
it change it from boot-able to unbootable, running the HP recovery after that made it even worse, that is when the hal.dll error started, I'm pretty sure of that. So running it again will do no further harm I guess. But I want to try some of the stuff you listed to get a look at the drive first.

I also need to have a look at this cloaker thing which has hi-jacked the drive I want to use to look at the 500gb drive. It makes the machine difficult to use, I can't seem to save anything I have done unless I create a new user, but I want my old user back. I tried "hiding" some of the files it uses (lol) ie cloaker, but it still did pretty much the same thing except it was even worse as it gave some permission error at logging.
So I need to find out how it works so I can get my old login back,

This it an interesting thread about it.

http://www.wirelessforums.org/security/how-can-i-disable-hp-preloaded-datamining-13658.html

Might help me find out how to get rid of it, but simply getting rid of it is not going to be enough I need to undo what ever it did to screen my machine up.

It seems to come from the HP recovery process

http://h10025.www1.hp.com/ewfrf/wc/...&jumpid=reg_r1002_usen_c-001_title_r0001#N467

It's going to be a bit of a problem working from a new account I expect, but I think I will have to try that in the meantime.

However at least now, I know what the problem is which is a step forward!!

And yes I did have Ubuntu at one time, I am pretty sure the wubi stuff should not be in the recovery folder.


Also had the recovery actually worked I would probably have been left with the same kind of hi-jacked drive. It may not have worked properly because the partitions were different as it was cloned form the 250meg drive, but that was clone in the first place.

I seem to have something in the back of my mind about partition order beingreversed in XP or something like that, well yes I seem to remember it being shows up first in the XP drive management utility.

Any how I have a lot of things to look into.

 

According to this, cloaker.exe hides any window that would pop
up from running the command line that is passed to it. It doesn't
"hide" an executable or run as a rootkit of something. It merely
prevents things like DOS windows from "flashing" on the screen.
It prevents a visual distraction.

http://www.bleepingcomputer.com/startups/cloaker.exe-14039.html

In the wirelessforums page, they used the word "datamining", but I
don't see any evidence there of such. New laptops typically have
a registration application, where a user can fill in their details
(for some reason). I think there's still one running on my laptop,
but I've never filled it out. I don't think it has even appeared
since I got the thing.

Paul

 

It's rather ironic that two things supposed to get me out of a mess ie chkdsk
and HP recovery actually left me a far worse state than where I originally was!!
Furthermore prior to this the only thing that left my PC in an unbootable state was anti-virus software!!!
I guess to be fair they have got me out of a mass quite a few time too so maybe I should not be too hard on them.

It might help to find out a bit more about what the HP recovery tries to do as it seems it was that which lost hal.dll, but finding out is unlikely to be easy.
Also reading about boot sector as I need to understand them better.

 

Well this is what it has done to my PC.

1) All my previous desktop items have been moved to a temporary folder and I have basically been set up as a band new user. No bookmarks or history inmy browsers.

2) Every time I login I am set up as a brand new users, ie all my book marks and history have gone and all my setting for everything.

3) That happens even if I create a new login id. Indeed I get asked if I would like to take a tour of windows every time to get familiar with it.

Hence the PC is next to useless, I can save stuff on the desktop if I create a new user, but not on my old login, new desktop every time.

But I loose all personal setting whatever login I use.

So it is a pretty devastating effect, making the computer next to useless.

And why would anyone want to do that?

To me it is bordering in criminal, it seems from what I have read someone can secretly logging and kill processes, or something like that.

But whatever is has effectively disable my PC as a usable PC on a long termbasis.

Anyway, enough of the bad news, well there is one more piece of bad news first
actually, that TestDisk would not work on the 5000gb drive, it just locked up as does windows when you click on the drive and select properties.

Hence I threw in the towel and started a chkdsk on it, that found some errors
in te index for file 9 or something like that.

So I have the 500gig drive back with both partition.

I just looked in the recovery partition and I see the wubildr files, the recovery looked folder and also now a Kaspersky Rescue Disk 10 folder, lol,
so see that stuck something on there too.

So that drive seem to function fine now as a slave drive, the only questionis, is it bootable???

Well there is only one way to find out I guess and that is to try it.

I expect the hal.dll will have gone, but it may be back to the error beforethat.

In the perhaps unlikely event it does boot it maybe It also has the cloakerproblem on it!!

Hence I will try and boot from it and report back.

 

Well it is back to the hal.dll error on a black screen if I try and boot normally, I get a blue screen with a different error if I try to boot run windows recovery.

I guess I could also try the HP recovery, which I think is different, can'treally make it much worse, although at least I can see and access the drive in windows now.

I can also access it in the TestDisc utility now.f3

TestDisc also gave an error when I did a search o it it said the drive seemto small, ie 500gb/463gb <<993gb/925gb>, check the hardisc size : HD jumpers, BIOS settings. But that's probably misleading.

Also I am not sure if I screwed up at some point, it look like it now has 2large partition, ie as if I wrote the main partition over the recovery partition!

I am not sure what happened, the thing is I am using two keyboards and otenstart typing on the wrong one, it might be I typed on the wroing keyboad and cause it to do something I did not want. You basically only have to hit a letter and return to make it do something.

It is doing some scan now which will take a while, just 5% completed, I will let it run an then take another look at it in windows to see what has happened.

 

well here is something of interest, I notice on the 500gb drive the
recovery partition is on the first partition and the main partition is the second

That is the opposite way around to the 250 meg

Ie in the full listing in windows I have

c: HP_pavillion d: HP_recovery

f: HP_recovery g: HP_pavillion.

I knew there was somthing in the back of my mind about this.

I guess I must have screwed things up when I did the clone for some reason.

Not sure why as I got it right the first time I cloned!!

That might well explain a lot.

 

Could the reason stuff is appearing in the recovery partition be that the drive
letters are the wrong way around?
Seems quite likely I suppose?

I guess maybe I could try and swop them around (the partition), assuming that is possible. They are of different formats one FAT32 and the other.

I note if I go to disk management in the control panel the first drive is listed as d:c: and the second f:g:

This is what I meant about things being the wrong way around, maybe I triedto
correct that but in fact should have left it alone?

The original utility I used to clone the drive might be able to swop them back?
However if it has to create the partitions first that might not be possible..

Or could there be a simpler fix? Ie something to swop drive letter? I don'treally know enough about it.

 

The spatial order of partitions on a hard drive,
does not have to match the order of partitions in the
partition table.

But when a bootable partition is cloned, the cloning
software does not want to be inside boot.ini, editing
stuff. To stop the need for editing stuff, when they
copy C:, they make sure it's put in a partition location
so the boot.ini is still correct.

So if some partition editor software swaps partitions
around in the partition table, and later you clone the
drive, the order of the partitions can seem to be changed.
And it's done that way, so the boot.ini (or BCD) remains
correct.

What you can do, is use PTEDIT32 and observe the original
drive. Look at the starting offset of the partitions.
The starting offsets probably aren't in increasing order.
Cloning such a drive, is bound to result in an apparent
change in partition order.

If the cloning software didn't care about booting and whether
you could boot the new drive later, it would make an exact
copy, no matter how screwed up it was. And then the user
would end up having to check the new boot.ini to make sure
it was correct.

*******

When a drive "says it is too small", that suggests an HPA
(host protected area) is present. You can check for one
of those with Linux.

http://en.wikipedia.org/wiki/Host_protected_area

They suggest "hdparm" as a tool to use, but you might
also try stepping through the information from "dmesg"
to spot an HPA-prepared hard drive. Sometimes, the
recovery partition is "hidden" by SET_MAX_ADDRESS
command. So if you see a "too small" drive, some
OEM systems have five primary partitions, and the
partition table and HPA are modified on the fly
to load the "best four of five". What fun...

Paul