Blue Screen of Life

Hello all,

As usual, my searching skills are lacking... I seem to recall someone mentioning some hacking that gave the Recovery Console CLI but from the Windows graphical screen where one usually sees the kernel type, RAM, number of processors. You know the one... Before AUTOCHK.EXE or other "native"-mode programs run, such as Alex Ionescu's NCLI... Could anyone offer a suggestion? I'm working on an XP/2003 idea for booting on any hardware, HAL/kernel auto-detection, etc.

Thanks.

I seem to recall someone mentioning some hacking that gave the Recovery Console CLI but from the Windows graphical screen where one usually sees the kernel type, RAM, number of processors. You know the one...

I don't recall something like that, but I cannot understand the "Windows graphical screen where one usually sees the kernel type, RAM, number of processors. You know the one...".

Can you try better describe what you recall?

Or are you talking about this thingy here? WINROOT
http://www.boot-land...?...ic=3537&hl=


Wonko

Thanks, Wonko.

If you use the /SOS switch in BOOT.INI, you'll see a light blue (or grey, depending on OS) screen which tells you the information I mentioned. This is where drivers will output messages, and is normally all hidden without /SOS as you usually see the black screen with the Windows logo in the centre and the blue (or grey, or green) "progress bar". It is precisely the screen that your link shows Alex' NCLI running in.

I thought that somebody had done a hack which put the Recovery Console CLI at that same screen, instead of the NCLI. I recall someone using terms like "Blue Screen of Life" or "Blue Screen of Recovery" or something like that. It was in these forums. Maybe I'm crazy. Please let me know if it rings a bell, anyone.

It was likely the WinRoot project. You should get in contact with AeroXP or Alex Ionescu to get more informations.

Maybe I'm crazy.

That's a possibility, yes.

Point is whether you are crazy and forgetful or just crazy.

I usually think to be the latter, but I really cannot recall anything like what you describe, which makes me think that I belong to the former group.


There is the BSOR broject:
http://www.boot-land...?showtopic=3720

But I think it is not what you are asking.




Wonko

Thanks to both of you for your responses. I believe it was the Blue Screen of Rescue that I was thinking of... I've never tried it. Trying it now reveals a WinBuilder script error where an .NLS file cannot be copied, I think because its name is "c_1252.nls,1252" and the CopyOrDecompress is changing that to "c_1252.nls,152_" as most compressed files end with the .??_ pattern. Oh well. You folks are great.

So here're some thoughts (for XP/2003):

With XP/2003, NTLDR does not auto-detect which HAL and kernel to use. Only the setup-variant does this. NTLDR requires the /HAL= and /KERNEL= switches in BOOT.INI to choose a particular kernel.

A RAM disk is the only type of "disk" whose driver will work on any hardware; other hard disk controllers may require installation or entries in CriticalDeviceDatabase, and it's tough to know before-hand what you'll need and tedious to populate this Registry key.

For network deployment scenarios or remote support/rescue purposes, it would be handy to be able to boot computers to a minimal Windows environment which includes networking support. This enables an administrator to remote control a computer, or send it instructions.

Traditionally, the Windows PE environment has been employed for the two uses mentioned above. Since it's loaded with SETUPLDR, it can auto-detect the HAL and kernel to use. Using Sherpya's fine resources, one can even boot a PE using PXE+TFTP, then run the OS via SMB. This is very nice. A limitation here is that you need one share per client, since any file writes that they perform would otherwise be to the same files. Additionally, there are volatile versus non-volatile Registry complications.

Having multiple shares means management, even if you can automate it to some degree. All of the OS files are redundant, so without hard links, it's a waste of storage. In a quest to produce hard links wherever possible, you have to determine which files are safe to create hard links for. You also have to create a share for each client, so it's not given that any new client can simply boot to your system without any preparation.

Suppose I have an HDD image with Windows and applications installed on it. Suppose that this image works across some set of models. Now suppose I obtain a brand new model of computer and wish to take that image and apply it to this model. There are some challenges:

* Without running SETUPLDR on the new system, how do you know which HAL and kernel to use?
* If you simply apply your image, what if you get a STOP 0x0000007B Blue Screen of Death because the hard disk controller is not installed?
* If you pre-install this device, maybe by importing the relevant subkeys of HKLM\SYSTEM\CCS\Enum\ from a PE, you need to be sure your PE OS files match those in your image. The device nodes can be different depending on the OS files used.
* If you pre-install this device, it means updating your image. If you store this image in multiple locations, it means updating all of those locations. The image grows and you might encounter driver incompatibilities. (For example, HP's disk protection filter being installed on a Dell)
* If you apply your image and then wish to perform some post-processing on the target system, (such as choosing the correct kernel and HAL, injecting the HDD controller into the CriticalDeviceDatabase, copying drivers onto the image for Mini-Setup or Found New Hardware Wizard to use, etc.) how do you do these things to a remote NTFS partition?
* If you use Windows RIS or any other commercial product, that product might cost money.
* If you use a Windows PE environment (some commercial products do), the PE might have certain RAM requirements.

It seems hard to get away from some of the benefits of a PE which can run in RAM, include lots of drivers for networking and HDD controllers, and can process the target HDD by re-imaging it or whatever. As mentioned, this means RAM requiremens.

An alternative to a PE is a stripped-down Windows which can run in RAM. While this may be more functional and useful than a PE, it likely has even greater RAM requirements than a PE.

It would be nice if we could boot a minimal Windows which doesn't have a strong RAM requirement. One way to accomplish this is to boot from the network. Two options for that are via the SMB PE method or via SAN, but both of these require resources per client. These also require that the NIC driver is RIS-compatible or that it doesn't rely on userspace or post-boot-time services (think wireless).

So how about a tiny Windows which boots from RAM disk and auto-detects HAL and kernel, but then establishes a network connection and continues to load OS components in a way that does not require per-client resources?

I'm thinking that native-mode applications could help with this. These native-mode applications can be run before the Win32 subsystem starts up, and thus offer a "Blue Screen of Life," where they could be used to "breathe life into" a brand new system.

But what do _you_ think?

I was waiting for your considerations.

Maybe it's the time I've found someone interested in XPCLI:
http://www.boot-land...?...ic=3717&hl=

About HAL, do check OfflineSysprep:
http://www.911cd.net...hp?showforum=43

And "Universal XP Image":
http://www.boot-land...?showtopic=9830


Wonko

P.S.:For XPCLI, here is a list of the most relevant posts (to speed up the reading/testing):
http://www.boot-land...?...=6996&st=26

Thanks to both of you for your responses. I believe it was the Blue Screen of Rescue that I was thinking of... I've never tried it. Trying it now reveals a WinBuilder script error where an .NLS file cannot be copied, I think because its name is "c_1252.nls,1252" and the CopyOrDecompress is changing that to "c_1252.nls,152_" as most compressed files end with the .??_ pattern. Oh well. You folks are great.

As author of the BSOR project:

For this project there has never been practical interest in the forum, and therefore I put it into winter-sleep.

If there are real interests to use, I'm willing to debug and continue.

Peter

But what do _you_ think?

Sounds useful, but not if it requires minlogon - which xpcli did I think.
Glad you're still around

Sounds useful, but not if it requires minlogon - which xpcli did I think.

Sure it did/does , the whole first step of re-vamping would be to re-add to it "normal" winlogon or find an alternate logon.


Wonko

@Sha
Your post is to lenghtly to answer all qestions and correct all errors, line by line. So here in short.

Setupldr does not detect HAL and Kernel unless it is used in a Network boot, but you can always use the single processor Kernel that's how PE1.0 do it.
Or, if you only use newer machines, always use the multi processor Kernel.

A PE does not require to add anything to the registry to add drivers. Drivers required for boot are added to txtsetup.sif.

To get around the BSOD on Boot, you'll have to install all boot drivers for all machines, you'll ever gonna use PE on. If you don't, you'll have to rebuild a few times.

The idea to use RAM-Disk to not need other drivers is pointless. This will sure give you a running PE on all systems, but without CD/DVD/HDD access.

Wonko the Sane:

XPCLI appears to be a stripped-down Win32 environment which allows CMD.EXE (and other Win32 programs) to run by its use of the XP Embedded .DLLs and/or MINLOGON.EXE. While handy to get a tiny Windows, I was thinking more along the lines of native-mode (non-Win32-subsystem) programs, for an even smaller Windows and without the XP Embedded requirements.

OfflineSysprep is definitely useful, but is also a Win32-mode app, if I'm not mistaken.

"Universal XP" is very nice work. The suite of programs are all Win32-mode apps, if I'm not mistaken. The user might need to trial-and-error the HAL and kernel choice on the target hardware or determine it with some other method, such as booting a Windows PE, installing Windows, or searching the Internet for the right choice.

psc:

It's not a big deal. I was under the impression that you hacked the Recovery Console CLI to appear on the pre-Win32-subsystem screen, but could be wrong. (Before the mouse cursor.) I was just looking into various native-mode uses in existence. Please don't spend time to correct the WinBuilder scripts just for me, as it wasn't too important; just investigation.

dog: MINLOGON.EXE from Windows XP Embedded is a Win32-mode program. I'm thinking more along the lines of native-mode programs. For example:

• PXE boot any system to PXELINUX
• Run a COMBOOT32 module which queries the server for instructions based on model
• Unknown model? Take "model discovery" action
  
  • Boot via SMB or boot via RAM disk, both described further down below
• Boot a trivial MEMDISK including the correct HAL and kernel and network drivers (hopefully < 5 MB)
• Re-image HDD or add/remove files to it or modify the Registry on the HDD or whatever
• Inform server that task(s) is/are complete
• Reboot

SMB method:

• Boot Windows via TFTP, then via SMB using SETUPLDR
• Make a folder with the model's name in the booted-from share
• Quite simply save the booted HAL and kernel (determined by SETUPLDR) to the model folder
• Quite simply dump HKLM\SYSTEM\CCS\Enum\ to the model folder
• Requires RIS NIC driver to be known and served by Sherpya's binlsrv.py (or MS RIS)

RAM disk method:

• Boot Windows as a RAM disk (WinVBlock, FiraDisk, whatever) using SETUPLDR
• Save some state somewhere in RAM, such as HAL and kernel chosen by SETUPLDR, HKLM\SYSTEM\CCS\Enum\ dump
• Reboot
• COMBOOT32 module finds saved state in RAM (we hope) and communicates it to server
• Idle until server has a better image for us to boot/better instructions

These are a couple of thoughts for how to control/manage brand new, PXE-booted models.

psc:

It's not a big deal. I was under the impression that you hacked the Recovery Console CLI to appear on the pre-Win32-subsystem screen, but could be wrong. (Before the mouse cursor.) I was just looking into various native-mode uses in existence. Please don't spend time to correct the WinBuilder scripts just for me, as it wasn't too important; just investigation.

Thanks for your reply!
BSOR is not 'hacking'. BSOR is just taken from source CD files.
The nativeEx idea is "Use what is, but ONLY what is, on the source CD"

Peter

@Sha0
XPCLI uses ONLY minlogon from embedded.
Sure it is a Win32 mini-environment, but unless you have a size limit very, very small in mind, it is as small as it can get without requiring re-writing "native mode" apps.

WINROOT is probably more like what you had in mind, but the point remains, the mini-os that "Windows OCManage" or AeroXP or Alex Ionesco put together is IMHO nothing but a proof-of-concept and cannot say how much work is needed to rewrite from scratch (or almost from scratch) something like good ol' O&O Blue Console.

BSOR is just the recovery Console - if I am not mistaken, a Winbuilder .script replicating -possibly bettering it - the behaviour of the batch discussed here:
http://www.boot-land...?showtopic=2254

I guess (but I may be completely wrong of course) that writing a replacement for minlogon.exe it somewhat easier than writing a native CLI, with the advantage that while there are very few "native" apps, one worth of mention is the native registry here:
http://www.boot-land...?showtopic=3782
we have all kind of utilities, command line or GUI, that can run in Win32.



Wonko

@Sha
Your post is to lenghtly to answer all qestions and correct all errors, line by line. So here in short.

Setupldr does not detect HAL and Kernel unless it is used in a Network boot, but you can always use the single processor Kernel that's how PE1.0 do it.
Or, if you only use newer machines, always use the multi processor Kernel.

Please tell me something: Why is it that when I boot my ancient BartPE CD on different types of hardware, run Process Explorer (ProcExp.exe), highlight the System process, look at the .DLL list, that I will see different HAL*.DLL files having been loaded into use depending on what type of hardware I booted? Who does this if not SETUPLDR (which is responsible for loading HAL and kernel files)? Why is it that the Recovery Console's CMDCONS\ directory includes a variety of HAL*.DLL? Why does it have information for the different HAL types in TXTSETUP.SIF, with NTDETECT.COM on some of the same lines?

Even if SETUPLDR always uses the UniProcessor kernel, how does that help us with an automated process for choosing the correct kernel choice for a computer? That's part of what I'm after.

A PE does not require to add anything to the registry to add drivers. Drivers required for boot are added to txtsetup.sif.

I don't quite follow you here. I agree that SETUPLDR and TXTSETUP.SIF are responsible for choosing boot-time drivers; not sure what question or error you are addressing here.

To get around the BSOD on Boot, you'll have to install all boot drivers for all machines, you'll ever gonna use PE on. If you don't, you'll have to rebuild a few times.

Agreed. This is why I said you can avoid this by using a RAM disk.

The idea to use RAM-Disk to not need other drivers is pointless. This will sure give you a running PE on all systems, but without CD/DVD/HDD access.

Not too sure why you suggest this is pointless... A Windows booted in a RAM disk can still enumerate the devnode IDs for devices. If you have networking, you can communicate that information as well as load further OS components, including drivers. Also, my thoughts were mostly based on remote-control or remote-deployment scenarios, where "CD/DVD" is not so important.

Thanks for sharing this feedback.

Please tell me something: Why is it that when I boot my ancient BartPE CD on different types of hardware, run Process Explorer (ProcExp.exe), highlight the System process, look at the .DLL list, that I will see different HAL*.DLL files having been loaded into use depending on what type of hardware I booted? Who does this if not SETUPLDR (which is responsible for loading HAL and kernel files)? Why is it that the Recovery Console's CMDCONS\ directory includes a variety of HAL*.DLL? Why does it have information for the different HAL types in TXTSETUP.SIF, with NTDETECT.COM on some of the same lines?

Then your BartPE is setup wrong. There are certain combinations of Kernel+HAL which are valid and some that are not.
By just switching the HAL, which setupldr can do, but not the Kernel, it is possible to get a combination that does not work.
Therefore it should best not be done.

Even if SETUPLDR always uses the UniProcessor kernel, how does that help us with an automated process for choosing the correct kernel choice for a computer? That's part of what I'm after.

As said, only during a network boot, setupldr will also switch Kernels.
If you hack setupldr, you might be able to convince it to this also with other boot methodes.

I don't quite follow you here. I agree that SETUPLDR and TXTSETUP.SIF are responsible for choosing boot-time drivers; not sure what question or error you are addressing here.

The error that you want to write the drivers in the CriticalDevicesDatabase.

Not too sure why you suggest this is pointless... A Windows booted in a RAM disk can still enumerate the devnode IDs for devices. If you have networking, you can communicate that information as well as load further OS components, including drivers. Also, my thoughts were mostly based on remote-control or remote-deployment scenarios, where "CD/DVD" is not so important.

Ok, then you're the exception. Usually everyone needs HDD access.
So, not pointless for your goal.

Then your BartPE is setup wrong. There are certain combinations of Kernel+HAL which are valid and some that are not.
By just switching the HAL, which setupldr can do, but not the Kernel, it is possible to get a combination that does not work.
Therefore it should best not be done.

MedEvil: Please tell me something more: Why is it that when I remove HALAACPI.DLL from the Recovery Console and boot that with QEmu 0.9.1, SETUPLDR gives me the message

File \CMDCONS\halaacpi.dll could not be loaded.
The error code is 14.

Setup cannot continue. Press any key to exit.

?
Why is it that when you put HALAACPI.DLL back and remove HAL.DLL, then run the same HDD with the same QEmu, but like this

qemu -no-acpi -hda cmdcons.hdd -boot c

the message changes to

File \CMDCONS\hal.dll could not be loaded.
The error code is 14.

Setup cannot continue. Press any key to exit.

? Is Recovery Console broken, too? What do you think Windows XP Setup will do if you try the same test by remastering the CD without the different HALs?

In regards to HAL and kernel combinations, are you referring to this[1] ?

If I understand you correctly,

Setupldr does not detect HAL and Kernel unless it is used in a Network boot, but you can always use the single processor Kernel that's how PE1.0 do it.

means the same as

By just switching the HAL, which setupldr can do, but not the Kernel,

Is that correct?

As said, only during a network boot, setupldr will also switch Kernels.
If you hack setupldr, you might be able to convince it to this also with other boot methodes.

Do you happen to have a reference where I could learn about this difference between the network-booting behaviour and the non-network-booting behaviour?

The error that you want to write the drivers in the CriticalDevicesDatabase.

I have failed to communicate and I apologize. An idea I offered was to use a minimal Windows to process a separate Windows installation that's on the HDD. In the Windows installation, you can modify its Registry's CriticalDeviceDatabase key to include entries which should invoke the appropriate HDD controller when that Windows installation boots. If you match your minimal Windows' OS files to the files used in the HDD installation, you will know the devnode IDs to inject into the CriticalDeviceDatabase, because your minimal Windows is running on the hardware itself and thus knows the IDs.

I did not mean to suggest modifying the minimal Windows' CriticalDeviceDatabase. If your minimal Windows is a PE, TXTSETUP.SIF is the place to load drivers, as we both have agreed. If your minimal Windows is not a PE, then you would indeed modify its CriticalDeviceDatabase to help it to boot from HDD. However, I have offered the idea of booting the minimal Windows from RAM disk or via network, so this does not apply.

Ok, then you're the exception. Usually everyone needs HDD access.
So, not pointless for your goal.

Yes, and so do I. If the minimal Windows is booted into RAM and has networking, you can then load your disk controller driver(s) and access the HDD. You can then re-image the HDD, swap in the correct HAL and kernel, copy drivers, put entries in the HDD's CriticalDeviceDatabase, copy software to run on first-boot or Mini-Setup, etc.

[1] HAL options after Windows XP or Windows Server 2003 Setup

@Sha0
If you think you know it all better, please be my guest and go ahead any way you see fit.

@Sha0
If you think you know it all better

No. I do not work for Microsoft. I have asked for feedback and am trying to learn. You've given feedback and I thank you for that. If there isn't a reference to how the network-booting behaviour is different than the non-network-booting behaviour, then could I ask about what experiences you've had that suggested that difference? It's pretty important to me that you brought this up, since if something to share (binaries) results from this discussion, it should be designed by making the most of the information available, especially in this great forum. Thanks. - Sha0

setupldr.bin does detect the HAL.

But usually it doesn't detect the kernel and loads ntoskrnl.exe.

There is a patch for kernel auto detection (nikzzzz or cryptoPe made it)

You can find it in BootSDI and WimBoot script.

@Sha0
If you think you know it all better, please be my guest and go ahead any way you see fit.

No. I do not work for Microsoft.

Ow, comeon peeps... use some logic:

The only ones that "know it all better" do not "work for Microsoft", they own it!




Wonko

If there isn't a reference to how the network-booting behaviour is different than the non-network-booting behaviour, then could I ask about what experiences you've had that suggested that difference? It's pretty important to me that you brought this up, since if something to share (binaries) results from this discussion, it should be designed by making the most of the information available, especially in this great forum.

There is no reference as far as i know, but if you decompile setupldr, you can read it.
It has 3 routines: 1 for booting from CD/DVD, 1 for booting from HDD and 1 for booting from network.
The last one is the only one, which can switch kernel depending on single / multi processor.

MedEvil:

My End-User License Agreement prevents me from decompiling Windows, so I was not aware of that. I sincerely appreciate you bringing this forward, since it affects design plans towards a system that uses a minimal Windows (A) to manipulate an HDD and some Windows installation (B) on that HDD.

For example, if A is booted via RAM disk, this is not a "network-boot" as far as SETUPLDR would be concerned, so if what you say is true, A is constrained to use only the UniProcessor kernel. Thanks.

For example, if A is booted via RAM disk, this is not a "network-boot" as far as SETUPLDR would be concerned, so if what you say is true, A is constrained to use only the UniProcessor kernel.

No, you did not get it 100% right.
A boot from ramdisk is treated like a boot from HDD and therefore setupldr has not the ability, to switch automaticly kernel images, acording to the type of detected processor.
It does not mean, that you have to use uniprocessor image.
You can also use multiprocessor image. You just need to rename the files.




edit:
PS: WinPE2.0 and 3.0 have the ability to switch HAL and Kernel as far as i know. Maybe you want to use rather one of those.