CLASSPNP.SYS load hang in kernel debugger

S

SAC

Hello,

I have a headless system attempting to boot from an on-board IDE
CompactFlash adapter. Using an RS-232 kernel debugger, I see it hangs
during loading of CLASSPNP.SYS. I think this is pre-FBA.

I assume this is probably something like the 7B error, but I've
definately got the IDE controller, Primary IDE, Secondary IDE, etc.
This same CF image will boot fine on a headed test PC.

Ran TA.EXE on target device, seems to find relevant stuff. Can't run
TAP.EXE b/c there is no real IDE connector on board, only the
CompactFlash adapter.

Here is the output from the debugger:



ModLoad: 804d4000 806c6980 ntoskrnl.exe
Windows XP Kernel Version 2600 UP Free x86 compatible
Built by: 2600.xpsp1.020828-1920
Kernel base = 0x804d4000 PsLoadedModuleList = 0x8054be30
System Uptime: not available
Loaded dbghelp extension DLL
Loaded ext extension DLL
Loaded exts extension DLL
Loaded kext extension DLL
Loaded kdexts extension DLL
Force unload of ntoskrnl.exe
ModLoad: 804d4000 806c6980 ntoskrnl.exe
ModLoad: 806c7000 806dfc00 hal.dll
ModLoad: fc9bb000 fc9bcb80 kdcom.dll
ModLoad: fc8cb000 fc8ce000 BOOTVID.dll
ModLoad: fc4bb000 fc4ca600 pci.sys
ModLoad: fc4cb000 fc4d3c00 isapnp.sys
ModLoad: fc4db000 fc4e4280 MountMgr.sys
ModLoad: fc47b000 fc499880 ftdisk.sys
ModLoad: fc9bd000 fc9be100 WMILIB.SYS
ModLoad: fc73b000 fc73f900 PartMgr.sys
ModLoad: fc9bf000 fc9c0280 intelide.sys
ModLoad: fc743000 fc748c80 PCIIDEX.SYS
ModLoad: fca83000 fca83d00 pciide.sys
ModLoad: fc4eb000 fc4f7000 volsnap.sys
ModLoad: fc465000 fc47a380 atapi.sys
ModLoad: fc441000 fc464700 Fastfat.sys
ModLoad: fc42d000 fc440780 KSecDD.sys
ModLoad: fc404000 fc42ce80 NDIS.sys
ModLoad: fc3ea000 fc403680 Mup.sys
ModLoad: fc4fb000 fc503400 disk.sys
ModLoad: fc50b000 fc516500 CLASSPNP.SYS


Nothing happens after this last line, it just hangs.

Let me know if anyone has any ideas or questions.

Thanks!
 
S

Slobodan Brcin \(eMVP\)

Hello,

Try command> !devnode 0 1
Also give us results from> analyze -v

Since you were able to use remote debugger then what you see on this list is
only list of loaded modules not an order in which they were loaded by ntldr.

On the other hand classpnp.sys is not a driver but rather a library used by
disk.sys.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
K

KM

SAC,

As you may already know, the classpnp.sys is the PnP (Kernel-mode).

I have run into similar issues with the hang on ClassPnP.sys.
I cannot tell for all the possibilities but in my case it was missing a
proper disk.sys driver. Basically I accidentially used a platform macro (and
XPe database) from another dev.machine where I had a different disk support
(a diffirent scsi driver). As far as I could understand the issue was that
ClassPnP.sys (PnP) was trying to pick up the wrong driver and, of course,
that driver hung. This is close to 7B, I guess.

Anyway... TAP input would be a cure for you as it supposes you run XP on the
target. If you can't get it, you will need to have to include all the
drivers manually.
Start with include all the disk driver and see if it helps.

Also, you mentined you only got the CF adapter. Do you then have a (custom)
flash driver in your image with the start at boot (StartType=0)?

KM
 
S

SAC

Hello Slobodan,

Well I'm trying to use WinDBG.exe ~ this is where I am getting the
output across the COM port for the messages, in the command window.

In the pane where I should be able to enter the commands you
suggested, I cannot enter commands and it has the text "Debuggee not
connected".

Any advice on how to establish a real connection where I can enter
your suggested commands?

Thanks,
SAC
 
S

Slobodan Brcin \(eMVP\)

SAC,

If you can see 7B error text in your windbg then you have already
established connection.
If not.
Make sure that com speed and ports are ok.

You can always break in with Ctlr+C even before 7B error.

If your debugger can't work while you start XPe. (looses connection)
Try starting debugger after the error is reported.
Or disable USB legacy support in BIOS. (This is known problem by MS but they
never investigated it)

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
S

SAC

Slobodan,

Thanks again for your help. Please note I have not actually seen a
7B error, it only seemed like maybe my symptoms were 7B related.

I was only able to get WinDGG to recognize a connected debuggee when I
selected Debug->KernelConnection->Cycle Initial Break. Otherwise,
the output in the command window is exactly what I posted earlier.

So after the initial break, I ran your suggested commands and posted
the results below. Please note there is one PCI device which I do
not have a driver for, but it is not a device necessary for booting
(it's a motion controller). Does this matter?

Here is the output:


Break instruction exception - code 80000003 (first chance)
*******************************************************************************
*
*
* You are seeing this message because you pressed either
*
* CTRL+C (if you run kd.exe) or,
*
* CTRL+BREAK (if you run WinDBG),
*
* on your debugger machine's keyboard.
*
*
*
* THIS IS NOT A BUG OR A SYSTEM CRASH
*
*
*
* If you did not intend to break into the debugger, press the "g" key,
then *
* press the "Enter" key now. This message might immediately reappear.
If it *
* does, press "g" and "Enter" again.
*
*
*
*******************************************************************************
nt!RtlpBreakWithStatusInstruction:
805103fa cc int 3
kd> !devnode 0 1
Dumping IopRootDeviceNode (= 00000000)
00000000: Could not read device node
kd>
Dumping IopRootDeviceNode (= 00000000)
00000000: Could not read device node
kd> !analyze -v
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
.....................
Loading unloaded module list

Loading User Symbols
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------


FAULTING_IP:
nt!RtlpBreakWithStatusInstruction+0
805103fa cc int 3

EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff)
ExceptionAddress: 805103fa (nt!RtlpBreakWithStatusInstruction)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: 80541ec0
Parameter[2]: 80541d50

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more
arguments are invalid

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x0

LAST_CONTROL_TRANSFER: from 8069208b to 805103fa

STACK_TEXT:
80541d68 8069208b 00000001 8054a6a0 ffdff120
nt!RtlpBreakWithStatusInstruction
80541ee8 8068624c 00000000 00000015 8003fc00
nt!ExpInitializeExecutive+0x302
80541f3c 80691b23 8054a900 8054a6a0 80542200
nt!KiInitializeKernel+0x29e
00000000 00000000 00000000 00000000 00000000 nt!KiSystemStartup+0x2bf


FOLLOWUP_IP:
nt!RtlpBreakWithStatusInstruction+0
805103fa cc int 3

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!RtlpBreakWithStatusInstruction+0

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3d6de35c

STACK_COMMAND: kb

BUCKET_ID: 0x0_nt!RtlpBreakWithStatusInstruction+0

Followup: MachineOwner
---------
 
S

Slobodan Brcin \(eMVP\)

SAC,

This log is empty you probably break in XPe too early.

I suggested you to keep closed windbg. After XPe stop loading (give it some
time). You should run windbg, and it should not require you to cycle
connection (it should be established).

You problem is not 7B related since no drivers are loaded yet, not even for
PCI bus. This is what !devnode is used for (it will show you relation
between loaded drivers).

There is another possibility for XPe to stop so early in kernel, and that is
if you have used /BREAK switch in boot.ini.
DO NOT USE /BREAK switch from boot.ini
Please note there is one PCI device which I do
not have a driver for, but it is not a device necessary for booting
(it's a motion controller). Does this matter?

In your case it is irrelevant since there is no lower drivers that are
needed for XPe even to enumerate your card, or any card for that matter.


Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SAC said:
Slobodan,

Thanks again for your help. Please note I have not actually seen a
7B error, it only seemed like maybe my symptoms were 7B related.

I was only able to get WinDGG to recognize a connected debuggee when I
selected Debug->KernelConnection->Cycle Initial Break. Otherwise,
the output in the command window is exactly what I posted earlier.

So after the initial break, I ran your suggested commands and posted
the results below. Please note there is one PCI device which I do
not have a driver for, but it is not a device necessary for booting
(it's a motion controller). Does this matter?

Here is the output:


Break instruction exception - code 80000003 (first chance)
****************************************************************************
***
*
*
* You are seeing this message because you pressed either
*
* CTRL+C (if you run kd.exe) or,
*
* CTRL+BREAK (if you run WinDBG),
*
* on your debugger machine's keyboard.
*
*
*
* THIS IS NOT A BUG OR A SYSTEM CRASH
*
*
*
* If you did not intend to break into the debugger, press the "g" key,
then *
* press the "Enter" key now. This message might immediately reappear.
If it *
* does, press "g" and "Enter" again.
*
*
*
****************************************************************************
***
nt!RtlpBreakWithStatusInstruction:
805103fa cc int 3
kd> !devnode 0 1
Dumping IopRootDeviceNode (= 00000000)
00000000: Could not read device node
kd>
Dumping IopRootDeviceNode (= 00000000)
00000000: Could not read device node
kd> !analyze -v
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
....................
Loading unloaded module list

Loading User Symbols
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------


FAULTING_IP:
nt!RtlpBreakWithStatusInstruction+0
805103fa cc int 3

EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff)
ExceptionAddress: 805103fa (nt!RtlpBreakWithStatusInstruction)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: 80541ec0
Parameter[2]: 80541d50

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more
arguments are invalid

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x0

LAST_CONTROL_TRANSFER: from 8069208b to 805103fa

STACK_TEXT:
80541d68 8069208b 00000001 8054a6a0 ffdff120
nt!RtlpBreakWithStatusInstruction
80541ee8 8068624c 00000000 00000015 8003fc00
nt!ExpInitializeExecutive+0x302
80541f3c 80691b23 8054a900 8054a6a0 80542200
nt!KiInitializeKernel+0x29e
00000000 00000000 00000000 00000000 00000000 nt!KiSystemStartup+0x2bf


FOLLOWUP_IP:
nt!RtlpBreakWithStatusInstruction+0
805103fa cc int 3

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!RtlpBreakWithStatusInstruction+0

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3d6de35c

STACK_COMMAND: kb

BUCKET_ID: 0x0_nt!RtlpBreakWithStatusInstruction+0

Followup: MachineOwner
---------
 
S

SAC

KM,

Your description of my problem does sound consistent with what I am
seeing.

The only disk driver I have loaded is the "Disk Drive" which has the
GenDisk. I see a total of 8 Disk Drives components available, you are
suggesting I add them all?

I have no way to run TAP, unfortunately.

The CF adapter on my CPU board is somehow mapped in BIOS to look like
IDE Drive 0. I also have a floppy, and can FDISK and FORMAT the CF
as the C: drive from DOS.

I do not have a custom flash driver with start at boot (StartType=0).
Do you think I might need something like this?

Thanks in advance,
SAC
 
S

Slobodan Brcin \(eMVP\)

SAC,

Have you read my last post?

Your XPe did dot reach driver initialization phase (You don't have even
basic drivers initialized, so it is irrelevant if you entered correct disk
drivers or not).

Since you do things manually:
Read this thread completely it might help you:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=#78YE#vBEHA.684%
40tk2msftngp13.phx.gbl

Start by entering correct kernel/hal pair, then universal support for PCI,
IDE, etc.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
K

KM

SAC,

I think I misled you. Sorry about that.

In the accident with the different platform macro I mentioned ealier I had
the proper disk.sys but I also got a wrong (unnecessary) "FastTrak 376
Controller" which falls into a "SCSI Miniport" driver group category if I
understand correctly.

Although I don't know how that RAID Array controller relates to ClassPnP.sys
and Disk.sys, I know that it has to be supported by BIOS. Since it was not
the case on my test machine, the image hung. The interesting part was that
it was hanging on ClassPnP.sys. I checked that with KD. Since I figured out
the problem pretty quickly I did not spend enough time in KD to understand
why it hung on the ClassPnP.sys.

Now about custom flash driver... I am not a hardware guys so please bear
with my story.
I played with an embedded device that had only CF adapter on the board
(similar setup to yours). Instead of disk.sys a custom Flash driver
(StartType=0, of course) was used there. With the disk.sys the image was
giving me 7B right away. So the point was that depending on your CF adapter
and board (BIOS support) it may be needed for you to use (write) a custom
flash disk driver.

KM
 
K

KM

Slobodan,
Your XPe did dot reach driver initialization phase (You don't have even
basic drivers initialized, so it is irrelevant if you entered correct disk
drivers or not).

May I ask how do you know that?

Konstantin
 
S

Slobodan Brcin \(eMVP\)

Yup of course,

This is the result of his !devnode command from other post in this thread.

kd> !devnode 0 1
Dumping IopRootDeviceNode (= 00000000)
00000000: Could not read device node

If it was a problem with disk.sys.
He should be able to see tree of all lower drivers from groups like Boot Bus
Extender, System Bus Extender, SCSI Miniport.

So this indicates either basic kernel init problem, or who knows what, but
bottom like is that !devnode must work no matter what even if you have two
or three drivers in your image. (But in this case it does not work)

Regards,
Slobodan
 
S

Slobodan Brcin \(eMVP\)

Konstantin,

You problem can be related to fact that some BIOS-es in rare occasions do
not get along with ntdetect.
So disk parameters passed from ntldr to kernel during transition are
missing. (whole disks are missing).
So ARC paths in kernel mode never get assigned since there is no match
between disks seen by BIOS and disks seen by drivers.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
K

KM

Slobodan,

Maybe.

From my (almost user point of you) the cuase was in that FastTrak driver
which is a "SCSI Miniport" driver and lower than the disk driver.
So, I thought that the driver (FastTrak) gets loaded and maybe een
initialized fine (although it does not "work" yet). Then disk.sys/ClassPnP
pair gets loaded and tries to use the lower FastTrak and here it hangs. Is
it wrong understanding? i.e. is it possible scenerio?

Anyway.. I don't have that setup already so can't explore it more.

KM
 
K

KM

Slobodan,

I see it now. I should have read the posts more carefully.
I agree that if it would be a problem with a particular driver, he would see
the tree of all preceding drivers. But he doesn't.

KM
 
S

Slobodan Brcin \(eMVP\)

Konstantin,
So, I thought that the driver (FastTrak) gets loaded and maybe een
initialized fine (although it does not "work" yet). Then disk.sys/ClassPnP
pair gets loaded and tries to use the lower FastTrak and here it hangs. Is
it wrong understanding? i.e. is it possible scenerio?

Since you are seeing 7B error then this scenario is not possible, you would
see various different errors if what you describe was the actual cause.

We have reached NDA point here. Only what I can say without going deeper to
the problem is something that you probably know or at least it is publicly
available:

In DDK 7B error is described under section "Bug Check 0x7B:
INACCESSIBLE_BOOT_DEVICE"

Cause for 7B error can be anything, I have isolated more than 10 different
causes. But one this is constant 7B error is not thrown by any of drivers,
but by ntoskrnl.exe when init phase 0 is complete and when boot disk is
expected to be present and functional.

Regards,
Slobodan

PS:
I'm sick of 7B, c000021a errors. I have been dealing with them for last two
months, day and nights. Hopefully I have solved them all. More testing will
tell.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
K

KM

Slobodan,

I must have confused you (sorry, not much seep and my language gets
confusing)..
I did NOT see the 7B. The imahe wa shanging on "loading" ClassPnP.sys.

If it would be the 7B it would be simpler. (the DDK 7B page is one of my
favorites)

Konstantin
 
S

SAC

KM, Slobodan,

I appreciate your help.

I finally got the debugger to connect normally, I'm not sure which new
component fixed this. Anyway, now the debugger does confirm this is
the 7B error. Below you'll see the results of my !devnode 0 1 and
!analyze -v commands.

Slobadan, I am sorry that 7B is such a pain. What a beast!

If you have any advice for me, it will be very much appreciated.

Thanks,
SAC


Loading User Symbols
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7B, {fc8d2640, c0000034, 0, 0}

Probably caused by : ntoskrnl.exe ( nt!KiBugCheckDebugBreak+19 )

Followup: MachineOwner
---------

nt!RtlpBreakWithStatusInstruction:
805103fa cc int 3
kd> !devnode 0 1
Dumping IopRootDeviceNode (= 0x80e7b008)
DevNode 0x80e7b008 for PDO 0x80e7c430
InstancePath is "HTREE\ROOT\0"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80e7bd28 for PDO 0x80e7be70
InstancePath is "Root\LEGACY_RDPWD\0000"
ServiceName is "RDPWD"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80e7ba48 for PDO 0x80e7bb90
InstancePath is "Root\LEGACY_TDPIPE\0000"
ServiceName is "TDPIPE"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80e7b808 for PDO 0x80e7b950
InstancePath is "Root\LEGACY_TDTCP\0000"
ServiceName is "TDTCP"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80e7b5c8 for PDO 0x80e7b710
InstancePath is "Root\RDPDR\0000"
ServiceName is "rdpdr"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_REGISTRY
DevNode 0x80e7b388 for PDO 0x80e7b4d0
InstancePath is "Root\RDP_KBD\0000"
ServiceName is "TermDD"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
DevNode 0x80e7b148 for PDO 0x80e7b290
InstancePath is "Root\RDP_MOU\0000"
ServiceName is "TermDD"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
DevNode 0x80eb5ee8 for PDO 0x80eb5030
InstancePath is "Root\SYSTEM\0000"
ServiceName is "swenum"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_REGISTRY
DevNode 0x80eb5ca8 for PDO 0x80eb5df0
InstancePath is "Root\SYSTEM\0001"
ServiceName is "update"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
DevNode 0x80eb5970 for PDO 0x80eb5ab8
InstancePath is "ROOT\PCI_HAL\0000"
ServiceName is "\Driver\PCI_HAL"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80e7ad10 for PDO 0x80eb55d0
InstancePath is "PCI_HAL\PNP0A03\0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80e7aad0 for PDO 0x80e7ac18
InstancePath is "Root\*PNP0301\1_0_22_0_32_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80e7a890 for PDO 0x80e7a9d8
InstancePath is "Root\*PNP0400\1_0_20_0_0_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80eb4dc8 for PDO 0x80eb4f10
InstancePath is "Root\*PNP0501\1_0_17_0_0_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80eb4b88 for PDO 0x80eb4cd0
InstancePath is "Root\*PNP0501\1_0_17_1_0_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80eb4948 for PDO 0x80eb4a90
InstancePath is "Root\*PNP0501\1_0_17_2_0_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80eb4708 for PDO 0x80eb4850
InstancePath is "Root\*PNP0501\1_0_17_3_0_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80eb44c8 for PDO 0x80eb4610
InstancePath is "Root\*PNP0700\1_0_13_0_26_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80eb4288 for PDO 0x80eb43d0
InstancePath is "Root\*PNP0F03\1_0_21_0_31_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80eb3700 for PDO 0x80eb3848
InstancePath is "ROOT\Ftdisk\0000"
ServiceName is "Ftdisk"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
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: fc8d2640, 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 805258ca to 805103fa

STACK_TEXT:
fc8d20bc 805258ca 00000003 fc8d23ec fc8d2640
nt!RtlpBreakWithStatusInstruction
fc8d2108 80526160 00000003 80084000 e10682f8
nt!KiBugCheckDebugBreak+0x19
fc8d24d4 805266db 0000007b fc8d2640 c0000034 nt!KeBugCheck2+0x46d
fc8d24f4 80692788 0000007b fc8d2640 c0000034 nt!KeBugCheckEx+0x19
fc8d2654 8067ed3b 80084000 80084000 00000000
nt!IopMarkBootPartition+0xbd
fc8d26a4 8068a5a5 80084000 fc8d27ec 00034000
nt!IopInitializeBootDrivers+0x49d
fc8d2844 8068b3a1 80084000 00000000 80e92960 nt!IoInitSystem+0x60a
fc8d2dac 8057c73a 80084000 00000000 00000000
nt!Phase1Initialization+0x83b
fc8d2ddc 805124c1 8068ad55 80084000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


FOLLOWUP_IP:
nt!KiBugCheckDebugBreak+19
805258ca eb59 jmp nt!KiBugCheckDebugBreak+0x74
(80525925)

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!KiBugCheckDebugBreak+19

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3d6de35c

STACK_COMMAND: kb

BUCKET_ID: 0x7B_nt!KiBugCheckDebugBreak+19

Followup: MachineOwner
---------
 
S

Slobodan Brcin \(eMVP\)

SAC,

Add following components and if you have more problems send us new !devnode
tree.

Standard IDE/ESDI Hard Disk Controller
Standard Dual Channel PCI IDE Controller
Secondary IDE Channel
Primary IDE Channel
All three "Disk drive" components.

PCI bus
PCI standard EISA bridge
PCI standard host CPU bridge
PCI standard ISA bridge
PCI standard PCI-to-PCI bridge
PCI standard RAM Controller
PnP (Kernel-mode)
PnP (User-mode)

FAT or/and NTFS

Resolve all dependencies.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SAC said:
KM, Slobodan,

I appreciate your help.

I finally got the debugger to connect normally, I'm not sure which new
component fixed this. Anyway, now the debugger does confirm this is
the 7B error. Below you'll see the results of my !devnode 0 1 and
!analyze -v commands.

Slobadan, I am sorry that 7B is such a pain. What a beast!

If you have any advice for me, it will be very much appreciated.

Thanks,
SAC


Loading User Symbols
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

Use !analyze -v to get detailed debugging information.

BugCheck 7B, {fc8d2640, c0000034, 0, 0}

Probably caused by : ntoskrnl.exe ( nt!KiBugCheckDebugBreak+19 )

Followup: MachineOwner
---------

nt!RtlpBreakWithStatusInstruction:
805103fa cc int 3
kd> !devnode 0 1
Dumping IopRootDeviceNode (= 0x80e7b008)
DevNode 0x80e7b008 for PDO 0x80e7c430
InstancePath is "HTREE\ROOT\0"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80e7bd28 for PDO 0x80e7be70
InstancePath is "Root\LEGACY_RDPWD\0000"
ServiceName is "RDPWD"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80e7ba48 for PDO 0x80e7bb90
InstancePath is "Root\LEGACY_TDPIPE\0000"
ServiceName is "TDPIPE"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80e7b808 for PDO 0x80e7b950
InstancePath is "Root\LEGACY_TDTCP\0000"
ServiceName is "TDTCP"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80e7b5c8 for PDO 0x80e7b710
InstancePath is "Root\RDPDR\0000"
ServiceName is "rdpdr"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_REGISTRY
DevNode 0x80e7b388 for PDO 0x80e7b4d0
InstancePath is "Root\RDP_KBD\0000"
ServiceName is "TermDD"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
DevNode 0x80e7b148 for PDO 0x80e7b290
InstancePath is "Root\RDP_MOU\0000"
ServiceName is "TermDD"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
DevNode 0x80eb5ee8 for PDO 0x80eb5030
InstancePath is "Root\SYSTEM\0000"
ServiceName is "swenum"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_REGISTRY
DevNode 0x80eb5ca8 for PDO 0x80eb5df0
InstancePath is "Root\SYSTEM\0001"
ServiceName is "update"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
DevNode 0x80eb5970 for PDO 0x80eb5ab8
InstancePath is "ROOT\PCI_HAL\0000"
ServiceName is "\Driver\PCI_HAL"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80e7ad10 for PDO 0x80eb55d0
InstancePath is "PCI_HAL\PNP0A03\0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80e7aad0 for PDO 0x80e7ac18
InstancePath is "Root\*PNP0301\1_0_22_0_32_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80e7a890 for PDO 0x80e7a9d8
InstancePath is "Root\*PNP0400\1_0_20_0_0_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80eb4dc8 for PDO 0x80eb4f10
InstancePath is "Root\*PNP0501\1_0_17_0_0_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80eb4b88 for PDO 0x80eb4cd0
InstancePath is "Root\*PNP0501\1_0_17_1_0_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80eb4948 for PDO 0x80eb4a90
InstancePath is "Root\*PNP0501\1_0_17_2_0_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80eb4708 for PDO 0x80eb4850
InstancePath is "Root\*PNP0501\1_0_17_3_0_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80eb44c8 for PDO 0x80eb4610
InstancePath is "Root\*PNP0700\1_0_13_0_26_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80eb4288 for PDO 0x80eb43d0
InstancePath is "Root\*PNP0F03\1_0_21_0_31_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80eb3700 for PDO 0x80eb3848
InstancePath is "ROOT\Ftdisk\0000"
ServiceName is "Ftdisk"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
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: fc8d2640, 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 805258ca to 805103fa

STACK_TEXT:
fc8d20bc 805258ca 00000003 fc8d23ec fc8d2640
nt!RtlpBreakWithStatusInstruction
fc8d2108 80526160 00000003 80084000 e10682f8
nt!KiBugCheckDebugBreak+0x19
fc8d24d4 805266db 0000007b fc8d2640 c0000034 nt!KeBugCheck2+0x46d
fc8d24f4 80692788 0000007b fc8d2640 c0000034 nt!KeBugCheckEx+0x19
fc8d2654 8067ed3b 80084000 80084000 00000000
nt!IopMarkBootPartition+0xbd
fc8d26a4 8068a5a5 80084000 fc8d27ec 00034000
nt!IopInitializeBootDrivers+0x49d
fc8d2844 8068b3a1 80084000 00000000 80e92960 nt!IoInitSystem+0x60a
fc8d2dac 8057c73a 80084000 00000000 00000000
nt!Phase1Initialization+0x83b
fc8d2ddc 805124c1 8068ad55 80084000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


FOLLOWUP_IP:
nt!KiBugCheckDebugBreak+19
805258ca eb59 jmp nt!KiBugCheckDebugBreak+0x74
(80525925)

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!KiBugCheckDebugBreak+19

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3d6de35c

STACK_COMMAND: kb

BUCKET_ID: 0x7B_nt!KiBugCheckDebugBreak+19

Followup: MachineOwner
---------









Since you are seeing 7B error then this scenario is not possible, you would
see various different errors if what you describe was the actual cause.

We have reached NDA point here. Only what I can say without going deeper to
the problem is something that you probably know or at least it is publicly
available:

In DDK 7B error is described under section "Bug Check 0x7B:
INACCESSIBLE_BOOT_DEVICE"

Cause for 7B error can be anything, I have isolated more than 10 different
causes. But one this is constant 7B error is not thrown by any of drivers,
but by ntoskrnl.exe when init phase 0 is complete and when boot disk is
expected to be present and functional.

Regards,
Slobodan

PS:
I'm sick of 7B, c000021a errors. I have been dealing with them for last two
months, day and nights. Hopefully I have solved them all. More testing will
tell.
[/QUOTE]
 
S

Slobodan Brcin \(eMVP\)

Konstantin,

I have no idea about how FastTrak driver is realized.
Is it marked as LowerFilter driver of disk driver. Or it is loaded
independently of disk driver?

BTW:
You have functional sources of disk and classpnp drivers so you can use them
for tracking errors.
Without knowing FastTrak driver realization I can't help you with accurate
answer.


Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top