82 replies to this topic

[Wonko the Sane]

If you talking about boot.ini arc paths
multi(0)disk(0)cdrom(159)I386=
then i figured it out

else help appreciated ))

Sorry, I was editing my previous post and didn't notice the above.
Where does the (159) come from?

P.s.: Nevermind, got it:
http://www.pcreview....mg-t531044.html



Wonko

[smx06]

Sorry, I was editing my previous post and didn't notice the above.
Where does the (159) come from?

i used I386 both on usb and cd
this is realy not important
it can be booted even from X386 (tested) or even 6969 )

0x07 bsod comes seems from driver loading for device (like i found even on USB hard drive booting in VMWare)

159 - seems differs on different computers - that was in VMWare
Can be seen using grldr (groob) pressin INSert on boot it will show additional info including CD id

[Wonko the Sane]

i used I386 both on usb and cd
this is realy not important
it can be booted even from X386 (tested) or even 6969 )

No, it may be not important when booting from USB or HD image, but until we succeed to boot from the CD device it cannot be said.

0x07 bsod comes seems from driver loading for device (like i found even on USB hard drive booting in VMWare)

Yes an no, 0x0000007b means "inaccessible boot device" and though it is usually connected with the loading of a driver it could be that the driver is correctly loaded but simply it fails to "hook" the "right" device or media.

159 - seems differs on different computers - that was in VMWare

You haven't yet learned how doing these tests in a Vmware VM can be foolish (in the sense that they may not give a reliable answer), didn't you?



Wonko

[maanu]

it might be little off topic , but chinese have found a way to fast load the winpe 1.X , specially from USB .


in that, PE loads in 2 portions ,1st only native windows files (8-10 MB IMG file) compressed to 4MB cab image , will be loaded . / then other files (which we will pack into WIM file ) , will be mounted using Native.exe file , (which chinese developed ) on the fly .

for more information ,



http://bbs.wuyou.com....php?tid=188616

http://bbs.wuyou.com....php?tid=200561


if any one needs example , i have made an English PE using above tech . just pm.

i ll try to find more time , and explain in detail all steps.

[Wonko the Sane]

in that, PE loads in 2 portions ,1st only native windows files (8-10 MB IMG file) compressed to 4MB cab image , will be loaded . / then other files (which we will pack into WIM file ) , will be mounted using Native.exe file , (which chinese developed ) on the fly .

for more information ,
http://bbs.wuyou.com....php?tid=188616

http://bbs.wuyou.com....php?tid=200561

Yes, OT , but interesting.

if any one needs example , i have made an English PE using above tech . just pm.

VERY BAD idea.

i ll try to find more time , and explain in detail all steps.

VERY GOOD idea.


Wonko

[smx06]

About CD boot (with 1st post algorithm)
as expected BSOD is going inside procedure:
nt!IopInitializeBootDrivers+0x4ba

going down..

[Wonko the Sane]

About CD boot (with 1st post algorithm)
as expected BSOD is going inside procedure:
nt!IopInitializeBootDrivers+0x4ba

going down..

What I did notice is that in the .reg (just like they are normally on WIndows XP "full" install) the NTFS and CDFS drivers are set as:

"Group"="File system"
"Start"=dword:00000004
"Type"=dword:00000002

Whilst the FastFat one is

"Group"="Boot file system"
"Start"=dword:00000004
"Type"=dword:00000002

A very loooong shot, but would it be possible that *somehow* a "driver initiate" command is needed, and NTLDR only provides one for NTFS and not for CDFS (and for CDROM on which CDFS depends).
The entry for CDROM:

[HKEY_LOCAL_MACHINEtControlSet001ServicesCdrom]
"DependOnGroup"=hex(7):53,43,53,49,20,6d,69,6e,69,70,6f,72,74,00,00
"ErrorControl"=dword:00000000
"Group"="SCSI CDROM Class"
"Start"=dword:00000000
"Tag"=dword:00000002
"Type"=dword:00000001

makes the driver belong to group "SCSI CDROM Class", which depends on "Scsi Miniport".
Now in the original SETUPREG.HIV, there is a quite simplified [HKEY_LOCAL_MACHINEtControlSet001ControlServiceGroupOrder]:

drivers
Boot Bus Extender
System Bus Extender
Input Device Support

Whilst in the .reg there is a "complete" one:

System Reserved
Boot Bus Extender
System Bus Extender
SCSI miniport
Port
Primary Disk
SCSI Class
SCSI CDROM Class
FSFilter Infrastructure
FSFilter System
FSFilter Bottom
FSFilter Copy Protection
FSFilter Security Enhancer
FSFilter Open File
FSFilter Physical Quota Management
FSFilter Encryption
FSFilter Compression
FSFilter HSM
FSFilter Cluster File System
FSFilter System Recovery
FSFilter Quota Management
FSFilter Content Screener
FSFilter Continuous Backup
FSFilter Replication
FSFilter Anti-Virus
FSFilter Undelete
FSFilter Activity Monitor
FSFilter Top
Filter
Boot File System
Base
Pointer Port
Keyboard Port
Pointer Class
Keyboard Class
Video Init
Video
Video Save
File System
Event Log
Streams Drivers
NDIS Wrapper
COM Infrastructure
UIGroup
LocalValidation
PlugPlay
PNP_TDI
NDIS
TDI
NetBIOSGroup
ShellSvcGroup
SchedulerGroup
SpoolerGroup
AudioGroup
SmartCardGroup
NetworkProvider
RemoteValidation
NetDDEGroup
Parallel arbitrator
Extended Base
PCI Configuration

Could it be that something in these settings change the behaviour?
Like removing them from "SCSI CDROM Class", and "SCSI Miniport" and moving themup to "Boot Bus Extender" or "System Bus Extender"


Wonko

[smx06]

Like removing them from "SCSI CDROM Class", and "SCSI Miniport" and moving themup to "Boot Bus Extender" or "System Bus Extender"

really mad idea ))
i just implemented it briefly moving cdfs to boot file system
and cdrom to boot bus extender + eliminating "depend on group" elsewhere in em..

i expected just crash - as this is very random way,
but on USB it boots successfully even it can see the CD contents ))
on CDboot the crash is the same

So i think this reg entries are just NOT used at all in our case..

[Wonko the Sane]

really mad idea ))
i just implemented it briefly moving cdfs to boot file system
and cdrom to boot bus extender + eliminating "depend on group" elsewhere in em..

An even madder attempt, you cannot simply "remove" the depend on group, I think


Wonko

[smx06]

sure; they're just not used, else this mess would lead to someth

[Wonko the Sane]

sure; they're just not used, else this mess would lead to someth

What made me think of something connected to the 0x0000007b booting issue is the comment (that you translated) in the .reg file:

;BSOD 0x7b fix on hard drives absence.
;faster loading

But maybe we are still within something connected to the stoopid arcpath.


Wonko

[smx06]

"after PnP completes the initial enumeration of the
system, the boot disk is not accessible as a real NT device; the first
parameter to the bug check is either a device object or a PUNICODE_STRING"

maybe you're right
the first parameter of BSOD (windbg shows) is a ptr to .ArcNamemulti(0)disk(0)cdrom(159)
and the status code is STATUS_OBJECT_NAME_NOT_FOUND ((NTSTATUS)0xC0000034 L)

[smx06]

attached are 2 logs from setupldr and ntldr
(both are loading from usb stick)
it could be interesting to produce setupldr log booting from cd
but don't know how as CD is not writable ))

http://www.box.com/s...16f910ae5be51eb

[smx06]

ps.
ramdisk loading errors are produced by missing ramdisk driver i just didnt remove it from registry

[Wonko the Sane]

Could it be that you are falling in this behaviour reported by Medevil?:
http://reboot.pro/3765/page__st__7

Try making a NT boot floppy and map it in grub4dos, maybe the issue is actually NTLDR on CD device...


Another idea - unrelated but not much - since now we have a new limit of 37,748,736 for the El-Torito floppy emulation:
http://www.msfn.org/...oppy-emulation/
what happens if we try this ooooold thingies:
http://www.freewebs....sandscripts.htm
or a more recent very minimal PE like as an example the just revamped PicoXP:
http://reboot.pro/15252/
and see if floppy emulation:

• works
• is faster than HD Emulation

Again, we must find a "common ground".
Which is Qemu+Qemu Manager as "environment" and a given project so that everyone can experiment with the same "base".


Wonko

[smx06]

>Try making a NT boot floppy and map it in grub4dos, maybe the issue is actually NTLDR on CD device...

sure but the case is loading from CD
and floppy has not enough room

If problem is ArcName that is only valid in real mode for ntldr and invalid after booting kernel
i'm thinking of ntbootdd.sys (ntbootdd.c) for making it valid for BOTH parts..
What do you think and can suggest about ntbotdd info?

[smx06]

Anybody can experiment basing on info above - just do BartPE, import .reg files to 'system',
put ntldr and boot ini to the root and you'll there ))

Edited by smx06, 27 March 2012 - 08:41 AM.

[Wonko the Sane]

>Try making a NT boot floppy and map it in grub4dos, maybe the issue is actually NTLDR on CD device...

sure but the case is loading from CD
and floppy has not enough room

smx06

A NT boot floppy is made by a floppy containing:
NTLDR
BOOT.INI
NTEDETECT:COM
that fit "comfortably" in a 1.44 Floppy image that you can boot through grub4dos.

Please read:
http://www.xxcopy.com/xxcopy33.htm
http://reboot.pro/5973/page__st__8

You can add to the BOOT.INI on your .iso/cd an entry like:

C:grldr="grub4dos"

add to the root of the CD or .iso grldr from a recent grub4dos and a menu.lst like the following:

title NT Floppy
find --set-root /myntfloppy.img
map --mem /myntfloppy.img (fd0)
map --hook
chainloader /NTLDR

This way the running NTLDR will be the one on the floppy and the BOOT.INI as well.


Wonko

[smx06]

a little more digging (im still using vmware+windbg as i think windbg is much more powerfull then any other debugger in this case; or is qemu able to connect to windbg?)

results:
- Arcname used ( cdrom(xxx)i386 is CORRECT!
checked in setupldr.bin->ntoskrnl debugging - it uses the same path!
BSOD0x07 is going when nt!IopMarkBootPartition+0x.. tries to NtOpen() this path
in our case it is not accessible because of CDROM.sys is loaded (cdfs.sys also)
but seems not properly initialized (maybe because cdrom device was not marked as bootable?nonremovable? by ntdetect.com?)

- setupldr.bin does all the same except it loads more drivers (trying to remove unneeded)
im curious of SCSIPORT.sys (that is missed in ntldr loading case; and totally missed in registry in both cases;)

ps. floppy case is not interesting for me as even if it works - it is different then CD option (and size limit is also unacceptable)

pps in successful case (setupldr) CDROM.sys
reports:
CdRomCreateWellKnownName: successfully linked DosDevicesCdRom0 to device DeviceCdRom0
CDROM.SYS Add succeeded
in failure (ntldr):
just DriverEntry() is called..


Thanks!

Edited by smx06, 29 March 2012 - 09:06 AM.

[smx06]

NTldr loaded drivers:

804d7000 806eb780 nt (pdb symbols) d:symbcachentoskrnl.pdb8592B6763F34476B9BB560395A383F962ntoskrnl.pdb
806ec000 80705c00 hal (deferred)
f8332000 f834c580 Mup (deferred)
f834d000 f8379a80 Ndis (deferred)
f837a000 f8390780 KSecDD (deferred)
f8391000 f8454400 dmboot (deferred)
f8455000 f846c480 atapi (deferred)
f846d000 f8492700 dmio (deferred)
f8493000 f84b1880 ftdisk (deferred)
f84b2000 f84c2a80 Pci (deferred)
f84c3000 f84f0d80 acpi (deferred)
f8535000 f8541180 cdrom (deferred)
f8545000 f8551200 CLASSPNP (deferred)
f8555000 f855dc00 isapnp (deferred)
f8575000 f857f500 mountmgr (deferred)
f8585000 f8591c80 VolSnap (deferred)
f8595000 f859de00 Disk (deferred)
f87d5000 f87db200 PCIIDEX (deferred)
f87dd000 f87e3b00 fdc (deferred)
f87e5000 f87e9900 partmgr (deferred)
f8945000 f8948000 BOOTVID (deferred)
f8a35000 f8a36b80 kdcom (deferred)
f8a37000 f8a38100 WMILIB (deferred)
f8a39000 f8a3a280 USBD (deferred)
f8a3b000 f8a3c700 dmload (deferred)
f8afd000 f8afdd00 PciIde (deferred)

************************************************************************************************************************************
setupldr loaded drivers:
80400000 80614780 nt (pdb symbols) d:symbcachentoskrnl.pdb8592B6763F34476B9BB560395A383F962ntoskrnl.pdb
80615000 80635380 hal (deferred)
f8277000 f8291580 mup (deferred)
f8292000 f82bea80 ndis (deferred)
f82bf000 f82dfa80 cdfs (deferred)
f82e0000 f836c480 ntfs (deferred)
f836d000 f8390000 fastfat (deferred)
f8390000 f83a6780 ksecdd (deferred)
f83a7000 f83c1300 cdrom (deferred)
f83c2000 f83edd80 dac2w2k (deferred)
f83ee000 f8405480 atapi (deferred)
>>f8406000 f841d800 SCSIPORT (deferred)
f841e000 f843c880 ftdisk (deferred)
f843d000 f845a480 pcmcia (deferred)
f845b000 f8488d80 acpi (deferred)
f8489000 f8499a80 pci (deferred)
f849a000 f8513b00 setupdd (deferred)
f8535000 f853dc00 isapnp (deferred)
f8545000 f854f500 mountmgr (deferred)
f8555000 f855d780 lbrtfdc (deferred)
f8565000 f8574d80 serial (deferred)
f8575000 f8581e00 i8042prt (deferred)
f8585000 f8591200 CLASSPNP (deferred)
f8595000 f859de00 disk (deferred)
f87b5000 f87bb200 PCIIDEX (deferred)
f87bd000 f87c1900 partmgr (deferred)
f87c5000 f87cbb00 fdc (deferred)
f87cd000 f87d3180 HIDPARSE (deferred)
f87d5000 f87db000 kbdclass (deferred)
f87dd000 f87e2a00 mouclass (deferred)
f87e5000 f87ea000 flpydisk (deferred)
f87ed000 f87f2100 ramdisk (deferred)
f8945000 f8948000 BOOTVID (deferred)
f8949000 f894bd80 acpiec (deferred)
f894d000 f8950c80 serenum (deferred)
f8951000 f8954a00 kbdhid (deferred)
f8955000 f8957f80 mouhid (deferred)
f8959000 f895ca80 cpqarray (deferred)
f895d000 f8960680 cbidf2k (deferred)
f8961000 f8963c80 sfloppy (deferred)
f8a35000 f8a36b80 kdcom (deferred)
f8a37000 f8a38100 WMILIB (deferred)
f8a39000 f8a3a580 intelide (deferred)
f8a3b000 f8a3ca00 cmdide (deferred)
f8a3d000 f8a3ee00 cd20xrnt (deferred)
f8afd000 f8afdd80 SPDDLANG (deferred)
f8afe000 f8afed80 OPRGHDLR (deferred)
f8aff000 f8affd00 pciide (deferred)
ps i removed USB* drivers from packages as they not needed in test mode (CD-booting)

[Wonko the Sane]

The floppy "image" is not at all incompatible with "size" or CD, I see that you completely failed to read the given links (or maybe I was not clear enough, if the latter please ask for additional info).

Mind you I have no way to know if my ideas/guesses are any good or completely wrong , but sure is frustrating to spend some time in thinking about them and posting them and have you regularly doing *another* thing or ignoring them altogether.

a little more digging (im still using vmware+windbg as i think windbg is much more powerfull then any other debugger in this case; or is qemu able to connect to windbg?)

results:
- Arcname used ( cdrom(xxx)i386 is CORRECT!
checked in setupldr.bin->ntoskrnl debugging - it uses the same path!
BSOD0x07 is going when nt!IopMarkBootPartition+0x.. tries to NtOpen() this path
in our case it is not accessible because of CDROM.sys is loaded (cdfs.sys also)
but seems not properly initialized (maybe because cdrom device was not marked as bootable?nonremovable? by ntdetect.com?)

That'ìs EXACTLY why I suggested you to try a floppy image, though since the reference is to MarkBootPartition maybe a small hard disk image is needed.

About WinDbg:
http://www.h7.dion.n...ingTips-en.html


Wonko

[smx06]

Well "MarkBootPartition" is just a name - it doesn't mark anything (at least at this stage)
it just tries reading by arcname (correct!) - and fails - then bsod.
i.e. cdrom is unaccessible at this time (even i forced to load cdrom.sys and cdfs.sys
they seems not initialized properly (just drivers were initialized via DriverEntry)
maybe some loading order can fix that (or maybe ntdetect.com failed to set cdrom as boot drive)

>about floppy

i read those threads briefly but can't understand how it can be used here (booting from CD)
Plz describe how you see the boot sequence of your suggestion with floppy!
Afair like this:
grldr (CD boot sector) ->
grldr (on CD root) ->
floppy image ->
ntldr (on floppy image) ->
boot.ini (on floppy image) ->
multi(0)disk(0)floppy(0)I386->
drivers (on floppy image)
ntoskrnl (on floppy image)
and then??
(all system can't be stored in 32MB in my case - and mixing part on floppy with part on CD outside the image i think will not work)

Or maybe you mean very other scheme (?)

p.s.
i can't use grldr (loading floppy image) in final solution just for test purposes (what usefull info can this bring me?)..


>About WinDbg:

Aha, it can be used, nice.
Thanks!

[Wonko the Sane]

CD made with grldr as NO-EMULATION bootsector
contents of CD:

• your current contents (exactly the same)
• grldr
• menu.lst
• myntfloppy.img

Contents of menu.lst:

title NT Floppy
find --set-root /myntfloppy.img
map --mem /myntfloppy.img (fd0)
map --hook
chainloader /NTLDR

title BootPE normally
root (cd)
chainloader /NTLDR

(remember that on CDFS grub4dos is CaSeSeNsItIvE)

Suggested mkisofs command lines:
http://reboot.pro/9787/page__st__10

grldr (CD boot sector) ->
grldr (on CD root) ->
floppy image ->
ntldr (on floppy image) ->
boot.ini (on floppy image) ->
multi(0)disk(0)cdrom(xyz)I386->
ntdetect.com (on floppy image) ->
drivers (on CD I386)
ntoskrnl (on CD I386)

Will it change anything? Cannot say.


Wonko

[smx06]

ah ok Thanks

[smx06]

Same effect booting from floppy (could be expected as all boot is still from multi(0)disk(0)cdrom(xyz)I386)
But i discovered with this (while testing) that cdrom.sys is initialized the same as while setupldr booting (previously i missed this);
and this brings that something is going wrong inside NtOpen ("ArcNamemulti(0)disk(0)cdrom(xyz)I386")
shall go inside it..