623 replies to this topic

[Sha0]

Blah! I fixed a recent BSoD where you load networking components, but forgot to release it! Here it is, as version 0.0.0.2. - Sha0

Attachment removed -- Obsolete due to newer version; check post #1 for download link.

[dog]

0.0.0.2 works here with xpsp3, no BSODs
I get three instances instead of two though:
ROOT\SCSIADAPTER\0000
ROOT\WINVBLOCK\0000
ROOT\WINVBLOCK\0001

That's with a voluntary reboot after each driver installation - the first time I installed it I tried to fix each "unknown" device without a reboot in between, and got to 4 or 5 device instances before I gave up and rebooted.

I tried 0.0.0.1 with NT4 - and got the expected result

[Sha0]

Hey dog: You might have missed the post at http://www.boot-land...?...ost&p=76898 where I explained that Add New Hardware Wizard adds a SCSI device, and the other one is created automatically to support scenarios where the driver is loaded from Windows' SetupLDR via TXTSETUP.SIF. You see, in order to have WinVBlock work by merely popping a reference to it in TXTSETUP.SIF, the driver has to create its own device. However, as I mentioned before, I'm trying to rethink that strategy. The Registry reworking that I'm currently doing is to get rid of this two-device scenario. By the way, you should leave the unknown device untouched, and do not Update Driver on it. You can simply leave it alone.

Thanks for the NT4 report. I think you might be the first to have tried. Only one question, though: What was the expected result?

- Shao

[dog]

Ah thanks, I'll try that.

Trying to install 0.0.0.1 on NT4 sp1 fails with "no entry point IoInvalidateDeviceRelations in ntoskrnl.exe"
The aoe docs said win2k and above, so I didn't expect it to work.

Would it be possible to install the driver using devcon or some other automated way?
I had a quick go with devcon but without success.

Cheers for the update

[Sha0]

WinVBlock 0.0.0.4 released.

Still no CD/floppy support (they are emulated as HDDs right now). That's next on the ToDo.

Supports the most recent MEMDISK mBFT & "safe hook" changes from Syslinux-3.84-pre6. This means multiple MEMDISKs are found and used.

A MEMDISK binary is included in the .ZIP file. Use it. It has two patches which are not in MEMDISK "proper" quite yet (I'm sure will be very soon).

Thanks to H. Peter Anvin for incorporating the mBFT and "safe hook" into the official MEMDISK. A Linux driver is now possible, too.

Enjoy.

- Shao Miller

Attachment removed -- Obsolete due to newer version; check post #1 for download link.

[Sha0]

WinVBlock 0.0.0.6 released.

Supports multiple MEMDISKs, multiple GRUB4DOS RAM disks, CD/DVD RAM disks from both MEMDISK's and GRUB4DOS' El Torito emulation.

Tested on Windows XP Professional with Service Pack 2.

Floppy emulation is half-done; they show up as removable media. done, too.

- Sha0

Attachment removed -- Obsolete due to newer version; check post #1 for download link.

[Sha0]

Oops! I forgot that ODDs (optical disc drives) should have a 2048-byte sector-size. That's fixed in WinVBlock 0.0.0.8 below. Sorry about that!

A quick-o tutori-o for an XP SP2 PE .ISO:

Use Bart's PE Builder ("'cause being an Admin is hard enough...") or WinBuilder or whatever to build a PE .ISO with the following simple modifications:

• Put WVBLK32.SYS (or 64) in I386\SYSTEM32\DRIVERS
• Add the following to I386\TXTSETUP.SIF:

  [SCSI.Load]
  
  wvblk32 = wvblk32.sys,4

If you want automation from PE Builder without doing the above steps, ensure a directory layout like the following:

C:\pebuilder3110a\drivers\SCSIAdapter\wvblk32\

C:\pebuilder3110a\drivers\SCSIAdapter\wvblk32\txtsetup.oem

C:\pebuilder3110a\drivers\SCSIAdapter\wvblk32\winvblk.inf

C:\pebuilder3110a\drivers\SCSIAdapter\wvblk32\wvblk32.sys

You can easily test MEMDISK (use the included one!) functionality with QEmu:

C:\Progra~1\QEmu>qemu -kernel memdisk -append "iso" -initrd bartpe.iso -hda empty.hdd -m 384

where you have the files memdisk, bartpe.iso, empty.hdd inside C:\Program Files\QEmu\ and where empty.hdd is just some garbage file (I usually use 10 MB) in case QEmu demands an HDD. Some hardware also requires the raw option for MEMDISK: -append "iso raw"

You could also test GRUB4DOS functionality if you have the .ISO in a partition with something like:

grub> root (hd0,0)

grub> map --mem /bartpe.iso (hd32)

grub> map --hook

grub> root (hd32)

grub> chainloader (hd32)

grub> boot

Pretty simple, I hope!

Oh, and I realized that floppy emulation actually already worked; my testing environment already had two physical floppy drives, so the additional ones showed up differently than I had expected in My Computer.

- Shao Miller

Attachment removed -- Obsolete due to newer version; check post #1 for download link.
45 downloads at time of removal.

[zhhsh]

Excuse me,Does it support Windows 2003 ?

-zhhsh

[Sha0]

Actually, it didn't seem to support a Windows 2003 PE .ISO previously... But it should now!

Here it is, attached. Version 0.0.1.0.

- Shao Miller

Attachment removed -- Obsolete due to newer version; check post #1 for download link.
10 downloads at time of removal.

[Sha0]

Hmm... I noticed a Blue Screen of Death when testing XP and 2003 PE .ISOs after loading PE Network Configurator.

The reason is because while WinVBlock depends on NDIS.SYS in order to maintain WinAoE functionality, in PEs you need to have NDIS start before WinVBlock. You do this with TXTSETUP.SIF entries:

[BootBusExtenders.Load]

ndis = ndis.sys

...

...

[BootBusExtenders]

ndis = "NDIS"

...

Full Windows environments should not have this problem, as far as I know.

Any feedback or test results from anyone? I still have some features to add.

- Shao Miller

[dog]

Just installed 0.0.1.0 on a 1.5GB xpsp3, grub4dos loaded it to ram ok.
I'd tried 0.0.0.8 but rebooted it accidentally before copying it to an image, told xp not to install a driver for the "Unknown device", on booting the image got stop 6b.
Could we have a changelog in the zip file? The docs are still all about AOE.
What features are you plotting ?

[Sha0]

Ask and ye shall receive...

WinVBlock 0.0.1.1 (attached) includes 32- and 64-bit compilations which compiled cleanly under a Vista/2008 build environment. Whether it works with Vista or not is yet to be tested.

This version includes the change-log from the git commit history.

This version removes the annoying unknown device, at long last. If you use Add Hardware Wizard, all will be well. If you are simply injecting the driver via TXTSETUP.SIF entries, all will also be well (you will have the unknown device only). No duplicates!

A couple of features to add include file-backed disks as well as sector-mapped disks, which could eventually turn into RAID.

Thanks!

- Shao Miller

Attachment removed -- Obsolete due to newer version; check post #1 for download link.
16 downloads at time of removal.

[TheK]

A couple of features to add include file-backed disks as well as sector-mapped disks, which could eventually turn into RAID.

Yes please

That would great! My board only supports USB 1.1 at POST and I hate to stare 15 minutes at a black screen, waiting for grub4dos to load 500MB to RAM

[Sha0]

While working through creating the Recovery Console RAM disk tutorial at http://www.boot-land...?...ost&p=87805 I noticed that the recent addition to remove the silly unknown device actually caused a regression with Recovery Console. The Recovery Console wants the disks available ASAP; checking for an already-installed bus device and installing the disks after that check is too late.

SO: Here is WinVBlock version 0.0.1.2, which supports BOOT.INI or TXTSETUP.SIF switches, such as:

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP" /fastdetect /winvblock=bus=1 /sos

- Sha0

Attachment removed -- Obsolete due to newer version; check post #1 for download link.
31 downloads at time of removal.

[Krokodox]

Sha0, thank you for your time and effort in creating WinVBlock!


I finally managed to achieve something that I thought was impossible just 6 months ago, i.e. network booting W2K3 without having to complicate life with iSCSI. This will also allow me to implement high-availability since it is possible to have several HTTP servers serving the bootimages.

Many thanks for the tight integration with MEMDISK, now the RAM booting only "steals" 400MB RAM leaving a whopping 1.6 GB for the server.

As soon as I can I will create a documentation for how to re-create my success, hopefully enabling other people to make use of your fantastic WinVBlock!


I have done some performace testing on the RAMDisk and foudn that it is quite a lot faster for writing operations than for reading! This is quite strange, however it is still a lot faster than using the local harddisk



Anyway, if there is one thing that I could wish for than it would be to have the option of having WinVBlock create a "snapshot" of its current state, i.e. to create a new .IMG file (complete with MBR, bootloader, etc) that can be used for next re-boot. This way one could create a "master image", boot it up on some other hardware, let PnP have its way and install whatewer software one would like, and save a "new" master image.


No matter what, WinVblock is simply brilliant in its ability to bridge pPXE / MEMDISK / Windows booting and I really look forward to any further enhancements!

[dog]

Anyway, if there is one thing that I could wish for than it would be to have the option of having WinVBlock create a "snapshot" of its current state

corsair reported success doing this with firadisk and volume shadow copy, so you can probably do the same with winvblock.

[dog]

I tried loading a 1.5GB xpsp3 from grub4dos with versions 0.0.1.2 and 0.0.1.1, with images made straight after installing and after a reboot, all gave

Stop c000021a
Fatal system error
The Session Manager Initialization system process terminated unexpectedly with a status of 0xc000003a



Does it work with boot.ini switches, or with memdisk rather than grub4dos?

Cheers for the changelog

[Krokodox]

I tried loading a 1.5GB xpsp3 from grub4dos with versions 0.0.1.2 and 0.0.1.1, with images made straight after installing and after a reboot, all gave

Stop c000021a
Fatal system error
The Session Manager Initialization system process terminated unexpectedly with a status of 0xc000003a



Does it work with boot.ini switches, or with memdisk rather than grub4dos?

Cheers for the changelog

Welcome to the club, I have seen a lot of those lately I encounter them while trying to transfer the running image to a new smaller imagefile. All seems to be well, i.e. the MountedDevices in the registry are up-to-date (or is empty), there is nothing wrong with the consistency of the filesystem and the permissions for files / folders is OK.

It does not matter if I copy the running image with VSS or if I mount the image offline and do an exact copy of the files to the new imagefile.

I have tried with compressed and uncompressed resulting image, I have tried with larger resulting imagefile: but with no success.

The only thing I have that is different is that the cylinders / heads / sectors for my "original" image is yy/64/32 while the new, smaller imagefile has xx/255/63. Mounting with ImDisk shows both imagefiles to be operable and examining the MBR and PBS shows that all is well. The new image boots and shows the splashscreen and thereafter switches to the BSOD as per above.

[dog]

You could try killchs:
http://www.boot-land...?...=8528&st=21
or I use grub4dos to do the same thing:

title kill chs of ntfs pbr (hd0,0)+1

cat --skip=217 --length=4 --locate=\x0F\x82\x3A\x00 (hd0,0)+1 && write --offset=217 (hd0,0) \x90\x90\x90\x90

pause

I've not got VSS to work with winvblock yet, on xp with version 0.0.1.0 I get

ERROR: COM call "m_pVssObject->AddToSnapshotSet((LPWSTR)volume.c_str(), GUID_NULL, &SnapshotID)" failed.

- Returned HRESULT = 0x8004230f

- Error text: VSS_E_UNEXPECTED_PROVIDER_ERROR

Although it might be down to my having disks with the same signature, I need to do more research...

[Sha0]

Krokodox: You're welcome, I'm sure.

With thanks to karyonix (the FiraDisk developer) for karyonix' post regarding __movsd, I've implemented a routine which should improve the performance for RAM disk I/O. It'll be available in the next release.

In regards to capturing the live running state... I've personally used WinVBlock to take a small Windows and "port" it across a variety of hardware platforms so that the image contains all of the installed devices for those hardware platforms. I do this very simply with DD for Windows. Usually I will run sync.exe from Microsoft's SysInternals first.

C:\Windows\System32>dd if=\\.\PhysicalDrive1 of=\\someserver\someshare\RamXP.HDD --progress

Krokodox, dog: I find it unusual that VSS would have any issues with WinVBlock, since WinVBlock provides the disk, not the volume.

These session manager initialization errors seem odd to me; for the session manager to start implies that it was successfully read from the filesystem on the WinVBlock disk. That it should shut down is what's odd.

dog: The tests that I run with every build establish both MEMDISK as well as GRUB4DOS RAM disks and I always check that they show up in My Computer and have files, so it should work with both. The boot.ini switch should only be used if you did not install the WinVBlock SCSI adapter using WinVBlock's .INF file and the Add New Hardware wizard. If you did install this SCSI adapter, don't use the boot.ini switch to automatically create the bus (SCSI adapter).

How about some examples of Syslinux or GRUB4DOS configurations that are yielding this error, in case they're relevant? How many disks are in the computer system having this error? Could a physically installed disk with the same signature as the RAM disk be causing the trouble?

[dog]

Krokodox, dog: I find it unusual that VSS would have any issues with WinVBlock, since WinVBlock provides the disk, not the volume.

Sorry, fixed VSS now. I'm not sure whether it was due to the ram disk having the same sig as the real HD, or due to leaving a v0.0.1.0 "unknown device" with no driver, but forcing a driver install and rebooting until no "unknown device" appeared seems to have fixed VSS.
I'll try later versions again tonight without the signature clash
Thanks!

[dog]

Yup, 0.0.1.2 works fine now, whether imaged straight after install or one reboot later. It only crashes when the ram disk has the same disk signature as the HD.

In other news, my attempts to use robocopy with vshadow doesn't work properly, but I might save that fun for another day.

[acus]

Hello,

I created a livexp.iso and put WVBLK32.SYS in I386\SYSTEM32\DRIVERS.
I also modified txtsetup.sif like described in posts #107 and #110.

I want to boot this iso with grub4dos in virtualbox emulator.

Please, what is the directory structure and what are the files needed for this task?

Thanks & regards

[Krokodox]

Hello,

I created a livexp.iso and put WVBLK32.SYS in I386\SYSTEM32\DRIVERS.
I also modified txtsetup.sif like described in posts #107 and #110.

I want to boot this iso with grub4dos in virtualbox emulator.

Please, what is the directory structure and what are the files needed for this task?

Thanks & regards

I actually never managed to boot from RAMDisk in VirtualBox, neither with Firadisk nor WinVBlock. VirtualBox stops because of some form of access violation. More precisely: It is VirtualBox that stops the VM, not the booted image having a BSOD.


I create an installation .ISO with the help of nLite, adding all SP's and Hotfixes that exists. I also add all HW drivers that the target computers have. I then boot this .ISO in VirtualBox and let it create an installation that I modify to suit my needs. When all is done I install the WinVBlock through "Add/Remove Hardware" in the Control Panel (somehow WinVBlock does not like to be added with nLite, it makes nLite show an errormessage).

Once the VM in VirtualBox is done I either take a snapshot with VSS and can thus copy the resulting files, or I make an image of the whole disk with Selfimage (http://selfimage.excelcia.org/). Selfimage gives a complete byte-for-byte copy of the drive including the MBR and all. The copy has the same size as the harddisk for the VM and this image I can boot with PXE to gPXE to MEMDISK to RAMDisk.

[Krokodox]

Sorry, fixed VSS now. I'm not sure whether it was due to the ram disk having the same sig as the real HD, or due to leaving a v0.0.1.0 "unknown device" with no driver, but forcing a driver install and rebooting until no "unknown device" appeared seems to have fixed VSS.
I'll try later versions again tonight without the signature clash
Thanks!

Use MBRFix (http://www.sysint.no...ting/mbrfix.htm), it can change the disk sig and do other useful stuff to the MBR