Jump to content

whocares02

Member
  • Posts

    91
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Germany

About whocares02

Profile Information

  • OS
    XP Home

Recent Profile Visitors

2,193 profile views

whocares02's Achievements

0

Reputation

  1. 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....
  2. 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
  3. I just realized, somebody might ask what "FU***** DRIVER" means. It means "fundamental driver" of course :-D ...
  4. 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.
  5. 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
  6. 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
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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".
×
×
  • Create New...