Hi,
I've followed the how-to and I get the error report from WinDbg attached to
this mail. I'd appreciate any information you can give me.
It seems like sanbootconf driver doesn't load.
Daniel.
Waiting to reconnect...
Connected to Windows XP 2600 x86 compatible target at (Mon Sep 26 14:50:42.625
2011 (UTC + 2:00)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
ntkrpamp.exe -
Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible
Built by: 2600.xpsp.080413-2111
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
System Uptime: not available
Break instruction exception - code 80000003 (first chance)
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
ntkrpamp.exe -
nt!DbgBreakPoint:
8052b5d0 cc int 3
kd> g
*** Fatal System Error: 0x0000007b
(0xF79E9524,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.
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7B, {f79e9524, c0000034, 0, 0}
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
Probably caused by : ntkrpamp.exe ( nt!KeRegisterBugCheckReasonCallback+77c )
Followup: MachineOwner
---------
nt!DbgBreakPointWithStatus+0x4:
8052b5dc 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: f79e9524, Pointer to the device object or Unicode string of ARC name
Arg2: c0000034
Arg3: 00000000
Arg4: 00000000
Debugging Details:
------------------
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set
symbol path and load symbols.
MODULE_NAME: nt
FAULTING_MODULE: 804d7000 nt
DEBUG_FLR_IMAGE_TIMESTAMP: 4802516a
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x7B
LAST_CONTROL_TRANSFER: from 804f99e4 to 8052b5dc
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
f79e90d8 804f99e4 00000003 00000000 80084000 nt!DbgBreakPointWithStatus+0x4
f79e94b8 804f9f33 0000007b f79e9524 c0000034
nt!KeRegisterBugCheckReasonCallback+0x77c
f79e94d8 80699111 0000007b f79e9524 c0000034 nt!KeBugCheckEx+0x1b
f79e9640 8069d232 80084000 00000000 80084000 nt!NlsOemLeadByteInfo+0x19ff1
f79e9690 80699f70 80084000 f79e96ac 00034000 nt!IoReportHalResourceUsage+0x1cc2
f79e9838 806983d3 80084000 00000000 861c43d8 nt!NlsOemLeadByteInfo+0x1ae50
f79e9dac 805cff64 80084000 00000000 00000000 nt!NlsOemLeadByteInfo+0x192b3
f79e9ddc 805460de 8069790c 80084000 00000000
nt!PsRemoveCreateThreadNotifyRoutine+0x214
00000000 00000000 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x72e
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KeRegisterBugCheckReasonCallback+77c
804f99e4 e85f830000 call nt!ZwYieldExecution+0xa64 (80501d48)
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt!KeRegisterBugCheckReasonCallback+77c
FOLLOWUP_NAME: MachineOwner
IMAGE_NAME: ntkrpamp.exe
BUCKET_ID: WRONG_SYMBOLS
Followup: MachineOwner
---------
_______________________________________________
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
