Profile
Personal Photo
Rating
 
Options
Options
Personal Statement
Andy Tim doesn't have a personal statement currently.
Personal Info
Andy Tim
Newbie
Age Unknown
Gender Not Set
Location Unknown
Birthday Unknown
Interests
No Information
Other Information
Country:: Canada
Statistics
Joined: 1-August 07
Profile Views: 0*
Last Seen: 23rd January 2008 - 12:20 AM
Local Time: Feb 27 2008, 10:30 AM
8 posts (0 per day)
Contact Information
AIM No Information
Yahoo No Information
ICQ No Information
MSN No Information
Contact Send Message
Contact Private
* Profile views updated each hour

Andy Tim

Members

*


Topics
Posts
Files E2T
Comments
Friends
My Content
5 Aug 2007
Read Topic
Network Booting XP
Hello everyone,

I've been messing around trying to see if I can boot Windows XP in full mode (not setup-mode or /MININT mode) entirely over the network. I've done it a million times with Windows XP PE (via BartPE). It's such an interesting process, the XP boot process...
  • The computer PXE-boots
  • A DHCP address is obtained from my Cygwin DHCPD
  • My DHCP server recommends STARTROM.N12 as a boot file
  • The computer downloads STARTROM.N12 from my Cygwin TFTPD
  • STARTROM.N12 runs and downloads NTLDR via TFTP
  • This is where we branch in different directions for BartPE and full XP, based on NTLDR. I am only discussing full XP in this post
  • The Windows XP Embedded NTLDR runs and downloads BOOT.INI via TFTP and gives the boot menu:
CODE
[boot loader]
timeout=30
default=ramdisk(0)\WINDOWS

[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional from Hard Disk" /fastdetect /sos /bootlog
ramdisk(0)\WINDOWS="ramdisk(0)\windows from net(0) HALAACPI" /fastdetect /rdpath=net(0)\foo.sdi /rdimageoffset=36352 /sos /bootlog /hal=halaacpi.dll
ramdisk(0)\windows="ramdisk(0)\windows from net(0) HALACPI" /fastdetect /rdpath=net(0)\foo.sdi /rdimageoffset=36352 /sos /bootlog /hal=halacpi.dll
net(0)\windows="net(0)\windows" /fastdetect /sos /bootlog
  • If we choose one of the ramdisk boots, NTLDR downloads FOO.SDI as a ramdisk, then starts loading the OS from it
  • If we choose the net(0)\windows option:
    • NTLDR starts loading the OS via TFTP!
      --- START OF GUESSWORK ---
    • When it's time to make the switch away from BIOS routines, the Kernel checks the ARC path which we were loaded from
      (You can use Sysinternals' [now Microsoft's] WinObj to see that ARC paths are shortcuts to filesystems)
    • The Kernel doesn't see a net(0) shortcut pointing to any filesystem
      --- END OF GUESSWORK ---
    • The Kernel displays a Blue Screen of Death with STOP 7B

Although it's guesswork, I think I might have learned something about the boot process that I never knew before... I always thought UNMOUNTABLE_BOOT_VOLUME had to do with not having a device (under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}) with a MatchingDeviceID of "gendisk" and not having a device (under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE, for example) with a ComptabileIDs including "GenDisk". Now I don't think so. Now I think this is what happens:
  • As .SYS files are being loaded (as seen with /SOS), each one has an initialization routine which is called
  • Microsoft's RAMDISK.SYS recognizes an available ramdisk loaded by NTLDR and associates that memory with a volume (like \Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750})
  • RAMDISK.SYS then creates a shortcut from ramdisk(0) to the volume, as can bee seen with WinObj
  • When the Kernel decides to switch from using BIOS routines, it checks the ARC path
  • The Kernel sees the shortcut from the ARC path of "ramdisk(0)" to "\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}", so it uses the NTFS filesystem all the way through the MS Ramdisk Controller to access the volume

I could be wrong; it could be NTLDR who makes the ramdisk(0) ARC shortcut. Whatever.

If this is all true, and all you need is an ARC shortcut to your boot volume, perhaps someone could write a small .SYS file who will be loaded at boot time and make the "net(0)" shortcut point to "\Device\LanmanRedirector\Registry_stored_fileserver\Registry_stored_fileshare". Then maybe at the big switch, we wouldn't get a blue screen!

The point of all of this is to run full XP over the network, without using a ramdisk. Let me know what you think.
1 Aug 2007
Read Topic
ImDisk as Network Boot Device or Disk Driver
Hello all,

Thanks for the great product, Olof.

We see various technologies today like Citrix, Ardence, Softricity, Neoware produce, using filesystem filters and lower-level disk virtualization drivers. The idea of various disk and filesystem levels with transparency for the end-application probably should have been implemented a long, long time ago. It has been possible with Linux for some time.

We notice two technologies released with Windows XP Embedded: Sector Disk System Deployment Image (SDI) and Enhanced Write Filter (EWF). SDIs are virtual disk drives, EWFs are an implementation of volume (filesystem) layers. There is another fellow from MS who comes in useful for booting Windows, the Windows Server 2003 RamDisk. With Vista we get .WIM files.

I have seen the postings at http://www.boot-land.net/forums/RAMdisk-an...vers-t1507.html and see that some of the links there (like the VDK link) mention whether their drivers are disk drivers or filesystem drivers.

So Windows XP in /MININT mode is not quite as useful as in regular mode. But how can we load a "real" XP to RamDisk or perhaps over the network? What we need is what Ardence (now Citrix) and I believe NeoWare have: a disk driver with low-level network functions. What would be ideal to me is if ImDisk were wrapped by or changed to a disk driver instead of a volume driver. Additionally, low-level network capabilities could be added so it could provide the virtual disk with a network-backed file store. Even better than that would be if the networking could switch between a low-level mode and a higher-level mode. I realize that this post is all over the place so let me paint a picture:

- A PC PXE-boots a very small HDD image.
- This image has NTLDR and starts loading Windows
- Once we start accessing files with the virtual disk driver (some super ImDisk version) read-write operations go over the ethernet cable with a tiny IP stack to a file-store
- Windows XP loads up, loads up high-level networking stacks
- The virtual disk driver switches to use the high-level networking
- A user disconnects the original PXE-boot media cable
- The virtual disk driver sees that the backing file-store resource is available wirelessly
- The PC is empty: no optical disk drive, no hard disk drive, no USB stick, no network cables
- The PC is running full-blown Windows XP

Maybe the virtual disk driver could optionally reserve some RAM to allow file operations to take place while the file-backing was unavailable. Maybe the driver could use registry parameters to try other fallback file-stores on alternate servers (as long as the image was the same!).

If a filesystem delta layer was added to this to allow changes to be saved separately from a base image, you might as well eat your hat with glee.

While I've probably only succeeded in confusing a reader, I think that a good starting point would be to offer ImDisk as a disk driver, rather than as a volume driver. Or both! How hard would it be to convert it or wrap it? I know that the MS RamDisk sample might be useful for this. While driver programming has always been my locked door, I would certainly contribute in any way I could to this effort.

What think the excellent community here?
Last Visitors
BLJ


20 Feb 2008 - 23:05
chos


5 Feb 2008 - 13:24

Comments
Other users have left no comments for Andy Tim.

Friends
There are no friends to display.
RSS Lo-Fi Version Time is now: 27th February 2008 - 03:30 PM

MKPortal ©2003-2006 mkportal.it

IPS Driver Error

IPS Driver Error

There appears to be an error with the database.
You can try to refresh the page by clicking here