Jump to content

DavidEllis2

Member
  • Posts

    5
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

Everything posted by DavidEllis2

  1. This is two questions that I think may be related... Firstly, can someone explain the meaning of the numbers that follow entries under [sourceDisksFiles] and [sCSI.load] in TXTSETUP.OEM? For example, I have a working install of an si3112r that uses: [SourceDisksFiles] si3112r.sys = 1,,,,,,3_,4,1 [HardwareIdsDatabase] PCI\VEN_1095&DEV_3112&SUBSYS_61121095 = "Si3112r" [SCSI.load] si3112r = si3112r.sys,4 [SCSI] Si3112r = "Silicon Image SiI 3112 SATARaid Controller" I got to that point by literally copying the numbers "1,,,,,,3_,4,1" and ",4" from the guide but I would greatly prefer to know what they actually mean. Under what circumstances do they have different values? ------------------- Secondly, my reason for asking is that I am trying to add a second controller which has two "sys" files associated with it. My initial cut would be: [SourceDisksFiles] Si3124r5.sys = 1,,,,,,3_,4,1 SiWinAcc.sys = 1,,,,,,3_,4,1 [HardwareIdsDatabase] PCI\VEN_1095&DEV_3124&SUBSYS_71241095, "Si3124r5" PCI\VEN_1095&DEV_3124&SUBSYS_71248086, "Si3124r5" [SCSI.load] Si3124r5 = Si3124r5.sys,4 [SCSI] Si3124r5 = "Silicon Image SiI 3124 SoftRAID 5 Driver" Has anyone tried using the 3124 driver and could they confirm or deny that the above is correct? Do I need to include something under [sCSI.load] to pick up that second file? Does that seocnd file require its own identification under [sCSI]? Are the numbers correct? David E.
  2. This problem is fixed. As I only came across the solution fortuitously, I'm posting the answer here. The underlying symptom was that the MS Software Shadow Copy Provider service could not be started. After hours of comparing registry keys for SwPrv, VSS and RpcSs between the failing system and a very similar working system I could see no obviously significant reason. (The ProcessID in SwPrv was different by I exepcted that.) I had recently installed Firefox and when I ran it a little while ago I noticed that it reported that it had installed a Java update and .NET 1.1. I had previously ignored installing .NET 1.1 from Microsoft Update because I had got .NET 3.5 installed. Because of the Firefox report I decided to sidetrack get .NET 1.1 from Microsoft Update just in case Firefox had not got it all. Lo and behold, after installing .NET 1.1 from Microsoft Update and returning to my Backup problem, the MS Software Shadow Copy Provider service startup was fixed. .NET 1.1 is apparently required for the MS Software Shadow Copy Provider service. If someone thinks I've misinterpretted what went on here, please let me know. It seems to be a strange solution to the problem.
  3. I'm hoping someone can help me track down and fix a backup problem. This is a fresh Win XP Pro reinstall with the service pack 3 and all the latest patches. I put it in about a week ago and have since installed a number of third party apps. I just noticed in the Backup logs that for the last three days it has been failing to start the Volume Shadow Copy Service. I think, but cannot be certain, that it was working early on or I would have noticed the problem in my prior checks of the Event logs. (The error in the Backup log tends to blend in with other messages and does not stand out.) Unfortunately, I am unable to _prove_ it was working originally. (I have no proof because I use Backup frequently so my backup logs don't go back more than the last ten runs and because I - probably unwisely - purged the earlier event logs as they were clean.) Anyway the present problem is as follows: VSS gives an EventID 12292: Volume Shadow Copy Service error: Error creating the Shadow Copy Provider COM class with CLSID {65ee1dba-8ff4-4a58-ac1c-3470ee2f376a} [0x8007041d]. DCOM gives an EventID 10005: DCOM got error "The service did not respond to the start or control request in a timely fashion. " attempting to start the service SwPrv with arguments "" in order to run the server: {65EE1DBA-8FF4-4A58-AC1C-3470EE2F376A} I have confirmed that the file swprv.dll is present in system32 and has proper security ACLs. I have also verified that the Volume Shadow Copy service is present. It is set to manual startup; I can start it manually; and I have tried running Backup after having started it manually. This error still persists. I've looked at the CLSID in the registry and also the VSS key and can see nothing obviously strange but I am not enough of a registry expert to know precisely what to look for. I would greatly prefer to locate the damage and fix it rather than have to try and revert to a very much earlier backup. To go back as far as I would probably need to is likely to involve a full reinstall and yet another activation. (I'm probably right up close to my limit on activations and I'm not too keen on the prospect of spending another week sorting out third party apps!) Any ideas on how to solve this?
  4. I would add that the problem of retaining the activation doesn't seem to be limited to OEM systems. I have a homebuilt on an ASUS motherboard with a copy of Windows XP Pro from an Action Pack subscription. During a recent reinstall I had hoped to retain the activation by restoring wpa.dbl. It failed but I figured it may have been because I had made a lot of system changes over the years, including activating several MS-Office products. I activated my new reinstall with MS immediately after the install because MS prevents downloading hotfixes till after activation. Then I copied the fresh wpa files (dbl and bak) and put them into my unattended install master for future use and proceeded with the rest of the install. Unfortunately, an old rogue application that was early on in my install blew up the installation but I did not discover the problem till very much later. By that time trying to revert to one of the earlier backups just created a mess so I was forced to go back to a fresh reinstall. I formatted the disk as a quick way to clean it and reinstalled from the unattended install which now had a nice clean wpa.dbl. Upon restart I was told that immediate activation was required in order to login. (In fact a second attempt to login does work but activation is required within 30 days.) Just as annoying was that while backup could restore from any of the previous backups of the original install, it would not correct the activation issue so a further activation was required in order to continue. One thing I did notice was that the activation period (30 days following the base install) was shortened to 27 days immediately after reverting to the backup taken just after the previous re-install. This highlights that there is activation information/data being saved somewhere that even reinstalling System State cannot bypass. Clearly there is more to preserving the activation than just recovering the wpa files. While I understand MS's need to use activation, there should be some way to permit legitimate reinstallation in the same environment without reducing the count of the activations.
  5. I will say first that I came across this guide by accident and it is fantastic. Well written and well illustrated so that even someone not that experienced in Windows can follow it. One thing concerning the pdf version. There are some pages that seem to be out of sequence and need to be regenerated. Starting at document Page 42 which is the second page of "Drivers via CD": That 2nd page of "Drivers via CD" is followed by the 1st page of "SATA/RAID Drivers". That 1st page is then followed by the 3rd page of "Drivers via CD". That 3rd (and last) page of "Drivers via CD" is then followed by a page from "presetup.cmd" - I think its the 1st. That page is then followed by the 2nd (and last) page of "SATA/RAID Drivers". After that is another page from "presetup.cmd" - I think its the 2nd (and last).
×
×
  • Create New...