Well, from a WinXPsp2 source, clean UBCD4win v3.60, and DP.net updates to:

Mass Storage: 12.09
LAN: 12.05
WLAN: 12.02

...the T530 booted fine :-). Quite happy, but mindful of the future - so thanks! I'll have to see just how inflexible DaRT is. But for now, as long as XP recognizes the hardware, a good old copy of ghost still does the trick.

Just got a new Lenovo T530 laptop after the holidays... sadly, my last build of UBCD4Win v3.60 won't cope with the newer hardware (had a T420 before this upgrade). I'm doing a build now with the latest driver packs for my source CD (XP), and I'll see what happens; but the prospect of failure had me wondering:

Since the thing that would drive me towards once bootable CD solution over another is a toss-up of either the availability of desired apps AND hardware support - and I still expect most of UBCD4Win based "apps" to work under an XP based boot CD on a Win7 host PC...

...what are folks who used to participate HERE in the BartPE / UBCD4Win area using nowadays considering that the UBCD4Win project folded some time ago, and we're well into an era of both newer hardware and host PC OS. I'd been watching several other projects for a bit of time back when I was hoping to trim down the size and boot time req'd by my UBCD4Win builds... but never really kept up with any of the other similar solutions out there. I'll cruise around some of those sites to see how people are getting on - but curious what the ~driver people are using in place of the 'ol UBCD4Win...?

Hi there... wondering if anyone here has been able to boot a Lenovo T420 laptop with the factory SSD drive with either BartPE or UBCD4Win (using latest/last 3.60 build here).

I found a thread concerning the previous laptop model (T410)... which I "also" have as the "loaner" prior to rec'ving the T420; and I have the same BSOD issue as the OP in that thread on BOTH the 410 and the 420. In my situation, I hadn't modified the driver pack or tried to slip in any specific drivers myself - from a "driver" perspective, it's a "clean source" as suggested by Overflow.

So I'm guessing that in both the T410 and T420 cases, it is likely a chipset and/or ssd issue (though other folks seem to be of the opinion that the bios settings for the ssd should allow XP to recognize the drive without explicit drivers - which I'll buy).

At any rate - any results from the community with the T420 w/ssd...? If you've got it working, share any steps to make it so? I'm going to go back to a completely fresh un-modified UBCD4win 3.60 and re-test in the meantime (but really, my standard build is just "application" mods, not driver stuff).

Briefly... I've just found that my UBCD4Win v3.50 build ~when built with Win2003 Server as the source~ allows my vmscsi plugin to work ok.

I've also since updated VMware Server to v2.0.2... so towards cdob's question above (sorry, I all-together missed your last response cdob) not sure if the VMware v1.0.5 environment was a different controller - but with v2.0.2 it is currently a virtual LSI controller in this guest image (which I did a v1.0.5 -> v2.0.2 virtual hardware "upgrade" on).

I'll go back and retry my WinXP based build on my upgraded v2.0.2 guest image to see what happens... but I've probably lost the VMware Server v1.0.5 environment.

Nope... same result. I'm stumped, and basically can't use 3.50 - if I want to tweak things and test them before burning that is :-(. Bummer... wish I hadn't deleted my 3.22 build folder.


Yep, same version of VMware, and again - using my last 3.22 based ISO still finds the vm disks just fine. So it's something unique to the v3.50 build. Either I'm doing something differently, or have "forgotten" to do something I did at some point to get the Drivers\SCSIAdapter driver add-on to work in 3.22 and older builds... though I can't imagine what that would be. I recall just being able to drop those files into a vmscsi folder under the Drivers\SCSIAdapter directory and be good to go...


Agree... you'd figure that newer version should work. But it never worked in v3.22 and prior either. I've always had to drop the files under Drivers\SCSIAdapter directory to be able to see the vm disks, and this is going back to even earlier builds of VMware server before 1.05 as well.

VMware Player is nice, but I need to create new images routinely, so I'm not just "playing" pre-built guest images...

I'll try makecab on the 1204 driver version that used to work before under the Drivers\SCSIAdapter directory, drop it into the driverpacks folder as you've suggested, and see what happens.

Hi all, congrats on the integration to date between the driverpacks and UBCD4win... job well done.

I've searched a fair bit, and figured it would be just as good to ask "here" as on the UBCD4win forum... particularly since my preference would be to have the driver bundled into the driver pack just "work".

Prior to v3.50 - I would just drop the files I'd long since gotten from a BartPE plug-in page out there in the ether into the Drivers\SCSIAdapter folder, and without any other modifications, booting a virtual machine from an ISO image built from the project (as late as v3.22) would just "work" - and I would see the virtual disks of the guest OS, and I could go ahead and test all my tools, etc. This no longer works, the driver seems to be ignored.

- WinXPprosp2 ISO image used as source for PE...
- Various VMware Server v1.05 built guest images...
- VMSCSI driver files as follows:


With v3.50, the vmscsi driver (vmscsi.sy_) seems to be included inb the Bâshrat the Sneaky driverpack, just as it had been with the one included with v3.22 - though I think the driver file is actually a bit 'newer' than in the previous build. But the one included with the Bâshrat the Sneaky driverpack back then never worked out of box back then either, though I didn't really care since I could just drop the old driver files under the traditional drivers sub-folder...

With v3.50, it seems the project is relying entirely on the driverpack now - and dropping the filers in the drivers sub-folder no longer works. I imagine that the original UBCD4win/BartPE driver compilation mechanism was grabbing something in the "vmscsi.inf" file that for whatever reason isn't included in the stuff that the driverpack puts in play... but I have no way of guessing what bits are "missing" or how to reinsert them. Here is the content of that inf file...

;This file contains the information required to load the driver for the VMware SCSI Controller

; Copyright (c) 2001 - 2004, VMware, Inc.

Signature="$Windows NT$"

1 = %DSKID1%,,,""

; Files for disk VMware SCSI Controller Installation Disk #1 (SCSIAdapter)
vmscsi.sys = 1,,






ServiceType=0x01		;KERNEL Driver
StartType=0			;Boot Time
ErrorControl=1			;Display Errors
LoadOrderGroup=SCSI Miniport

HKR, "Parameters\Device", "NumberofRequests", %REG_DWORD%, 128

HKR, "Parameters\PnpInterface", "5", 0x00010001, 0x00000001

AddReg = EventLog_AddReg


VMWARE="VMware, Inc."
DEVICE="VMware SCSI Controller"
DSKID1="VMware SCSI Controller Installation Disk #1 (SCSIAdapter)"

I've tried a few screwball things to re-add my known "working" collection of vmscsi files to the v3.50 project to no avail... So my question is two-fold:

1.)  Is there "something to do" to get the "VMSCSI_SY_" driver included in the driverpack to actually work and load when booting a v3.50 ISO from a VMware guest image?
2.)  Is there some process by which I can keep using the driverpack for everything that IS working, but SEPARATELY add the older vmscsi files that used to work under the Drivers\SCSIAdapter folder in some other manner