Prev: Not Asus-specific: SATA & AHCI
Next: Intermittent lockups, need troubleshooting advice
From: Paul on 13 Jun 2010 04:44
Puddin' Man wrote:
> On Sat, 12 Jun 2010 02:13:44 -0400, Paul <nospam(a)needed.com> wrote:
>
>> Have you tried pressing F8 at bootup ? That could present a
>> popup boot menu, and then perhaps the CDROM drive would be listed.
>>
>> I can't promise the results would be any different, but perhaps
>> that path would actually get to the CDROM. The fact you're getting
>> the exact same message, seems to suggest the optical drive is being
>> ignored for some reason. Does it look like the optical drive is
>> enabled in the BIOS screens ? Is the optical drive on one of the
>> Southbridge SATA ports ? Have you tried another SATA port for the
>> optical drive ? Does the optical drive show up, by name, in the F8
>> popup boot menu ?
>
> 'Tis well that you ask all these questions, as I seem to be
> prone to miss a detail here or there ...
>
>> I can't really think of any other test cases, other than F8. because
>> you seem to have exhausted any other possible solution. The only other
>> way out of this, would be an alternate BIOS version, where ExpressGate
>> was entirely missing. And I doubt Asus would entertain such an option.
>>
>> This is what it says in your manual, with regard to F8.
>>
>> "To select the boot device during system startup, press <F8>
>> when ASUS Logo appears."
>
> I finally got this to work (the timing is tricky with this board).
> Loaded the Recovery Console, ran fixmbr which said it successfully
> rebuilt mbr.
>
> Rebooted and got (guess what) ... Voila! :-)
>
> "A kernel file is missing from the disk.
> Insert a system diskette and restart the system."
>
> I thought I had disabled Expess Gate, but it was set to 'Auto'
> which suppressed the features, only wrote a line of text. I
> fully disabled it and got the same result when trying to boot.
>
>> As for the behavior of your system, the only other option that
>> comes to mind, is flash updating the BIOS. Check the vip.asus.com
>> forums before doing that - sometimes, if a new BIOS is causing grief,
>> there'll be a posting from a customer there.
>>
>> http://vip.asus.com/forum/view.aspx?id=20100520225401593&board_id=1&model=P7H55D-M+EVO&page=1&SLanguage=en-us
>
> I checked, no evident bios issues. There are 5 bios versions available.
> I'm running the second (0701). The entire series looks like:
>
> Version 1303 - Improve Memory OK! function.
> Version 0903 - Support new CPUs. ...
> Version 0806 - Enhance the compatibility with certain memory.
> Version 0701 - Add item "Configure SATA as" at setup screen to support AHCI mode
> Version 0503 - First release.
>
> In order to get to these on the Asus site, I had to spec an OS. I spec'd
> Win7 (no W2k option). Are bios's now OS dependent? Do you know anything
> about EFI (Extensible Firmware Interface)?
>
> Just for s***s and grins, I reconnected the Win7 disk, booted, and
> searched the W2k disk for "kernel file is missing". It found no
> occurances. Of course, I don't necessarily trust Win7 "Search". <g>
>
> Some days it just doesn't pay to get out of bed ... :-)
>
> Thanks,
> P
>

I've only made a little program on the "what triggers XMNT2001.exe" problem.

I set up a VirtualPC session, put a fixed size virtual disk in it, and copied
over my Win2K image using Partition Magic (installed inside the virtual session).
I was hoping I'd be able to scan the fixed size virtual disk and find the call
to that program. I picked a pretty small VHD virtual disk size, so the search
would not take forever.

I have one idea why a scan of the disk isn't finding the call. And this
stinks. The file name is stored in "double byte format", which is
why it isn't being detected in a search. X_M_N_T_2_0_0_1, where the
underscores are hex 0x00 values. Just to give you an idea what other
ways there are of doing it.

Now, I didn't really make much progress that way. I did discover two
key files.

WINNT\system32\PQ_BATCH.PQB
WINNT\system32\PQ_DEBUG.TXT

Partition Magic appears to be hooking into a registry entry called
BootExecute. That is what the PQ_DEBUG.TXT file is telling me,
because it records the before and after values of that registry
key. Normally, the value of BootExecute is

autocheck autochk *

In other words, every time the OS boots, one of the first things it
does, is go out and see if "chkdsk" needs to run.

PowerQuest changes that command to something like this.

autocheck xmnt2001 /bat=C:\WINNT\system32\PQ_BATCH.PQB ...

What that means is, the autocheck program, calls whatever executable is tacked
onto the end of the command string. At the end of that command execution,
is another occurrence of

autocheck autochk *

so that as the system is coming up, the normal chkdsk activity will be
triggered properly if it is needed.

So the "autocheck xmnt2001" is what causes xmnt2001 to execute.
It's an overloading of the disk check sequence, that they use
for their purposes.

*******

That doesn't answer the question, when the xmnt2001 program is called,
as to why it insists that some of your kernel files are missing. The
PQ_BATCH file is primarily concerned with the queued up work to be done.
In your case, the PQ_BATCH file could be empty (i.e. the Partition Magic
script has been completed). A pointer to the PQ_DEBUG file is also passed,
but I suspect that is for the purpose of writing to the file, and adding
the results of whatever it has done recently.

Somehow, it knows what disk is going to boot. And it is looking at that
disk for what it thinks the boot loader is going to need. I can see
IO.SYS and NTLDR named in xmnt2001.exe for example. I might have missed
some.

Now, this old KB article, has exactly the same error message text, and
the missing file is NTLDR. The claim is, NTLDR in this case, can't be
found due to some MFT (master file table) corruption. If you know the
partition in question is readable (you've been able to read it with some
other OS, Windows or Linux based), then you can probably discount that.
You'd think, if some software was looking for NTLDR, it would be
mentioned by name.

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

In terms of the files on the C: drive of my VirtualPC session, this
is what Win2K has to offer

AUTOEXEC.BAT 0 bytes
CONFIG.SYS 0 bytes
IO.SYS 0 bytes
MSDOS.SYS 0 bytes
NTDETECT.COM 34724 bytes
arcldr.exe 150528 bytes
arcsetup.exe 163840 bytes (arc refers to the entry format in boot.ini)
boot.ini 192 bytes
ntldr 214432 bytes

You shouldn't discount all those files, as some of them are there for
compatibility reasons. Even when a file like that has zero size, it is
there so if some piece of software goes looking for it, the file exists
and passes an existence check. NTLDR is the boot loader. The "arc" things
may have something to do with multi(0)disk(0)rdisk(0)partition(1)\WINDOWS .

So I'm not 100% convinced, that changing the BootExecute registry entry,
is going to fix anything. It might change the source of the next error
message you get. The next message could come from the normal boot sequence
for example.

To change the registry, you'd need an off-line registry editor. (I understand
you can use the registry editor in a running Windows OS, to make changes to
a file brought over from another system, but I've never tried that before.)
There are a number of entries like this, in ControlSet001, ControlSet002, and
also the CurrentControlSet. Something like this.

HKLM\System\CurrentControlSet\Control\Session Manager\

BootExecute

The registry file itself, would be one of five of them in here.

WINNT\system32\config
SYSTEM <---- one of five registry files

What you'd be seeking to do, is change the BootExecute entry back to

autocheck autochk *

from the current value, which might look like

blah blah blah autocheck autochk *

I was hoping that the foulup that using the registry for this
purpose would cause, would result in a few web pages with
recipes for getting out of a "Partition Magic mess". So far,
I'm not finding anything useful. PowerQuest was bought out
by Symantec, and searching on your error message against
that site, isn't getting me anywhere.

Now, I tried queueing up a partition shrink in my VPC session,
and didn't find the stuff I thought I'd find. Like the registry
entry wasn't there. It looks like the registry entry has already
been overwritten with the "autocheck autochk *" value, and yet
the xmnt2001 hasn't had a chance to run yet.

Anyway, I thought I'd give a progress report. Not much so far.

So, things you can try are:

1) Inspect the Win2K partition, to see if the file system is intact.
2) Check for things like IO.SYS and ntldr, to see if they're there.
3) Look at the boot.ini and see if there is a valid arc in there.
Boot.ini is a text file, and the hard part is permissions when
in Windows. Since I was doing my inspecting with a Linux LiveCD,
permissions aren't a problem there :-)

Paul
From: Puddin' Man on 13 Jun 2010 17:56
On Sun, 13 Jun 2010 04:44:30 -0400, Paul <nospam(a)needed.com> wrote:

>I've only made a little program on the "what triggers XMNT2001.exe" problem.
>
>I set up a VirtualPC session, put a fixed size virtual disk in it, and copied
>over my Win2K image using Partition Magic (installed inside the virtual session).
>I was hoping I'd be able to scan the fixed size virtual disk and find the call
>to that program. I picked a pretty small VHD virtual disk size, so the search
>would not take forever.
>
>I have one idea why a scan of the disk isn't finding the call. And this
>stinks. The file name is stored in "double byte format", which is
>why it isn't being detected in a search. X_M_N_T_2_0_0_1, where the
>underscores are hex 0x00 values. Just to give you an idea what other
>ways there are of doing it.

It wasn't stored that way when you/we originally found it (or was
it?), and I
was (Win7) searching for the text string inside the file.

>Now, I didn't really make much progress that way. I did discover two
>key files.
>
>WINNT\system32\PQ_BATCH.PQB
>WINNT\system32\PQ_DEBUG.TXT

I've seen these in recent weeks.

>Partition Magic appears to be hooking into a registry entry called
>BootExecute. That is what the PQ_DEBUG.TXT file is telling me,
>because it records the before and after values of that registry
>key. Normally, the value of BootExecute is
>
> autocheck autochk *
>
>In other words, every time the OS boots, one of the first things it
>does, is go out and see if "chkdsk" needs to run.
>
>PowerQuest changes that command to something like this.
>
> autocheck xmnt2001 /bat=C:\WINNT\system32\PQ_BATCH.PQB ...
>
>What that means is, the autocheck program, calls whatever executable is tacked
>onto the end of the command string. At the end of that command execution,
>is another occurrence of
>
> autocheck autochk *
>
>so that as the system is coming up, the normal chkdsk activity will be
>triggered properly if it is needed.

Strictly speaking, if PM "thinks" it needs to be executed.

Incidently, which ver. of PM are your running? Ver. 6? 7? 8?

>So the "autocheck xmnt2001" is what causes xmnt2001 to execute.
>It's an overloading of the disk check sequence, that they use
>for their purposes.
>
>*******
>
>That doesn't answer the question, when the xmnt2001 program is called,
>as to why it insists that some of your kernel files are missing. The
>PQ_BATCH file is primarily concerned with the queued up work to be done.
>In your case, the PQ_BATCH file could be empty (i.e. the Partition Magic
>script has been completed). A pointer to the PQ_DEBUG file is also passed,
>but I suspect that is for the purpose of writing to the file, and adding
>the results of whatever it has done recently.
>
>Somehow, it knows what disk is going to boot. And it is looking at that
>disk for what it thinks the boot loader is going to need. I can see
>IO.SYS and NTLDR named in xmnt2001.exe for example. I might have missed
>some.
>
>Now, this old KB article, has exactly the same error message text, and
>the missing file is NTLDR. The claim is, NTLDR in this case, can't be
>found due to some MFT (master file table) corruption. If you know the
>partition in question is readable (you've been able to read it with some
>other OS, Windows or Linux based), then you can probably discount that.
>You'd think, if some software was looking for NTLDR, it would be
>mentioned by name.
>
>http://support.microsoft.com/kb/176968
>
>In terms of the files on the C: drive of my VirtualPC session, this
>is what Win2K has to offer
>
> AUTOEXEC.BAT 0 bytes
> CONFIG.SYS 0 bytes
> IO.SYS 0 bytes
> MSDOS.SYS 0 bytes
> NTDETECT.COM 34724 bytes
> arcldr.exe 150528 bytes
> arcsetup.exe 163840 bytes (arc refers to the entry format in boot.ini)
> boot.ini 192 bytes
> ntldr 214432 bytes
>
>You shouldn't discount all those files, as some of them are there for
>compatibility reasons. Even when a file like that has zero size, it is
>there so if some piece of software goes looking for it, the file exists
>and passes an existence check. NTLDR is the boot loader. The "arc" things
>may have something to do with multi(0)disk(0)rdisk(0)partition(1)\WINDOWS .
>
>So I'm not 100% convinced, that changing the BootExecute registry entry,
>is going to fix anything. It might change the source of the next error
>message you get. The next message could come from the normal boot sequence
>for example.
>
>To change the registry, you'd need an off-line registry editor. (I understand
>you can use the registry editor in a running Windows OS, to make changes to
>a file brought over from another system, but I've never tried that before.)

'Tis just "Load Hive" from Regedit. Running multi-boot for years, I've
had occasion to use it now and then. Works well so long as you are
fully familiar with drive letters currently in use.

>There are a number of entries like this, in ControlSet001, ControlSet002, and
>also the CurrentControlSet. Something like this.
>
> HKLM\System\CurrentControlSet\Control\Session Manager\
>
> BootExecute
>
>The registry file itself, would be one of five of them in here.
>
> WINNT\system32\config
> SYSTEM <---- one of five registry files
>
>What you'd be seeking to do, is change the BootExecute entry back to
>
> autocheck autochk *
>
>from the current value, which might look like
>
> blah blah blah autocheck autochk *

I doctored BootExecute with "Load Hive" a week or 2 ago when
I found the issue running searches on xmnt2001.

>I was hoping that the foulup that using the registry for this
>purpose would cause, would result in a few web pages with
>recipes for getting out of a "Partition Magic mess". So far,
>I'm not finding anything useful. PowerQuest was bought out
>by Symantec, and searching on your error message against
>that site, isn't getting me anywhere.

Symantec declines to support PM in any way/fashion (sigh).

>Now, I tried queueing up a partition shrink in my VPC session,
>and didn't find the stuff I thought I'd find. Like the registry
>entry wasn't there. It looks like the registry entry has already
>been overwritten with the "autocheck autochk *" value, and yet
>the xmnt2001 hasn't had a chance to run yet.

Did it que up a .bat to run on next boot?

>Anyway, I thought I'd give a progress report. Not much so far.
>
>So, things you can try are:
>
>1) Inspect the Win2K partition, to see if the file system is intact.

It was not. Chkdsk/f genned about 9500 lines of notes/corrections. I'm
reasonably certain that Recovery Console buggered my partition as
I *used* to know almost exactly what was stored there.

>2) Check for things like IO.SYS and ntldr, to see if they're there.

That's curious. I don't find these files either on the i5 partition
or on the P4 partition (now running) from which it was copied.

>3) Look at the boot.ini and see if there is a valid arc in there.
> Boot.ini is a text file, and the hard part is permissions when
> in Windows. Since I was doing my inspecting with a Linux LiveCD,
> permissions aren't a problem there :-)

Heah 'tis. See what you think:

[boot loader]
timeout=6
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="MT P1: NT Workstation
Version 4.00"
multi(0)disk(0)rdisk(0)partition(1)\WINNT="MT P1: NT Workstation
Version 4.00 [VGA mode]" /basevideo /sos
[operating systems]
[operating systems]
[operating systems]
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="MT P1: NT Workstation
Version 4.00 (#1)"
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="MT P1: NT Workstation
Version 4.00 (#2)"

I suppose I'll jimmy-a-disk and attempt to boot W2k again on i5, but I
doubt my
buggered partition will be anything save more trouble. Will let you
know.

I'm composing this with a new and strange version of Ultraedit on the
Win7 system,
which destroys my eyes. Hope it all looks legible.

Thanks,
P
From: Paul on 13 Jun 2010 20:53
Puddin' Man wrote:
> On Sun, 13 Jun 2010 04:44:30 -0400, Paul <nospam(a)needed.com> wrote:
>
>> is another occurrence of
>>
>> autocheck autochk *
>>
>> so that as the system is coming up, the normal chkdsk activity will be
>> triggered properly if it is needed.
>
> Strictly speaking, if PM "thinks" it needs to be executed.
>
> Incidently, which ver. of PM are your running? Ver. 6? 7? 8?

PM7. The XMNT things seem to have a version per PM release.
So there is a XMNT2002, XMNT2001, and I think a plain XMNT.
XMNT2001 is for PM7.

>>
>> To change the registry, you'd need an off-line registry editor. (I understand
>> you can use the registry editor in a running Windows OS, to make changes to
>> a file brought over from another system, but I've never tried that before.)
>
> 'Tis just "Load Hive" from Regedit. Running multi-boot for years, I've
> had occasion to use it now and then. Works well so long as you are
> fully familiar with drive letters currently in use.
>

So if you need to then, you shouldn't have a problem checking it out.

>
> I doctored BootExecute with "Load Hive" a week or 2 ago when
> I found the issue running searches on xmnt2001.
>

>
> Did it que up a .bat to run on next boot?
>

In the BootExecute key (according to the info logged in PQ_DEBUG.txt,
the call to XMNT2001 includes a /bat option, and the contents of
PQ_BATCH.PQB contains information for use by XMNT2001. It isn't a
..bat file for the OS or anything. It's a terse set of commands
of the things to be done by XMNT2001. In my case, in my attempted
test, it was to shrink my FAT32 test partition by a small amount.
PowerQuest made the file in a human readable format, which is
a good thing.

>> So, things you can try are:
>>
>> 1) Inspect the Win2K partition, to see if the file system is intact.
>
> It was not. Chkdsk/f genned about 9500 lines of notes/corrections. I'm
> reasonably certain that Recovery Console buggered my partition as
> I *used* to know almost exactly what was stored there.
>

So then I guess it's pretty hard now to tell whether some kernel file
(ntldr) was missing or not.

>> 2) Check for things like IO.SYS and ntldr, to see if they're there.
>
> That's curious. I don't find these files either on the i5 partition
> or on the P4 partition (now running) from which it was copied.

I would have expected an ntldr, because that is part of booting Win2K.
I'm not so sure about the others. I have files going back to Win98
hanging around here, and I can never be sure about anything.

>
>> 3) Look at the boot.ini and see if there is a valid arc in there.
>> Boot.ini is a text file, and the hard part is permissions when
>> in Windows. Since I was doing my inspecting with a Linux LiveCD,
>> permissions aren't a problem there :-)
>
> Heah 'tis. See what you think:
>
> [boot loader]
> timeout=6
> default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
> [operating systems]
> multi(0)disk(0)rdisk(0)partition(1)\WINNT="MT P1: NT Workstation
> Version 4.00"
> multi(0)disk(0)rdisk(0)partition(1)\WINNT="MT P1: NT Workstation
> Version 4.00 [VGA mode]" /basevideo /sos
> [operating systems]
> [operating systems]
> [operating systems]
> [operating systems]
> multi(0)disk(0)rdisk(0)partition(1)\WINNT="MT P1: NT Workstation
> Version 4.00 (#1)"
> [operating systems]
> multi(0)disk(0)rdisk(0)partition(1)\WINNT="MT P1: NT Workstation
> Version 4.00 (#2)"
>
> I suppose I'll jimmy-a-disk and attempt to boot W2k again on i5, but I
> doubt my
> buggered partition will be anything save more trouble. Will let you
> know.
>
> I'm composing this with a new and strange version of Ultraedit on the
> Win7 system,
> which destroys my eyes. Hope it all looks legible.
>
> Thanks,
> P

It's every bit as legible as my text is :-)

My boot.ini files have always been pretty simple. Your file "looks"
like a boot.ini. I doubt I could explain where all the entries came
from.

Paul
From: Puddin' Man on 14 Jun 2010 23:06
On Sun, 13 Jun 2010 20:53:38 -0400, Paul <nospam(a)needed.com> wrote:

Lets sub-title this message "Mea Culpa". :-)

> AUTOEXEC.BAT 0 bytes
> CONFIG.SYS 0 bytes
> IO.SYS 0 bytes
> MSDOS.SYS 0 bytes
> NTDETECT.COM 34724 bytes
> arcldr.exe 150528 bytes
> arcsetup.exe 163840 bytes (arc refers to the entry format in boot.ini)
> boot.ini 192 bytes
> ntldr 214432 bytes

As mentioned, when I didn't find most of these on the source partition,
I discounted the fact that they weren't on the test partition. Even
thought maybe they were NT-required but perhaps not W2k-required.

Turns out I found them all on the C: drive of the primary disk on
the P4 system. Evidently it used those to get the boot off the
ground, then finished the boot wherever boot.ini pointed it
to. There were/are 3+ bootable part's on the P4 system, all W2k sp4.

So I copied the above files to a thumb drive, booted Win7
on the i5 sys, added them to the test partition, and it
attempted to boot. Voila!

I can still hardly believe there was no message about
ntldr/detect, etc being missing.

It really (and finally!) attempted to boot W2k: no
ambiguity whatsoever. Didn't get far, though. Normal
boot got me the usual logo, etc and a message telling me
how to re-allocate a page-file, then it crashed. Safe
mode loaded some drivers and crashed. But, with a
damaged partition, I didn't expect much.

I don't remember having to add ntldr, etc when I transferred
the whole shmear to the disk when I brought the P4 system
up in 2006. But my memory is not what it used to be.

Anyway, many, many thanks to Paul for very patient help in
getting W2k to boot on the new (i5) system. Perhaps I'll
be able to do something with it some day.

Salut,
Puddin'

"Law Without Equity Is No Law At All. It Is A Form Of Jungle Rule."

First  |  Prev  | 
Pages: 1 2 3
Prev: Not Asus-specific: SATA & AHCI
Next: Intermittent lockups, need troubleshooting advice