Migrate XP from SCSI to SAS without reinstall

[whocares02]

Hello forums,

I just bought a SAS-HDD as replacement for my old SCSI-HDD which stopped working. I have backups of all partitions and my biggest problem is good-old WinXP which just don't want to boot off a SAS-drive. It's basically the same problem as with the AHCI-drivers: There are plenty of forum-threads here, regarding to that Issue. Instead of migrating from IDE to SATA, I want to migrate from SCSI to SAS with out reinstalling EVERYTHING!

With my computer I have advanced possibilities:

-I still have a floppy-drive (for F6-Method)!
-My XP is fully upgraded with AHCI-drivers, SCSI-drivers and installed Recovery-Console
-My first (XP-)partition is bootable in Virtualbox! Yes, I can boot the physical HDD in vbox and install the SAS-drivers in safe-mode!
-I can boot from Linux and several Repair CDs to copy/edit files in my XP-partition or change the registry remotely.

My only problem is, windows is just not using the SAS-drivers after a real-boot with the SAS-drive (Inside virtualbox emulated IDE is used).

I know that the SAS-drivers are actually working because in recovery-console, I can hit F6-Key to use the drivers from floppy. So on real hardware I can successfully boot XP into recovery-console with this method. However, recovery-console doesn't offer any setup or install-options. It's not even possible executing .exe-files. What a useless crap! Why did they implement a F6-method for this console anyway?

So my question is: How do I tell XP to finally use the drivers, actually already present in the system? I always get 0x0000007B-error on boot, meaning "Inaccessible boot-device".

It's not that I don't know how to do a fresh install of windows or where to buy a newer version. I just want to make this happen! It's really bugging me this is actually not possible.

This is the best forum I know about, regarding this problem. So somebody please help.

 

I am using the driver "LSI_1068E_SASRAID_2k3_32" for my DELL SAS Raid SCSI 6/IR Controller Card.

I don't remember where I downloaded this driver, but I attached it here. Inside are drivers for Server2003 and Win2000. I already found out the Win2000-driver is the proper one. So symmpi.inf is the important inf-file. The second inf-file is some virtual-driver from microsoft and I'm not sure what's going on with this one. At least it's a very small file. The third inf-file ( LSI_SAS.INF) however is for Server2003-only. So this one is wrong. I attached the two important inf-files to this post, in addition.

symmpi.inf lsipseud.inf LSI_1068E_SASRAID_2k3_32.zip

Edited December 22, 2022 by whocares02

[whocares02]

Folks, I got it!

The most important clue came from here:  Injecting SCSI controller device drivers into Windows when it fails to boot after converting it with VMware Converter (1005208)

They recommend installing the driver in a virtual WinXP and copy the neccesary reg-entries out of it. According to the article, these reg-entries were most important:
 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\symmpi

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\
pci#ven_1000&dev_0030

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmscsi

The last reg-key however, is for the vmware-scsi-driver only. So the question comes up which additional reg-key to copy for the Dell/LSI-Sas-driver. I still can't say for sure because I propably copied a few too much. Here is what I did:

In virtualbox, I edited the properties of a XP-virtual-machine and added a SAS-Controller with a small HDD to it. For the SAS-controller (in vm-settings) I changed the number of ports from 0 to 1. This way the driver-setup will see a proper SAS-controller when installed later in virtual-WinXP. Virtualbox will emulate LsiLogic SAS! However the version slightly mismatches: The emulated one is a Dell 5/IR SAS-controller, my real one is a dell 6/IR. Because of this the exported reg-keys will need modification later. All occurances of "0054" in the reg-files need to be replaced with "0058", since this is the correct number according to symmpi.inf. The file reads at several places:

%DevDescD8% = NO_DRV, PCI\VEN_1000&DEV_0058&SUBSYS_1F0F1028

At the end of the file "%DevDescD8%" is explained:

[Strings]
LSI = "LSI Logic"
DELL = "Dell"
DiskDesc = "LSI Logic PCI Fusion-MPT Driver Install Disk"
DevDesc2 = "LSI Adapter, 2Gb FC, models 44929, G2 with 929"
DevDesc3 = "LSI Adapter, 2Gb FC, models 40919 with 919"
DevDesc4 = "LSI Adapter, 2Gb FC, models 7202,7402 with 929X"
DevDesc5 = "LSI Adapter, 2Gb FC, models 7102 with 919X"
DevDesc6 = "LSI Adapter, Ultra320 SCSI 2000 series, w/1020/1030"
DevDesc7 = "LSI Adapter, Ultra320 SCSI RAID series, w/1035"
DevDesc8 = "LSI Adapter, SAS 3000 series, 4-port with 1064"
DevDesc9 = "LSI Adapter, SAS 3000 series, 8-port with 1068"
DevDesc10 = "LSI Adapter, SAS 3000 series, 8-port with 1068E"
DevDesc11 = "LSI Adapter, SAS 3000 series, 4-port with 1064E"
DevDesc12 = "LSI Adapter, 4Gb FC, models 7104,7204,7404 with 949X"
DevDesc13 = "LSI Adapter, 4Gb FC, models 7104,7204,7404 with 949E"
DevDesc14 = "LSI Adapter, SAS RAID-on-Chip, 8-port with 1078"
DevDescD1 = "Dell SAS 5/E Adapter"
DevDescD2 = "Dell SAS 5/i Adapter"
DevDescD3 = "Dell SAS 5/i Integrated"
DevDescD4 = "Dell SAS 5/iR Integrated D/C"
DevDescD5 = "Dell SAS 5/iR Integrated Emb"
DevDescD6 = "Dell SAS 5/iR Adapter"
DevDescD7 = "Dell SAS 6/iR Adapter"
DevDescD8 = "Dell SAS 6/iR Integrated"
DevDescD9 = "Dell SAS 6/i Integrated"

So my card is DevDescD8, but the installed card will be one of DevDescD1 to ...D6. Which one, I don't know. However, they all have "0054" in their device-string, which needs to be replaced later.

Regarding to the additionally exported reg-entries: I will just attach the unmodified reg-files to the post.

I exported everything reading something with "SCSI", as long as it was not clearly related to some other driver (e.g. imdisk virtual disk driver). Also, I exported everything with "SYMMPI", since this is the important driver. In addition, I exported some reg-keys reading "{4D36E97B-E325-11CE-BFC1-08002BE10318}", since this is the number some SYMMPI-reg-keys refere to. All exported keys are sub-keys of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet

 

I think the most important files are:

• pci_ven.reg
• symmpi.reg
• class3.reg
• critdev1.reg
• critdev2.reg
• critdev3.reg
• enum-pci.reg

...since they have a direct reference to the symmpi-driver.

I also copied c:\windows\system32\drivers\symmpi.sys because this file seems to be a newer version and has bigger filesize (around 107 KB) than the one with the same name in the drivers-package.

So in virtualbox, I booted up the Real-XP-HDD in safe-mode, modified all reg-files to read "0058" insted of "0054", installed the two inf-files for win2k from the sas-textdriver-package and imported the modified reg.keys into the registry. Finally I copied over the newer driver-file symmpi.sys.

 

I should mention that I also installed the MergeIDE-Tool from the german computer-magazine ct, as recommended here. The tool modifies the registry to relax the windows-behavior when the IDE did change. This is an additional reason for 0x0000007B-errors. The article reads:

 

Quote

Windows memorizes which IDE/ATA controller it was installed on and fails to boot in case the controller changes. This is very annoying because you will run into this problem with basically all migrated images

The tool will change that. It's just a batch file that imports a reg-file. In addition it might copy some driver-files from the XP-Setup-CD.

Not sure if the MergeIDE-tool helped doing the trick. However, after booting the whole computer with the SAS-HDD, XP finally ATE THIS FU***** DRIVER and BOOTED-UP!

Of course automatic driver-install requested the driver again, afterwards and completed installation. There is an additional driver neccesary to satisfy some virtual-SAS-device in device-manager. This is done with another driver from the dell-homepage. I'm not quiet sure if the link has the same driver-version I used. So I just attached the file here, in addition (R170419.7z). This is a Win2k3-driver but it works nevertheless.

 

There is one drawback though: I marked all ntfs-drives of my computer to check with scandisk on next reboot. This caused a BSOD at the end of the checks. It was too quick to read and even safe-mode was not possible afterwards. However, choosing "last known good configuration" after boot-up and hitting f8-key brought back working XP from SAS.

 

Maybe somebody knows what's going on with that problem.

I'm happy anyway: I solved an everlasting problem and teached XP a lesson! This totally made my day!

 

Edit:

Forgot to mention:

It should be possible importing reg-files without virtualbox, using a winPE-BootCD. I haven't tried that. Regedit has the ability to import an external offline-registry and place it somewhere in the registry-tree. However, I don't think an imported reg-file will merge with that offline-registry this way. The offline-registry won't appear as the root of the whole registry. Probably the reg-file won't be imported to the correct position. So my virtualbox-attempt is safer.

 

pci_ven.reg ql1080.reg ql10wnt.reg ql12160.reg ql1240.reg ql1280.reg symc810.reg symc8xx.reg sym_hi.reg symmpi.reg sym_u3.reg ultra.reg class.reg critdev2.reg critdev3.reg enum-pci.reg

class.reg

Edited December 22, 2022 by whocares02

[jaclaz]

JFYI, and in case of need, there is a tool to edit offline registry files "directly" (without importing the hive(s) in Regedit):

https://labalec.fr/erwan/?cat=95

Reboot.pro is down, unfortunately, but there is a good guide for it here:

http://mistyprojects.co.uk/documents/offlinereg/offlinereg.htm

jaclaz

[whocares02]

Thank you very much! I noticed old reboot.pro-bookmarks didn't work anymore, in my browser. This is a shame! One of the most valuable websites on the web (besides msfn of course :-P ). I hope this is only temporary.

While console-based registry-edit of course is more professional, I made a quick websearch for a GUI-Editor. This one looks interesting:

Registry Editor PE

it's for integration in a WinPE-LiveCD. The screenshots look promising.

To capture the driver-installation I should have used something like this:

• RegistryChangesView takes two snapshots of the registry for comparison before/after a software-installation
• RegFromApp does basically the same but monitors a chosen program for the reg-changes it made

Both programs output .reg-files, listing all altered reg-keys. These .reg-files can be imported into the registry of another computer in the usual way. I would edit them manually to remove useless keys, since these programs usually capture a bit too much.

More cool regedit-tools are listed here.

Any clues why I got a BSOD after scandisk? Should I use the older symmpi.sys, shipped with the driver? I'm a bit afraid the system could be unstable in long-term. I don't dare running scandisk again.

 

Edited December 22, 2022 by whocares02

[whocares02]

Quote

However, after booting the whole computer with the SAS-HDD, XP finally ATE THIS FU***** DRIVER and BOOTED-UP!

I just realized, somebody might ask what "FU***** DRIVER" means. It means "fundamental driver" of course :-D ...

[jaclaz]

No idea about the BSOD after scandisk/Chkdsk, without a known STOP ERROR it could be *anything*.

The Merge-Ide is "safe" in the sense that the only thing that does is to restore the "Standardl" Microsoft  PCI/ATA controller driver (the one that is default when you install without any particular disk controller driver), it may (or it may not) have helped, but surely it didn't cause the BSOD in itself as by the time you rebooted and (auto) ran chkdsk it must have been already been replaced by the LSI driver.

It could also have been a random "glitch in the matrix", or it could be that *for whatever reasons* one of the volumes was mounted read only and chkdsk needed instead to change something on it

I think the only thing you can do is to make an image of the install volume (as a way back in case of issues) and see if the scandisk or chkdsk creates the issue again, as I see it chkdsk is a vital part of a Windows install, and you should not consider the install "stable" until you are sure that it works normally,

jaclaz

 

 

[whocares02]

Mmmh...I still have my backup of the partition and could start over from the beginning any time (still excited the SAS-drive can copy the whole partition in 5 minutes only). I'm sure it's the sys-file of the driver, I replaced with a newer version, already present in the virtual-windows-installation.

I see two options:

• Replacing the .sys-file with the original (older version) or
• using another driver, I found on the dell-website. It's a very old one but it's exclusively for XP-32-Bit (see attachment).

Also: Wasn't there some way to view the last BSOD in windows somewhere? Event-viewer shows nothing, unfortunately :-(

Wait, here...this looks good: Nirsoft Blue-Screen-View (Freeware), it's reading the crash-file C:\Windows\Minidump (provided crash-dumps are enabled in some windows-system-settings somewhere).

Will report back later.

 

Dell_SAS-Driver_WinXP_32Bit.7z

[jaclaz]

It is a good idea (always) to have the OS stop (and not reboot) on BSOD's (for next time):

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CrashControl

Autireboot

(set it to 0 to prevent rebooting)

Usually (but not always) minidump is enabled, so the nifty Nirsoft tool might be able to catch that  (past) BSOD, to check if the minidump is enabled:

https://blog.nirsoft.net/2010/07/27/how-to-configure-windows-to-create-minidump-files-on-bsod/

jaclaz

[whocares02]

No, no, both was enabled on my computer already. The computer reboots even before the BSOD finishes writing the screen and there is no minidump created. Therefore I assume Windows can't access the drive again, to write the dumpfile down.

For some reason, I have three driver versions for my Dell SAS 6/ir now. I tried all three of them:

Highest version was installed at first: 1.34.2.0 (dated Dec 12th, 2010), from LSI, not digitally signed. I then downgraded to 1.24.4.0 (dated Dec 2nd, 2007), from dell, digitally signed. Problem persist. I then downgraded to version 1.21.26.0 (August 25th, 2006) from LSI, not signed. The last and oldest driver did cause a BSOD 0x0000007B, directly after reboot, without a scheduled chkdsk. So this driver seems to be completely wrong.

For the other two: The scheduled chkdsk is always running fine. The crash always happens after finish of the last disk-check, when several partitions are marked for check. The computer reboots, and runs the scheduled disk-checks again, then crashing again, etc...

Running safe-mode afterwards, looks like this: Windows is loading several files in textmode, than black-screen with blinking cursor for a very long time. The HDD is very busy then. Then suddenly hard-reset of the system with a short beep from pc-speaker (yes, I still have one! :-) ).

Choosing "Last known good configuration" is always bringing me back to a working windows. Checkdisk is NOT scheduled anymore after this.

So the question is: What happens at the end of checkdisk that alters the configuration of windows and how to find out?

Maybe this is something to research after the holidays. Wish you a merry christmas....

 

 

 

 

 

Edited December 23, 2022 by whocares02

[RainyShadow]

9 hours ago, whocares02 said:

So the question is: What happens at the end of checkdisk that alters the configuration of windows and how to find out?

It tries to add an entry to the event log (check in event viewer > aplications, listed as winlogon) and/or create a log file in C:\System Volume Information\Chkdsk 

 

Then, if there were repairs made to the system drive, it tries to restart the PC and repeat the check. Otherwise it just continues loading Windows.