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....

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

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

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.

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: 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

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

yes, seems to me as well.

You just wrote: Now you tell me: It doesn't matter if booting BartPE makes sense or not. Problem is always the same: On a NAS, holding several Isos (e.g. WinXP, BartPE, PartedMagic, Ubuntu, Win7, Antivir-disk and whatever-else) none of them can be booted from a miniOS since they're all not be able to continue running from RAMDisk or holding the network-connection the miniOS created. As soon as a new OS-environment is loaded, all pre-configurations are forgotten. Exception is firadisk, though it's only for ramdisks. The "good practice" you describe is very slow and not usefull for DVD-Isos. Only new computers have 4GB RAM or more. Loading/transferring-time was unbearable with pre-loading such an iso.

How would you force such a background-OS not getting aborted as soon as some other environment gets chain-loaded? Let's say you boot-linux and call BartsPE, using grub. I suggest bartspe would just hard-reset linux as soon as it's graphical interfaces pops up. However you need to keep the network-connection in background, when bartspe-iso is streamed from a NAS.

No thank you. Seems what I was looking for doesn't exist. Seems I'm the only one missing a client-only based solution. Hoped for a discussion with other interested people. well, I can...because with wifi-hdds they are served "magically" through a network. It just seems there's just no (TSR-) loader being able installing from them. It's not your fault jaclaz. It just didn't get developed up to now. I of course also can't expect tools like grub4d0s or firadisk. Nevertheless they do exist, hence my question.

Using winner means creating a custom winner-disk. No no no, I'm too lazy for this. Correct me if I'm wrong but usually you can't, since many setups won't find the virtual-CD-source, especially when it's a network-share. Even when downloading an image to local disk before setup - let's say of linux - it should loose the grub-mount-point as soon as the kernel is loaded. Stick as an alternative is a possible way of course. Just wanted to know if there was a network-way, usable as easy as plugging a stick.

Ping looks interesting. Did I get it right that someone just needs to share an iso on network and ping finds it? Website doesn't provide too much informations. How is installation done? Does Ping copy the whole file first? I think what I was actually looking for was some tool like firadisk but for network-connections. Makes no sense to me buying a Wifi-HDD to boot up another computer in addition. Why the Wifi-HDD then? Hard disk storage can be provided by some server as well.

mmm...sounds not too bad actually. Ever tried it on an old machine? Best performance-test you can get. Edit: I don't like comodo-stuff as well. I somehow remember trouble when trying to uninstall it.

Comodoa also has a chrome-based browser just called dragon. Both are for secure surfing. Downside: nobody knows what features are actually integrated by comodo. Hands off stuff like this! I doubt it's faster anyway.

SORRY, didn't see your answer up to now! It's not true what you say! I tried your attempt. I modified my ims.inf exactly as described by you without success. Doing the same within the iso was not possible for me. You didn't tell me how to recompress ims.in_ with 7zip. I'm sure XP don't accept .7z-files - so some other option must be chosen. With just moving back the modified file into the archive, 7zip complained something alike "operation not possible".

What? I don't get anything. I'm talking about NAS: Network attached storage. I believe PXE-boot is technically interesting. However, when it's neccesary setting up another computer, working as server, the whole concept of NAS is lost. It's not a replacement for inserting a CD then.

More preferable was something like this: grub4dos-cd -> som mini-linux -> usual access to router-shares -> booting iso (residing on router) with grub4dos and firadisk -> installing windows. I know it's possible just using grub to boot something else direktly out of a running linux. Problem is: connection might get lost doing so. RAMDisk might be the only option (if possible). However, large ISOs (DVDs) would take a lot of time until transmitted and loaded.

Sorry, I don't get you.

Just found a few infos about PXE. It looks rather complicate. As far as I understood, someone needs to setup a Smb-Server, a special tftp-server, a special dhcp-server and provide a special folder-structure on smb-share with special file-modifications of setup-files. All this just to make possible a network-boot-disk might find the setup-files. ...doesn't sound straight-forward actually... It's easier just inserting a CD than booting-up another PC in network providing all neccesary servers.

It's just an idea....wouldn't it be nice if such an iso-mount was combined with netboot? Just typed in "netboot" in forum-search, resulting: Szenario could be: XP-ISO residing on a stick, plugged in a router of a home-network. Every computer in the house had access to the stick and could get a fresh (unttended) setup, streamed over internal network. Never done netboot before. Not sure how realistic this is.

I can recommend chrome as browser. On an old Pentium-3 With 800Mhz and 700MB memory, it really showed performance-differences: Even old opera (version 7) was slower than newest chrome! I used some portable-version to make sure it won't put weight on the system. I think it was called chromium.

I have no faith in all the webkit-spinoffs. Remember when firefox was new on the web? Until the 3.x-version there were dozens of mozilla-powered browsers. They popped up everywhere. Now, a few years later, there's almost nothing left. Most projects are discontinued. I miss konqueror with good ol' konqueror-engine. Opera getting chrome-code included is no surprise at all. They made a mistake 10 years ago already, when joining with google. It will destroy the project. In the end two google-browsers will be "too much for the users".

@mooms: It's not that easy: Nlite is always a bit capricious when integrating hotfixes and updates. E.g I found out it's a good idea cleaning the list and reimport all hotfixes to ensure nlite will integrate them, after loading the last session. Also some hotfixes need to be in special order. MSXML for instance needs to be at the end of the list, as well as IE7. Since Microsoft released a few hundred updates, I'm everytime glad when integration was successfull. I really don't wanna repeat that step if not neccesary. Well, yeah. Thank you! Edit: Allright, I did it - running nlite again. This time with SFC enabled and IE8 included. Seems even IE8 isn't rejected this time, though there are problems with some of its updates. I put them in RunOnceEc.cmd to install them silently after setup. Curious already if SFC will work after test-install is complete (still in progress right now.) Edit: Yap, it's working! Opening C:\Windows\System32\dllcachealready shows over 2000 files, directly after XP-installation. Removing a file from there and from windows-folder brings up CD-insert-request. nLite-disk gets accepted and files restored. I am using a modified ims.inf in addition. Hence I'm not sure if enabling SFC in nlite alon did the trick. My ims.inf reads all cd-tag-names in capitals (because files on cd are uppercase as well). cdtagfile = "\WIN51IP";{locked} cdtagfilei = "WIN51IP";{locked} cdtagfilem = "WIN51MP";{locked} spcdtagfilei = "WIN51IP.SP2";{locked} cd2tagfilei = "\WIN51IP2";{locked} In addittion, all strings reading "Professional" are replaced with "Home". Problem solved!

There are files missing on my nlite-disk. I really believe that. The folder \windows\system32\dllcache contains 76 files only, after a fresh installation. When running sfc /scannowand inserting the original cd, windows immediately fills that folder. Up to now it contains over 900 files already and SFC's progress-bar is only at 25% right now. I'm sure SFC will accept the nlite-cd afterwards. I guess it was just a bad idea switching off SFC in nlite. I'm trying submix' advice now, changing ims.in_ to recompile the iso for a next install. in addition to his renaming of cd-id-strings in the extracted ims.inf, I changed win51ip2 to win51ic2 as well, since this seems to be the string for a 2nd-SP2-CD. cd2name = "Windows XP Professional CD2"cd2tagfilei = "\win51ic2";{locked}My only question now is: How do I recompress with 7zip? Edit: Submix, I just tried renaming the cd-strings in an installed nlite-xp, in the way you described (just within \windows\inf\ims.inf). It's not working. SFC still complains, even after reboot. Are you sure it will work when editing ims.in_ in the iso? I (of course) did copy back all three files' original versions before modifying them in my running windows to ensure to make only described modifications.

Hey listen, I know it's easy just to move all problems to the source. But no matter how often it got recommended already, I don't start from scratch again, not after two weeks. All problems up to now were solvable and not related to my disk. I'll try submix' attempt now - and if I fail, I still got a full-unattended, working and pre-configured XP with a minor bug in SFC. I actually can live with it. Edit: Guess what: On the vbox-machine running my testinstall, SFC is working now, after I inserted the original CD. When I remove some helpfile from \windows\helpand \windows\system32\dllcachefor testing, SFC wants the CD. For some reason it accepts my nlite-disc now! I have NO IDEA how and why! Opening ims.inf shows all cdtag-filenames uppercase (not sure if I did that modification). All strings still just read "Windows XP Home" without the word "Edition". I'll copy the files now and try them on a fresh nlite-install. Will post here upon success.