Z
zigzagph
Hello all. Could someone please help me solve this issue.
Here is my situation, I have an XPe image created from FP2007 that is
relentless to boot from an AHCI enabled drive. It will boot all day
long running in Basic mode but when I enable AHCI I get the infamous
Stop 7B bug check.
Here is a little background of the system I am configuring and what I
have tried. The motherboard is an Asus P5B-VM with the G965 chipset,
2gig RAM, Core duo, JMicron SATA.
First off I imported the SATA drivers into custom component and then
into my database with no errors being displayed throughout its creation
in Component Designer. Then I imported the PMQ into TD which picked up
the SATA component and all of its dependencies. Satisfied the
dependencies and built the image with no errors. Time for deployment. I
partitioned and formated the target drive using the oem drivers buy a
custom PE and the F6 during install and still no errors everything
looks good. Reboot.... Stop 7B! So I hooked up the trusty ole Kernel
Debugger and got some more info.
Microsoft (R) Windows Debugger Version 6.5.0003.7
Copyright (c) Microsoft Corporation. All rights reserved.
Using 1394 for debugging
Opened \\.\DBG1394_INSTANCE10
Waiting to reconnect...
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is:
C:\WINDOWS\Symbols;srv*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible
Built by: 2600.xpsp.050301-1521
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0
System Uptime: not available
*** Fatal System Error: 0x0000007b
(0xF789E524,0xC0000034,0x00000000,0x00000000)
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been
invoked.
A fatal system error has occurred.
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
...........................
Loading unloaded module list
Loading User Symbols
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7B, {f789e524, c0000034, 0, 0}
Probably caused by : ntkrnlmp.exe ( nt!IopMarkBootPartition+113 )
Followup: MachineOwner
---------
nt!RtlpBreakWithStatusInstruction:
804e2a42 cc int 3
0: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************
INACCESSIBLE_BOOT_DEVICE (7b)
During the initialization of the I/O system, it is possible that the
driver
for the boot device failed to initialize the device that the system is
attempting to boot from, or it is possible for the file system that is
supposed to read that device to either fail its initialization or to
simply
not recognize the data on the boot device as a file system structure
that
it recognizes. In the former case, the argument (#1) is the address of
a
Unicode string data structure that is the ARC name of the device from
which
the boot was being attempted. In the latter case, the argument (#1) is
the
address of the device object that could not be mounted.
If this is the initial setup of the system, then this error can occur
if
the system was installed on an unsupported disk or SCSI controller.
Note
that some controllers are supported only by drivers which are in the
Windows
Driver Library (WDL) which requires the user to do a custom install.
See
the Windows Driver Library for more information.
This error can also be caused by the installation of a new SCSI adapter
or
disk controller or repartitioning the disk with the system partition.
If
this is the case, on x86 systems the boot.ini file must be edited or on
ARC
systems setup must be run. See the "Advanced Server System
Administrator's
User Guide" for information on changing boot.ini.
If the argument is a pointer to an ARC name string, then the format of
the
first two (and in this case only) longwords will be:
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer;
That is, the first longword will contain something like 00800020 where
20
is the actual length of the Unicode string, and the next longword will
contain the address of buffer. This address will be in system space,
so
the high order bit will be set.
If the argument is a pointer to a device object, then the format of the
first
word will be:
USHORT Type;
That is, the first word will contain a 0003, where the Type code will
ALWAYS
be 0003.
Note that this makes it immediately obvious whether the argument is a
pointer
to an ARC name string or a device object, since a Unicode string can
never
have an odd number of bytes, and a device object will always have a
Type
code of 3.
Arguments:
Arg1: f789e524, Pointer to the device object or Unicode string of ARC
name
Arg2: c0000034
Arg3: 00000000
Arg4: 00000000
Debugging Details:
------------------
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x7B
LAST_CONTROL_TRANSFER: from 805360c7 to 804e2a42
STACK_TEXT:
f789e08c 805360c7 00000003 f789e3e8 00000000
nt!RtlpBreakWithStatusInstruction
f789e0d8 80536b9e 00000003 00000000 80087000
nt!KiBugCheckDebugBreak+0x19
f789e4b8 805371b2 0000007b f789e524 c0000034 nt!KeBugCheck2+0x574
f789e4d8 806ca58f 0000007b f789e524 c0000034 nt!KeBugCheckEx+0x1b
f789e640 806b7f0b 80087000 00000000 80087000
nt!IopMarkBootPartition+0x113
f789e690 806adf9d 80087000 f789e6ac 00034000
nt!IopInitializeBootDrivers+0x4ba
f789e838 806af023 80087000 00000000 897e5788 nt!IoInitSystem+0x712
f789edac 80574128 80087000 00000000 00000000
nt!Phase1Initialization+0xac7
f789eddc 804efc71 806ae7d0 80087000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
nt!IopMarkBootPartition+113
806ca58f 8d85e4feffff lea eax,[ebp-0x11c]
SYMBOL_STACK_INDEX: 4
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!IopMarkBootPartition+113
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 42251085
STACK_COMMAND: kb
FAILURE_BUCKET_ID: 0x7B_nt!IopMarkBootPartition+113
BUCKET_ID: 0x7B_nt!IopMarkBootPartition+113
Followup: MachineOwner
---------
I will post the !devnode 0 1 shortly.
Has anyone had any problems using AHCI or Native Command Queuing
issues? Is AHCI supported in XPe? Does this sound like a Sata driver
problem or a ntloader issue? Any help would be greatly appreciated.
Cheers
PH
Here is my situation, I have an XPe image created from FP2007 that is
relentless to boot from an AHCI enabled drive. It will boot all day
long running in Basic mode but when I enable AHCI I get the infamous
Stop 7B bug check.
Here is a little background of the system I am configuring and what I
have tried. The motherboard is an Asus P5B-VM with the G965 chipset,
2gig RAM, Core duo, JMicron SATA.
First off I imported the SATA drivers into custom component and then
into my database with no errors being displayed throughout its creation
in Component Designer. Then I imported the PMQ into TD which picked up
the SATA component and all of its dependencies. Satisfied the
dependencies and built the image with no errors. Time for deployment. I
partitioned and formated the target drive using the oem drivers buy a
custom PE and the F6 during install and still no errors everything
looks good. Reboot.... Stop 7B! So I hooked up the trusty ole Kernel
Debugger and got some more info.
Microsoft (R) Windows Debugger Version 6.5.0003.7
Copyright (c) Microsoft Corporation. All rights reserved.
Using 1394 for debugging
Opened \\.\DBG1394_INSTANCE10
Waiting to reconnect...
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is:
C:\WINDOWS\Symbols;srv*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible
Built by: 2600.xpsp.050301-1521
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0
System Uptime: not available
*** Fatal System Error: 0x0000007b
(0xF789E524,0xC0000034,0x00000000,0x00000000)
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been
invoked.
A fatal system error has occurred.
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
...........................
Loading unloaded module list
Loading User Symbols
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7B, {f789e524, c0000034, 0, 0}
Probably caused by : ntkrnlmp.exe ( nt!IopMarkBootPartition+113 )
Followup: MachineOwner
---------
nt!RtlpBreakWithStatusInstruction:
804e2a42 cc int 3
0: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************
INACCESSIBLE_BOOT_DEVICE (7b)
During the initialization of the I/O system, it is possible that the
driver
for the boot device failed to initialize the device that the system is
attempting to boot from, or it is possible for the file system that is
supposed to read that device to either fail its initialization or to
simply
not recognize the data on the boot device as a file system structure
that
it recognizes. In the former case, the argument (#1) is the address of
a
Unicode string data structure that is the ARC name of the device from
which
the boot was being attempted. In the latter case, the argument (#1) is
the
address of the device object that could not be mounted.
If this is the initial setup of the system, then this error can occur
if
the system was installed on an unsupported disk or SCSI controller.
Note
that some controllers are supported only by drivers which are in the
Windows
Driver Library (WDL) which requires the user to do a custom install.
See
the Windows Driver Library for more information.
This error can also be caused by the installation of a new SCSI adapter
or
disk controller or repartitioning the disk with the system partition.
If
this is the case, on x86 systems the boot.ini file must be edited or on
ARC
systems setup must be run. See the "Advanced Server System
Administrator's
User Guide" for information on changing boot.ini.
If the argument is a pointer to an ARC name string, then the format of
the
first two (and in this case only) longwords will be:
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer;
That is, the first longword will contain something like 00800020 where
20
is the actual length of the Unicode string, and the next longword will
contain the address of buffer. This address will be in system space,
so
the high order bit will be set.
If the argument is a pointer to a device object, then the format of the
first
word will be:
USHORT Type;
That is, the first word will contain a 0003, where the Type code will
ALWAYS
be 0003.
Note that this makes it immediately obvious whether the argument is a
pointer
to an ARC name string or a device object, since a Unicode string can
never
have an odd number of bytes, and a device object will always have a
Type
code of 3.
Arguments:
Arg1: f789e524, Pointer to the device object or Unicode string of ARC
name
Arg2: c0000034
Arg3: 00000000
Arg4: 00000000
Debugging Details:
------------------
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x7B
LAST_CONTROL_TRANSFER: from 805360c7 to 804e2a42
STACK_TEXT:
f789e08c 805360c7 00000003 f789e3e8 00000000
nt!RtlpBreakWithStatusInstruction
f789e0d8 80536b9e 00000003 00000000 80087000
nt!KiBugCheckDebugBreak+0x19
f789e4b8 805371b2 0000007b f789e524 c0000034 nt!KeBugCheck2+0x574
f789e4d8 806ca58f 0000007b f789e524 c0000034 nt!KeBugCheckEx+0x1b
f789e640 806b7f0b 80087000 00000000 80087000
nt!IopMarkBootPartition+0x113
f789e690 806adf9d 80087000 f789e6ac 00034000
nt!IopInitializeBootDrivers+0x4ba
f789e838 806af023 80087000 00000000 897e5788 nt!IoInitSystem+0x712
f789edac 80574128 80087000 00000000 00000000
nt!Phase1Initialization+0xac7
f789eddc 804efc71 806ae7d0 80087000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
nt!IopMarkBootPartition+113
806ca58f 8d85e4feffff lea eax,[ebp-0x11c]
SYMBOL_STACK_INDEX: 4
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!IopMarkBootPartition+113
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 42251085
STACK_COMMAND: kb
FAILURE_BUCKET_ID: 0x7B_nt!IopMarkBootPartition+113
BUCKET_ID: 0x7B_nt!IopMarkBootPartition+113
Followup: MachineOwner
---------
I will post the !devnode 0 1 shortly.
Has anyone had any problems using AHCI or Native Command Queuing
issues? Is AHCI supported in XPe? Does this sound like a Sata driver
problem or a ntloader issue? Any help would be greatly appreciated.
Cheers
PH