Regedit in Minlogon

  • Thread starter Thread starter Dietmar
  • Start date Start date
D

Dietmar

Hi all,
I designed the Minlogon macrocomponent deleting NTFS, importing serial
Port (for debug) and Aha154x scsi and scsiport.sys and second
Ide-Controller. After FBA I wanted to fake in registry the Aha154x entry
with the name from my own Scsidriver for ramboot, named ntbootdd. This
procedur worked wonderful in a "mini NT4" so that I can boot this NT4 to
ram without any SDI. But there arrives a (small?) problem: Regedit does
not work in minlogon. I copied it simple to the rootfolder but then
arrives a message: "The system can not execute the specified program."
How can I overcome this? My image is only 13MB and it should not grow to
much.

Thanks
Dietmar
 
Dietmar,

Work with the image registry hives offline. Just open it up with regedit on XP Pro machine.

Not to mention that you can add any required reg.entries in TD (Extra Registry section).
 
Hi Konstantin,
I did this and my image size doesnt change. If You import regedit with TD,
it grows from 13 to 30 MB, thanks.
Now I have an other question: My own written scsi driver ntbootdd.sys
workes (compiled for NT4) in NT4 for ramboot. Now I compile ntbootdd.cpp
for XPSP1 checked with DDK for SP1 (I use ntbootdd.sys on a minlogon
image, build with XPE SP1 )and the following happens with minlogon: The
image in ram is DISCOVERED with this driver. But first windbg is writing
lines
and crashes then. Do You have any idea, how I can put windbg, not to crash
or even if it crashes to recover what happens with minlogon in ram? I think
it is something like BSOD 07B, but what is use of a debugger which crashes
itself?

Thank You
Dietmar

PS: Is it allowed for minlogon to write \maxmem=16 in boot.ini ? There is
no pagingfile.
 
Hi all,
I make a photo from my screen:
It is, as I thought:
BSOD 0x0000007B (0xFF53B640, 0xC0000034,
0x00000000, 0x00000000)

And also from my screen (not windbg, grrr...)
before BSOD 07B

scsi(0)disk(0)rdisk(0)partition(1)\WINDOWS\system32\ntoskrnl.exe

hall.dll
KDCOM.DLL
BOOTVID.dll
\config\system
c_1252.nls
c_437.nls
l_intl.nls
WINDOWS\FONTS\vgaoem.fon
\AppPatch\drvmain.sdb

drivers\pci.sys
isapnp.sys
MountMgr.sys
ftdisk.sys
WMILIB.SYS
PartMgr.sys
atapi.sys
Fastfat.sys
disk.sys
CLASSPNP.SYS

I miss my driver ntbootdd.sys here. This was together with disk.sys the
only one that has a start=0 value in registry.
But the driver must have been started because the files above are read
from RAM AFTER reboot and NO harddisks at all are there.
Is it possible that the crash came from CLASSPNP.SYS and the faked entry
in registry, Aha154x renamed to ntbootdd? In NT4 I used a driver called
class2.sys whitch is not in XP(E) at all. All that works in NT4 but not
here? I thought, that there isnt such a great difference...

Nice to hear from You all
Dietmar
 
Hi all,
thats my last post for today:
The registry values for ntbootdd.sys have not be stored(?) in my post
above but now they do but give the same BSOD
0x0000007B (0xFF53B640, 0xC0000034,
0x00000000, 0x00000000)

but now my driver is loaded (windbg still crashes...)

scsi(0)disk(0)rdisk(0)partition(1)\WINDOWS\system32\ntoskrnl.exe

hall.dll
KDCOM.DLL
BOOTVID.dll
\config\system
c_1252.nls
c_437.nls
l_intl.nls
WINDOWS\FONTS\vgaoem.fon
\AppPatch\drvmain.sdb

drivers\ntbootdd.sys (ha!)
SCSIPORT.SYS
WMILIB.SYS
Fastfat.sys
disk.sys
CLASSPNP.SYS

Crash... (and also the debugger windbg)

Because I have no idea to stop chrashing the debugger please help

Dietmar
 
Hi all,
I solved the chrashing windbg with USB legacy set to "disabled" on both
machines.

And here is the result from windbg:
My driver ntbootdd.sys is started, but the following disk.sys has a
problem with that or with CLASSPNP.SYS ? Can I change classpnp.sys against
class2.sys? It is in Win2000. Can this behavior result, because my driver
isnt a PNP driver? There are only two entries for the real Aha154x (non
PNP) in the registry as can be seen in TD. I toke them as they are for
Aha154x (non PNP). This worked on NT4. And my last remark: Any idea why
scsiport.sys has not started at all but is listened in driver list?

Thanks
Dietmar


Microsoft (R) Windows Debugger Version 6.5.0003.7
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \\.\com1
Waiting to reconnect...
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: C:\WINDOWS\Symbols
Executable search path is:
Windows XP Kernel Version 2600 UP Free x86 compatible
Built by: 2600.xpsp1.020828-1920
Kernel base = 0x804d4000 PsLoadedModuleList = 0x8054be30
System Uptime: not available

*** Fatal System Error: 0x0000007b
(0xFF53B640,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, {ff53b640, c0000034, 0, 0}

Probably caused by : ntoskrnl.exe ( nt!IopMarkBootPartition+bd )

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

nt!RtlpBreakWithStatusInstruction:
805103fa cc int 3
kd> lm
start end module name
804d4000 806c6980 nt (pdb symbols)
C:\WINDOWS\Symbols\exe\ntoskrnl.pdb
806c7000 806dfc00 hal (deferred)
ff0c8000 ff0eb700 Fastfat (deferred)
ff0ec000 ff102080 SCSIPORT (deferred)
ff124000 ff12c400 disk (deferred)
ff134000 ff13f500 CLASSPNP (deferred)
ff534000 ff537000 BOOTVID (deferred)
ff624000 ff625b80 kdcom (deferred)
ff626000 ff627100 WMILIB (deferred)
ff6ec000 ff6ecd80 ntbootdd (deferred)
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: ff53b640, 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:
ff53b0bc 805258ca 00000003 ff53b3ec ff53b640
nt!RtlpBreakWithStatusInstruction
ff53b108 80526160 00000003 80087000 e1071890 nt!KiBugCheckDebugBreak+0x19
ff53b4d4 805266db 0000007b ff53b640 c0000034 nt!KeBugCheck2+0x46d
ff53b4f4 80692788 0000007b ff53b640 c0000034 nt!KeBugCheckEx+0x19
ff53b654 8067ed3b 80087000 80087000 00000000 nt!IopMarkBootPartition+0xbd
ff53b6a4 8068a5a5 80087000 ff53b7ec 00034000
nt!IopInitializeBootDrivers+0x49d
ff53b844 8068b3a1 80087000 00000000 80deb020 nt!IoInitSystem+0x60a
ff53bdac 8057c73a 80087000 00000000 00000000
nt!Phase1Initialization+0x83b
ff53bddc 805124c1 8068ad55 80087000 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


FOLLOWUP_IP:
nt!IopMarkBootPartition+bd
80692788 cc int 3

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!IopMarkBootPartition+bd

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3d6de35c

STACK_COMMAND: kb

FAILURE_BUCKET_ID: 0x7B_nt!IopMarkBootPartition+bd

BUCKET_ID: 0x7B_nt!IopMarkBootPartition+bd

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

kd> !devnode 0 1
Dumping IopRootDeviceNode (= 0x80e0f4c8)
DevNode 0x80e0f4c8 for PDO 0x80e0f600
InstancePath is "HTREE\ROOT\0"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80e0eee8 for PDO 0x80e0e030
InstancePath is "Root\atapi\0000"
ServiceName is "atapi"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
DevNode 0x80e0ec08 for PDO 0x80e0ed50
InstancePath is "Root\atapi\0001"
ServiceName is "atapi"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
DevNode 0x80e0e9c8 for PDO 0x80e0eb10
InstancePath is "Root\Ftdisk\0000"
ServiceName is "Ftdisk"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
DevNode 0x80e0e788 for PDO 0x80e0e8d0
InstancePath is "Root\LEGACY_MOUNTMGR\0000"
ServiceName is "MountMgr"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80e0e548 for PDO 0x80e0e690
InstancePath is "Root\LEGACY_PARTMGR\0000"
ServiceName is "PartMgr"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80e0e308 for PDO 0x80e0e450
InstancePath is "Root\LEGACY_VGASAVE\0000"
ServiceName is "VgaSave"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80ddf008 for PDO 0x80e0e210
InstancePath is "Root\PCI_HAL\0000"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80ddf168 for PDO 0x80ddf768
InstancePath is "PCI_HAL\PNP0A03\0"
ServiceName is "pci"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
DevNode 0x80ddfdc8 for PDO 0x80ddff10
InstancePath is "Root\SYSTEM\0000"
ServiceName is "swenum"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_REGISTRY
DevNode 0x80ddfb88 for PDO 0x80ddfcd0
InstancePath is "Root\SYSTEM\0001"
ServiceName is "update"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
DevNode 0x80ddeee8 for PDO 0x80dde2e8
InstancePath is "Root\*PNP0000\PnPBIOS_1"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80ddeca8 for PDO 0x80ddedf0
InstancePath is "Root\*PNP0100\PnPBIOS_3"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80e0dee8 for PDO 0x80e0d030
InstancePath is "Root\*PNP0200\PnPBIOS_2"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80e0dca8 for PDO 0x80e0ddf0
InstancePath is "Root\*PNP0301\1_0_22_0_32_0"
ServiceName is "i8042prt"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
DevNode 0x80e0da68 for PDO 0x80e0dbb0
InstancePath is "Root\*PNP0501\PnPBIOS_10"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80e0d828 for PDO 0x80e0d970
InstancePath is "Root\*PNP0501\PnPBIOS_11"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80e0d5e8 for PDO 0x80e0d730
InstancePath is "Root\*PNP0700\PnPBIOS_12"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80e0d3a8 for PDO 0x80e0d4f0
InstancePath is "Root\*PNP0800\PnPBIOS_8"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80e0d168 for PDO 0x80e0d2b0
InstancePath is "Root\*PNP0B00\PnPBIOS_4"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80dddee8 for PDO 0x80ddd030
InstancePath is "Root\*PNP0C01\PnPBIOS_0"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80dddca8 for PDO 0x80ddddf0
InstancePath is "Root\*PNP0C02\PnPBIOS_13"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80ddda68 for PDO 0x80dddbb0
InstancePath is "Root\*PNP0C02\PnPBIOS_14"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80ddd828 for PDO 0x80ddd970
InstancePath is "Root\*PNP0C02\PnPBIOS_15"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80ddd5e8 for PDO 0x80ddd730
InstancePath is "Root\*PNP0C04\PnPBIOS_9"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
Problem = CM_PROB_NOT_CONFIGURED
DevNode 0x80ddd3a8 for PDO 0x80ddd4f0
InstancePath is "Root\*PNP0F03\1_0_21_0_31_0"
ServiceName is "i8042prt"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
DevNode 0x80e0c5b8 for PDO 0x80e0c700
InstancePath is "ROOT\ntbootdd\0000"
ServiceName is "ntbootdd"
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0x80e0b008 for PDO 0x80e0ba38
InstancePath is "SCSI\Disk&Ven_NEBBETT&Prod_&Rev_\1&30c669b6&0&000"
ServiceName is "disk"
State = DeviceNodeInitialized (0x302)
Previous State = DeviceNodeUninitialized (0x301)
 
Dietmar,

Nice work so far.

You need to check whether ntldr has propagated corect disk signature asociated with ARC path for your disk.
For this you will need to backtrace trough kernel from 7B error to see what checks were preformed. My guess is that your drivers are
working so so but that you are missing vital info from ntldr/ntdetect pair.

Regards,
Slobodan
 
Hi Slobodan,
I noticed that it doesnt matter, if I use the driver ntbootdd.sys build
from NT4 DDK (which worked for NT4) or build from XP1 DDK. There is always
the SAME BSOD message with same numbers. So I think, it is perhaps a
problem, how this driver is listened in registry. The Aha154x.sys (non
PNP) has an extra entry which I cant fake to ntbootdd.sys ,
Enum\Root\LEGACY_AHA154X .
Can I do the same entry for ntboodd?
And my last question: Is it possible to build a component for my
ntbootdd.sys and can it help to integrate it in database?

Thanks
Dietmar

PS: The driver ntbootdd.sys is also on
bootfloppydisk. Can this be a problem?
 
Dietmar,

Do you have an entry for ntbootdd under [HKLM\SYSTEM\CurrentControlSet\Services]?
If not, you may want to create it (offline registry) manually. Taking another SCSI miniport as
template (e.g. Aha154x, which you already mentioned).
 
Hi Slobodan,
I just have another simple idea:
Can it be the fault of FBA, because I cant get rid of FBA in minlogon. If
I kill the folder with
FBA, the image doesnt start any more from harddisk.
And this is, because I assume this: With the image of minlogon in ram,
there are still the harddisks listend, which where there when FBA first
run on minlogon image. Can I delete them simply in registry?

Thanks
Dietmar
 
Hi Konstantin,
yes I have this entry and I killed the subfolder(s)
Parameters/PnPInterface with parameters 1 3 for PNP (which belongs to real
Aha154x). This works as You can see, the ntbootdd.sys driver is loaded (has
started (308)). And all seems to work right. Therefore I came to the idea,
that this is similar to all the other 07B BSODS. I think, that XP (FBA
here?) only wanted to start from that harddrive, on which it was
originally installed. That describes exact all, was has happened until.
And that is my question: Which key(s) have I to kill or to write new, that
XP(E) forgot of any old harddrives and that it is getting the NEW one and
the vendor number for the "Harddrive in Ram" InstancePath is

SCSI\Disk&Ven_NEBBETT&Prod_&Rev_\1&30c669b6&0&000

I think, it is not far away from working and then
is there a big chance for large images in ram without any SDI. You only
have to copy the files by explorer, that works for me in NT4.

Thank You for Your help
Dietmar

PS: Have You ever seen a BSOD 07b in NT4?
 
Hi all,
after I read all the posts here which belongs to scsi BSOD 07b I came to
the following idea (hihi):
I will export the registry from my running NT4 miniimage in ram. There I
only have to look (or can reimport pieces in minlogons registry), which
number the "scsi" disk have and have all the correct entrys because
Microsoft says:
Click to expand...
"For Windows 2000 and later, a legacy miniport driver is initialized in
exactly the same way as for Microsoft Windows NT 4.0. When a legacy
miniport driver calls ScsiPortInitialize, the port driver calls..."
I think that will work or even put me a big step forward.

Thanks for help
Dietmar

PS: Do You know, that floppydisk is not supported
by minlogon? That is a funny thing: In TD have the drivers flpydisk.sys
and fdc.sys NO entry in registry. But if You simple copy them to system32,
the floppy doesnt work at all after reboot. This is nearly the same as with
my "scsi" disk driver ntbootdd.sys . There are (more) entries in registry
needed.
 
Back
Top