Blinking cursor at failed boot

On 1/20/2014 7:09 AM, philo wrote:
On 01/19/2014 05:07 PM, Jon Danniken wrote:
On 01/19/2014 02:56 PM, philo wrote:
[...]
So that further leaves me to believe its an MBR problem.

If the disk was blank (having no MBR) you'd get the "non-system disk" error

One other thing though...have you made /any/ changes in the BIOS?

I have noticed that from machine to machine there are differences
/sometimes/ in how exactly the BIOS "hands off" to the MBR

If I put an XP hard drive in another machine one would usually see the
system start to load and then go into a BSOD (or once in a while
actually boot to Windows)

However once in a while I just observe the blinking cursor.

You know, that is another possibility here. Let's go on the theory of a
corrupt MBR record. Even when trying to restore it, its still corrupt.

Two things that I can think of that could cause this:

1) Some BIOS has a toggle to make the MBR as read only. This feature is
intended to block some malware from hooking into the MBR.

2) The first track and sector on the drive holds the MBR. Even a brand
new drive has some bad sectors on it from manufacturing. No problem
though since the drive marks them as bad and won't write anything there.
Although this isn't true if the MBR sector ever fails. The drive should
be usable in every other way except for booting.

--
Bill
Motion Computing LE1700 ('09 era) - Thunderbird v12
Centrino Core2 Duo L7400 1.5 GHz - 2GB RAM
Windows XP Tablet PC Edition 2005 SP2

On 01/20/2014 07:49 AM, BillW50 wrote:



snip
1) Some BIOS has a toggle to make the MBR as read only. This feature is
intended to block some malware from hooking into the MBR.

2) The first track and sector on the drive holds the MBR. Even a brand
new drive has some bad sectors on it from manufacturing. No problem
though since the drive marks them as bad and won't write anything there.
Although this isn't true if the MBR sector ever fails. The drive should
be usable in every other way except for booting.



You are right and I had forgotten about that.

OTOH: If the BIOS is setup that way and something tries to write to the
MBR, you get a warning screen and an option to allow or deny.

(At least on any BIOS that I've worked with)

While I was fooling around renaming the system "boot" files I noticed
something interesting.

If I used a Linux-based utility to do so, even though I could rename the
files, when I attempted to boot to Windows I was able to do so with no
error. When I examined the files, the re-naming did not stick. I assume
that's because Linux does not update the MFT and upon boot, the error is
corrected.

If I used a Windows-based utility, the name change stuck



Of course as to the MBR, I don't think any of that is kept in the MFT
but having GRUB on the MBR...even if removed...must have left the MBR
corrupted somehow.

On 1/20/2014 9:23 AM, philo wrote:
On 01/20/2014 07:49 AM, BillW50 wrote:

snip
1) Some BIOS has a toggle to make the MBR as read only. This feature is
intended to block some malware from hooking into the MBR.

2) The first track and sector on the drive holds the MBR. Even a brand
new drive has some bad sectors on it from manufacturing. No problem
though since the drive marks them as bad and won't write anything there.
Although this isn't true if the MBR sector ever fails. The drive should
be usable in every other way except for booting.

You are right and I had forgotten about that.

OTOH: If the BIOS is setup that way and something tries to write to the
MBR, you get a warning screen and an option to allow or deny.

(At least on any BIOS that I've worked with)

I seen both happen, with an error and without. It probably depends on
the guy who wrote the BIOS.

And maybe I better mention this too. Never get any funny ideas thinking
you are going to remove the MBR by using a disk editor and zero out the
whole sector. Yes you can zero out the first X number of bytes. But at
the tail end of the sector has very important things in there. Things
like what kind of device it is, where the partition info is at, and so
on. If you zero everything out, nothing most likely will ever see the
whole drive as a useable device again. Also you probably can't even go
back in there again with the same disk editor either. At least not after
a reboot.

--
Bill
Motion Computing LE1700 ('09 era) - Thunderbird v12
Centrino Core2 Duo L7400 1.5 GHz - 2GB RAM
Windows XP Tablet PC Edition 2005 SP2

BillW50 wrote:
On 1/20/2014 9:23 AM, philo wrote:
On 01/20/2014 07:49 AM, BillW50 wrote:

snip
1) Some BIOS has a toggle to make the MBR as read only. This feature is
intended to block some malware from hooking into the MBR.

2) The first track and sector on the drive holds the MBR. Even a brand
new drive has some bad sectors on it from manufacturing. No problem
though since the drive marks them as bad and won't write anything there.
Although this isn't true if the MBR sector ever fails. The drive should
be usable in every other way except for booting.

You are right and I had forgotten about that.

OTOH: If the BIOS is setup that way and something tries to write to the
MBR, you get a warning screen and an option to allow or deny.

(At least on any BIOS that I've worked with)

I seen both happen, with an error and without. It probably depends on
the guy who wrote the BIOS.

And maybe I better mention this too. Never get any funny ideas thinking
you are going to remove the MBR by using a disk editor and zero out the
whole sector. Yes you can zero out the first X number of bytes. But at
the tail end of the sector has very important things in there. Things
like what kind of device it is, where the partition info is at, and so
on. If you zero everything out, nothing most likely will ever see the
whole drive as a useable device again. Also you probably can't even go
back in there again with the same disk editor either. At least not after
a reboot.


Yes, we know the 512 byte MBR has 440 bytes code, and four 16 byte
partition table entries. The partition table entries can be regenerated
with TestDisk, but with caveats. Deleted partitions will be redetected,
and old file system headers that never got overwritten, can be
detected by TestDisk as well. A human has to look at the computed
partition tables and decide whether they're realistic or not. For
example, I ran TestDisk once, and had it compute a partition table,
where two partitions overlapped. It doesn't seem to check for that,
for the version I was using. If I had accepted and used that
computed MBR, I would have ended up with a corrupted partition
(that CHKDSK can't fix).

I'm curious as to the mechanism the BIOS would use, to "protect"
the disk once the OS is running. I've heard of
"Trend ChipAway Virus On Guard" a.k.a. TCAV, which
has something to do with detecting a hijack of
disk resources, but it apparently "recognizes" OSes,
which means if you install some OS it doesn't know
about, it may mistake it for a problem and put up
a dialog on the screen. And that would not be
a form of real-time protection, that's a scan TCAV
does at startup. So if I wanted to entirely
zero out a disk from a running OS, I don't think
TCAV would do a damn thing. It's a startup check for
a hijack.

(TCAV positive hit, during POST)

http://img441.imageshack.us/img441/2210/p5120121.jpg

I can't find any documentation, for what it looks for.

I did notice, in a Google search, that machines infected
with TDSS may trigger a TCAV warning message on startup.
There is a description here of how TDSS works, and
apparently it modifies MBR code. Perhaps a machine
with TCAV, knows of a few 440 code segments, and if
it finds a modification, then prints the warning on
the screen ? It would be pretty difficult for TCAV
to actually care about all the files an OS uses - that
would take too much space to implement in the BIOS
flash chip.

http://www.securelist.com/en/analysi...157/TDSS_TDL_4

Paul

On 1/20/2014 11:58 AM, Paul wrote:
BillW50 wrote:
On 1/20/2014 9:23 AM, philo wrote:
On 01/20/2014 07:49 AM, BillW50 wrote:

snip
1) Some BIOS has a toggle to make the MBR as read only. This feature is
intended to block some malware from hooking into the MBR.

2) The first track and sector on the drive holds the MBR. Even a brand
new drive has some bad sectors on it from manufacturing. No problem
though since the drive marks them as bad and won't write anything
there.
Although this isn't true if the MBR sector ever fails. The drive should
be usable in every other way except for booting.

You are right and I had forgotten about that.

OTOH: If the BIOS is setup that way and something tries to write to the
MBR, you get a warning screen and an option to allow or deny.

(At least on any BIOS that I've worked with)

I seen both happen, with an error and without. It probably depends on
the guy who wrote the BIOS.

And maybe I better mention this too. Never get any funny ideas
thinking you are going to remove the MBR by using a disk editor and
zero out the whole sector. Yes you can zero out the first X number of
bytes. But at the tail end of the sector has very important things in
there. Things like what kind of device it is, where the partition info
is at, and so on. If you zero everything out, nothing most likely will
ever see the whole drive as a useable device again. Also you probably
can't even go back in there again with the same disk editor either. At
least not after a reboot.


Yes, we know the 512 byte MBR has 440 bytes code, and four 16 byte
partition table entries. The partition table entries can be regenerated
with TestDisk, but with caveats. Deleted partitions will be redetected,
and old file system headers that never got overwritten, can be
detected by TestDisk as well. A human has to look at the computed
partition tables and decide whether they're realistic or not. For
example, I ran TestDisk once, and had it compute a partition table,
where two partitions overlapped. It doesn't seem to check for that,
for the version I was using. If I had accepted and used that
computed MBR, I would have ended up with a corrupted partition
(that CHKDSK can't fix).

I'm curious as to the mechanism the BIOS would use, to "protect"
the disk once the OS is running. I've heard of
"Trend ChipAway Virus On Guard" a.k.a. TCAV, which
has something to do with detecting a hijack of
disk resources, but it apparently "recognizes" OSes,
which means if you install some OS it doesn't know
about, it may mistake it for a problem and put up
a dialog on the screen. And that would not be
a form of real-time protection, that's a scan TCAV
does at startup. So if I wanted to entirely
zero out a disk from a running OS, I don't think
TCAV would do a damn thing. It's a startup check for
a hijack.

(TCAV positive hit, during POST)

http://img441.imageshack.us/img441/2210/p5120121.jpg

I can't find any documentation, for what it looks for.

I did notice, in a Google search, that machines infected
with TDSS may trigger a TCAV warning message on startup.
There is a description here of how TDSS works, and
apparently it modifies MBR code. Perhaps a machine
with TCAV, knows of a few 440 code segments, and if
it finds a modification, then prints the warning on
the screen ? It would be pretty difficult for TCAV
to actually care about all the files an OS uses - that
would take too much space to implement in the BIOS
flash chip.

http://www.securelist.com/en/analysi...157/TDSS_TDL_4

Well here is one I know rather well. On an Asus EeePC 700 series in the
BIOS (F2), there is a setting called "OS Installation". It has two
choices, either "Start" or "Finished". Start allows R/W access to the
MBR and Finish only allows read only access. And no errors are reported
if you try to write over the MBR in read only mode.

Philo mentioned about using Win98 FDISK /MBR. And that one has a
bug/feature in it. As the MBR sector also contains the 32-bit disk
signature. And if you add a second drive under Windows 200, XP, etc. to
format it and then want to clone the first drive to the second new one.
And when done, you pull out the first one and use the second as the
first only drive, guess what? It won't boot. Because Windows remembers
this is the other second drive by its 32-bit disk signature.

But Windows 98 FDISK /MBR bug/feature not only writes to the MBR part,
but also corrupts part of the 32-bit disk signature. So now the clone
will boot normally because Windows thinks it never saw this drive before
and thus doesn't confuse it as that other drive.

Also I also recall somewhere on the MBR sector is also a one byte device
type. I believe the range is 80h to FFh. But 8xh is very common and I
believe 80h was really common. If you null this one out, every OS will
see this as an unknown device type and won't do anything with it. You
won't even able go back in and change it back. More or less like a
bricked hard drive.

--
Bill
Motion Computing LE1700 Tablet ('09 era) - Thunderbird v12
Centrino Core2 Duo L7400 1.5GHz - 2GB RAM - Windows 8 Professional

On 01/20/2014 05:37 PM, BillW50 wrote:


snip

Philo mentioned about using Win98 FDISK /MBR. And that one has a
bug/feature in it. As the MBR sector also contains the 32-bit disk
signature. And if you add a second drive under Windows 200, XP, etc. to
format it and then want to clone the first drive to the second new one.
And when done, you pull out the first one and use the second as the
first only drive, guess what? It won't boot. Because Windows remembers
this is the other second drive by its 32-bit disk signature.

But Windows 98 FDISK /MBR bug/feature not only writes to the MBR part,
but also corrupts part of the 32-bit disk signature. So now the clone
will boot normally because Windows thinks it never saw this drive before
and thus doesn't confuse it as that other drive.

Also I also recall somewhere on the MBR sector is also a one byte device
type. I believe the range is 80h to FFh. But 8xh is very common and I
believe 80h was really common. If you null this one out, every OS will
see this as an unknown device type and won't do anything with it. You
won't even able go back in and change it back. More or less like a
bricked hard drive.




Thanks for the added info. I also recall back in the days when people
used drive overlay software. You needed to remove it by using the same
utility that installed it. I found that if I used fdisk /mbr, the
overlay was deactivated...but it was still on the MBR.


Other than using the utility's uninstall feature, the only way you could
remove it was by doing a so called low level format. I'm sure that if
someone totally screwed up the mbr there are some utilities out there
that could blank out the entire drive and allow one to start over.

On 01/19/2014 04:23 PM, Paul wrote:
Jon Danniken wrote:
On 01/19/2014 02:25 PM, Jon Danniken wrote:
I did try changing out ntldr and ntdetect, but again no dice. The MS
site suggested making a boot floppy, but I don't have a USB floppy drive
(yet), nor any floppy drives on this one.

Just for fun I deleted ntldr and rebooted. I didn't get the "NTLDR
Missing or Corrupt" message, so whatever is happening isn't getting that
far in the process.

Jon


Interesting.

I was going to suggest this, but I guess not. As you'd
proved it's not going to help.

http://support.microsoft.com/kb/305595

The idea is, you use the Windows installer CD, go to i386 and
get a copy of NTLDR and NTDETECT.com and copy those to a floppy.
Then, I went to the existing C: drive and copied boot.ini from
C: to the floppy, a total of 3 files. Note - before you object,
the usage of a floppy, is part of an imaging trick - this floppy
will *not* be offered to the broken computer.

Then, I used this.

http://www.chrysocome.net/dd

( http://www.chrysocome.net/downloads/dd-0.6beta3.zip )

Then, make an image of the floppy. This is a sector by
sector image. It copies every sector on the floppy.
DD has some bugs in its "end-of-device" check, but in
this case, it knows where the end of the floppy is.

dd if=\\?\Device\Floppy0 of=bootxp.dd bs=512

The resulting file should be 1,474,560 bytes (2880 sectors).
So now I have an image of a FAT12 floppy, with three files on
it, stored in a 1,474,560 byte file.

Next, I transfer that to my 1GB Kingston USB flash.

dd if=bootxp.dd of=\\?\Device\Harddisk2\Partition0 bs=32768 count=45

which will transfer the floppy image to a USB stick. The larger the
block size parameter the better, as long as it's a power_of_two. So 32768
is as close as I can get to the larger USB flash stick storage size.

Note, the files that were already on the USB stick, I didn't lose them,
because I backed them up.

dd if=\\?\Device\Harddisk2\Partition0 of=savethefiles.dd bs=262144
count=3838

The dimensions of devices can be determine by using this command,
as described on the program author's web site.

dd --list

and knowing that "Partition0" represents the whole device as a block
device.
That's where I get the information that my USB stick is 1,006,108,672
bytes.
And know that 262144 * 3838, copies the entire USB stick.

I can reverse the dd transfer, and put the image of what was on there,
back.


Thanks Paul, I appreciate that. Unfortunately I was unable to coax
either of my two floppy drives to work, although they were both
functional the last time I checked (which was, admittedly, many years
ago). I was able to create a floppy image in virtualbox, however (using
dd bs=512 count=2880 if=/dev/zero of=floppy.img), which allowed me to
get a virtual floppy to play with.

Unfortunately, booting with it on either of my machines gave me a "Disk
Error" message. I also tried it with a virtual floppy that I made into
a system disk (also under virtual XP), but booting with that one gave me
a "Disk I/O Error" message.

So I'll have to pick up a known working floppy drive to rule out virtual
floppies as being useful.


OK, I did two boot tests. I booted the floppy with NTLDR, NTDETECT.com
and boot.ini, and it presented the OS boot choice menu (WinXP boot
manager).
So that worked. That means the floppy bootstrapped me into WinXP, and
the WinXP boot manager took over. The boot.ini ARC path was important
to that process selecting the correct disk. I have two disks, and WinXP
is on only one of the disks. The floppy targeted the correct disk.

Next, I used the popup boot and selected the USB flash stick. And the same
thing happened, it booted to the WinXP boot manager, and WinXP booted.
So the
Microsoft recipe works :-)

The reason the image transfer using "dd" is needed, is to get around the
USB flash stick formatting issue. The format on the floppy is likely
something like FAT12 or FAT16. You can't expect to take a huge USB flash
stick, and convince Windows to format it FAT12. By imaging a floppy
diskette,
file system and all, and transplanting it onto the USB key, that is part of
what makes this work. The floppy is used as an intermediate "cheating"
step.

The other part, is certain "emulation" modes the BIOS has. It treats USB
devices according to size in some cases. Some BIOS even know when a USB ZIP
drive is connected to the computer, and do something different internally
for those. So there's no guarantee that my experience would have worked
for you. Some older BIOS, just don't have good working USB boot options.


This could also be a factor. My main machine didn't recognize it with
the F12 menu, so I had do actually go into the BIOS and select it it
under HDD Priority. One of my other machines didn't even recognize it
at all, but it's an old Epox board that is rather unpredictable even in
the best of times.


Is the file system on that disk, mountable from Linux ? That would
tell you the file system header is at least partially OK. Linux
may not check everything in there for consistency. I would have
thought CHKDSK run from some Windows environment (recovery console),
should also have been looking at that. Windows probably wouldn't have
mounted the partition, if it didn't recognize it. So right away,
that suggests the file system header (bytes at the very beginning
of the partition) are OK.

In Linux, you can do

sudo disktype /dev/sda

to get a rundown of what Linux thinks is on the disk in terms of
file systems. I expect GParted would display the information
as well. I like disktype because it's a small (optional) tool
which is handy when something is broken.

http://disktype.sourceforge.net/

Yes, I can mount the partition in Linux without any trouble whatsoever;
I can even boot into it with the Hiren's disk, just not with my regular
grub install, nor after fixmbr/fixboot, nor rescatux (which is odd
because Hiren's uses a form of grub).

With enough fiddling, you can even get Package Manager and
a network connection on a LiveCD, to give you a copy of the
binary of that. Few distros come with that as standard. You
have to go into the Package Manager, turn on all the Repositories,
reload, then search for disktype, all to get the tiny executable.

I don't really know where to go next. You did a fixboot (update
the boot sector in the C: partition, in the file system header
area) as well as fixmbr (fix the 440 bytes in the MBR sector 0).
You shouldn't really need to do a fixboot, unless the partition
had been formatted and the file system header overwritten by
a formatter. I know this, because I copy the files off my
WinXP occasionally, format C:, and copy the files back. And
the OS won't boot, unless that is followed by a fixboot. Otherwise,
you probably wouldn't (normally) need it.

So that's yet another option for you (if you're bored). Copy
all the files off C:. Reformat C:. Copy all the files back.
Do a fixboot. Make sure NTLDR, NTDETECT.com and boot.ini
are present. And try booting. That's a lot of work, and
when I do that process, I dual boot Win2K and do the file
copying step from there. So it's not something you do with
only one OS present. While you can do things like run an
NTBACKUP plugin from BartPE and other exotic things, that's
really reserved for when you have a running system and
need a hobby :-)

Aye, thanks again. I may indeed end up transferring the contents to
spare space on the drive and recreating the partition. Assuming I get a
working installation on it I will definitely image it should this happen
again.

Jon

On 01/20/2014 05:26 AM, Ben Myers wrote:

Start XP, click "Start", "Run", type "diskmgmt.msc" into the "Open" box and click "OK".
Right-click the "C:" drive in the top window and see if "Mark partition as active" is available.
If so, select it. Also, removing Grub may actually be a three step process, fixboot, fixmbr
and then fixboot again.

http://www.wikihow.com/Uninstall-the...-With-an-XP-CD

Hi Ben, and thanks. I gave that a shot, but still no joy. I actually
did it the other way, too (fixmbr, fixboot, fixmbr) just for fun.

Jon

On 01/20/2014 05:09 AM, philo wrote:

I ran some tests and renamed the system "boot" files to see what would
happen.


1) Renaming "ntldr" gave the expected message about ntldr being missing.

2) Renaming ntdetect.com , the system just went into a reboot.

3) Renaming boot.ini I got a message that boot.ini was mis-configured
and then to my surprise Windows loaded anyway.



So that further leaves me to believe its an MBR problem.


If the disk was blank (having no MBR) you'd get the "non-system disk"
error

Neat, thanks philo. It is a puzzler that I'm not getting any error
messages, just the blinking cursor. Grub can boot to linux (on a
different partition) just fine, but neither it, nor Windows (with fixmbr
and fixboot), can reach the Windows partition. Hiren's does, though,
with whatever magic it uses.


One other thing though...have you made /any/ changes in the BIOS?

Nope, haven't even poked around in there for awhile.

I have noticed that from machine to machine there are differences
/sometimes/ in how exactly the BIOS "hands off" to the MBR

If I put an XP hard drive in another machine one would usually see the
system start to load and then go into a BSOD (or once in a while
actually boot to Windows)

However once in a while I just observe the blinking cursor.

I did upgrade the processor a few weeks ago, but afterwards Windows was
working fine, over several reboots.

Thanks again,

Jon

On 01/20/2014 09:58 AM, Paul wrote:
BillW50 wrote:
On 1/20/2014 9:23 AM, philo wrote:
On 01/20/2014 07:49 AM, BillW50 wrote:

snip
1) Some BIOS has a toggle to make the MBR as read only. This feature is
intended to block some malware from hooking into the MBR.

2) The first track and sector on the drive holds the MBR. Even a brand
new drive has some bad sectors on it from manufacturing. No problem
though since the drive marks them as bad and won't write anything
there.
Although this isn't true if the MBR sector ever fails. The drive should
be usable in every other way except for booting.

You are right and I had forgotten about that.

OTOH: If the BIOS is setup that way and something tries to write to the
MBR, you get a warning screen and an option to allow or deny.

(At least on any BIOS that I've worked with)

I seen both happen, with an error and without. It probably depends on
the guy who wrote the BIOS.

And maybe I better mention this too. Never get any funny ideas
thinking you are going to remove the MBR by using a disk editor and
zero out the whole sector. Yes you can zero out the first X number of
bytes. But at the tail end of the sector has very important things in
there. Things like what kind of device it is, where the partition info
is at, and so on. If you zero everything out, nothing most likely will
ever see the whole drive as a useable device again. Also you probably
can't even go back in there again with the same disk editor either. At
least not after a reboot.


Yes, we know the 512 byte MBR has 440 bytes code, and four 16 byte
partition table entries. The partition table entries can be regenerated
with TestDisk, but with caveats. Deleted partitions will be redetected,
and old file system headers that never got overwritten, can be
detected by TestDisk as well. A human has to look at the computed
partition tables and decide whether they're realistic or not. For
example, I ran TestDisk once, and had it compute a partition table,
where two partitions overlapped. It doesn't seem to check for that,
for the version I was using. If I had accepted and used that
computed MBR, I would have ended up with a corrupted partition
(that CHKDSK can't fix).

I'm curious as to the mechanism the BIOS would use, to "protect"
the disk once the OS is running. I've heard of
"Trend ChipAway Virus On Guard" a.k.a. TCAV, which
has something to do with detecting a hijack of
disk resources, but it apparently "recognizes" OSes,
which means if you install some OS it doesn't know
about, it may mistake it for a problem and put up
a dialog on the screen. And that would not be
a form of real-time protection, that's a scan TCAV
does at startup. So if I wanted to entirely
zero out a disk from a running OS, I don't think
TCAV would do a damn thing. It's a startup check for
a hijack.

(TCAV positive hit, during POST)

http://img441.imageshack.us/img441/2210/p5120121.jpg

I can't find any documentation, for what it looks for.

I did notice, in a Google search, that machines infected
with TDSS may trigger a TCAV warning message on startup.
There is a description here of how TDSS works, and
apparently it modifies MBR code. Perhaps a machine
with TCAV, knows of a few 440 code segments, and if
it finds a modification, then prints the warning on
the screen ? It would be pretty difficult for TCAV
to actually care about all the files an OS uses - that
would take too much space to implement in the BIOS
flash chip.

http://www.securelist.com/en/analysi...157/TDSS_TDL_4

Interesting. One thing that I didn't mention before (and most likely
has nothing to do with this), is that I picked up a new wifi adaptor
last week. When I put it into the USB port (under Linux), I got a
screen full of code message output, like you see when you boot (or
shutdown) a Linux system. When I pulled the adaptor out, the machine
rebooted, which seemed odd.

The next time I put it in the machine I got the same messages, but
pulling it out didn't reboot the machine, and that was the last time I
saw the messages (it ended up needing me to download the driver for it
to work anyway).

It struck me as odd that inserting a wifi adaptor would yield those
results, and it was later that I first noticed that XP wouldn't boot
(first time I had booted if for a couple of weeks, though).

Anyway, I'm sure it's nothing.

Jon

"Jon Danniken" wrote in message ...
On 01/20/2014 05:26 AM, Ben Myers wrote:
Start XP, click "Start", "Run", type "diskmgmt.msc" into the "Open" box and click "OK".
Right-click the "C:" drive in the top window and see if "Mark partition as active" is available.
If so, select it. Also, removing Grub may actually be a three step process, fixboot, fixmbr
and then fixboot again.

http://www.wikihow.com/Uninstall-the...-With-an-XP-CD

Hi Ben, and thanks. I gave that a shot, but still no joy. I actually
did it the other way, too (fixmbr, fixboot, fixmbr) just for fun.

You might try rebuilding the partition table.

https://www.google.com/?complete=0#c...ition+table+xp

Ben

Jon Danniken wrote:

Interesting. One thing that I didn't mention before (and most likely
has nothing to do with this), is that I picked up a new wifi adaptor
last week. When I put it into the USB port (under Linux), I got a
screen full of code message output, like you see when you boot (or
shutdown) a Linux system. When I pulled the adaptor out, the machine
rebooted, which seemed odd.

The next time I put it in the machine I got the same messages, but
pulling it out didn't reboot the machine, and that was the last time I
saw the messages (it ended up needing me to download the driver for it
to work anyway).

It struck me as odd that inserting a wifi adaptor would yield those
results, and it was later that I first noticed that XP wouldn't boot
(first time I had booted if for a couple of weeks, though).

Anyway, I'm sure it's nothing.

Jon


I wonder how you can study a thing like that, when it
trashes anything it is connected to ?

Did you get that thing at an NSA flea market ? :-)

Paul

On 01/21/2014 10:18 PM, Paul wrote:
Jon Danniken wrote:

Interesting. One thing that I didn't mention before (and most likely
has nothing to do with this), is that I picked up a new wifi adaptor
last week. When I put it into the USB port (under Linux), I got a
screen full of code message output, like you see when you boot (or
shutdown) a Linux system. When I pulled the adaptor out, the machine
rebooted, which seemed odd.

The next time I put it in the machine I got the same messages, but
pulling it out didn't reboot the machine, and that was the last time I
saw the messages (it ended up needing me to download the driver for it
to work anyway).

It struck me as odd that inserting a wifi adaptor would yield those
results, and it was later that I first noticed that XP wouldn't boot
(first time I had booted if for a couple of weeks, though).

Anyway, I'm sure it's nothing.

Jon


I wonder how you can study a thing like that, when it
trashes anything it is connected to ?

Did you get that thing at an NSA flea market ? :-)

LOL Paul!

Jon

On 01/21/2014 09:07 PM, Jon Danniken wrote:
On 01/20/2014 05:09 AM, philo wrote:

I ran some tests and renamed the system "boot" files to see what would
happen.


1) Renaming "ntldr" gave the expected message about ntldr being missing.

2) Renaming ntdetect.com , the system just went into a reboot.

3) Renaming boot.ini I got a message that boot.ini was mis-configured
and then to my surprise Windows loaded anyway.



So that further leaves me to believe its an MBR problem.


If the disk was blank (having no MBR) you'd get the "non-system disk"
error

Neat, thanks philo. It is a puzzler that I'm not getting any error
messages, just the blinking cursor. Grub can boot to linux (on a
different partition) just fine, but neither it, nor Windows (with fixmbr
and fixboot), can reach the Windows partition. Hiren's does, though,
with whatever magic it uses.


Basically all you are doing when you use Hiren's is omit loading the
HD's MBR...which is further evidence of an MBR problem.


Why it cannot be fixed, I don't know.