Under some circumstances the presetup.cmd causes an error messagebox: Windows Kein Datenträger (Windows no disk), Exception Processing Message C0000013 ... Abrechen, Wiederholen, Weiter (Abort, Retry, Continue) when it is trying to find the CD/DVD drive.

The following code causes the problem if there are card readers present.

REM +==========================================================================+
REM |   Finding CD/DVD driveletter.                                            |
REM |--------------------------------------------------------------------------|
SET TAGFILE=\OEM
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST "%%i:%TAGFILE%" SET CDDRIVE=%%i:

The problem is that the for loop continues searching (trying to read the root directory) even if it has already found the CD/DVD drive.
So I would suggest to change this code to abort the search after the CD/DVD has been found, which can be done in this way:

REM +==========================================================================+
REM |   Finding CD/DVD driveletter.                                            |
REM |--------------------------------------------------------------------------|
SET TAGFILE=\OEM
FOR %%i IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST "%%i:%TAGFILE%" (
      SET CDDRIVE=%%i:
      GOTO CDFOUND
)
:CDFOUND

This helps at least if the drive letters of the card reader are behind the letter of the CD/DVD drive. Otherwise my solution does not work, but in this case also other problems exist.

Update title - jeff

Hm, I'm a little bit confused. How can the tape device be detected if the SCSI driver has not been loaded?

... it shows a "?" and when I check the driver info it is listed as no drivers loaded.

So I have to ask, where exactly is the question mark, at the tape device or at the SCSI controller?

Are you sure that SCSI hardware works correctly (termination, SCSI ID)? Are you sure that the SCSI cable used is a Ultra320 brand of SCSI cables (there are other brands whose connectors are "compatibel" but the cables are not)?

If you are sure all the SCSI things are correct, you can check it in the folowing way:
1. Restart your system, enter the LSI SCSI BIOS while in BIOS POST by pressing Ctrl-C.
2. Go to device list, check that the controller itself and the SDLT 600 are visible and that they are at 160MB/s or 320MB/s synchronous mode and 16 Bit. Refer to this document for more information.
3. If ther are any problems resolve them.

Now its time to clean up the driver installation:
1. Reboot your system to W2K and login as Administrator.
2. Go to device manger and remove both devices (tape drive and controller) by pressing the Del key.
3. Go C:\windows\system32\drivers directory and delete symmpi.sys if exists.
4. Go to C:\windows directory with explorer, right click the inf directory --> Search .. --> *.inf as filename and VEN_1000&DEV_0030 as word to be searched --> one or more files named oemXX.inf or symmpi.inf should be found, delete them if any.
5. Do the same again, search for *.inf with SCSI\BridgeLSI as word, delete this or these file(s) also if any.
6. Power down your system.
7. Disconnect the tape device but let the SCSI cabel and the terminator connected to the controller.
8. Power up your system, boot W2k.
9. The "New hardware found" wizzard should come up, let it search where you have the extracted files of the archive symmpi_SCSI_W2k_P12_12605.zip.
10. Reboot if requested.
11. Go to device manager, under SCSI devices the "LSI Adapter, Ultra320 SCSI 2000 series, w/1020/1030" should show up without "!" and "?" marks. If so, all is fine goto 12., if not my possibilities for remote help have ended here.
12. Powerd  down your system.
13. Reconnect the SDLT 600.
14. Reboot again, the SDLT 600 driver should install automatically or by wizzard.
15. Go to device manager to check that the SDLT 600 has no "!" and "?", you already know.
16. Insert one of the *.reg file to increase SCSI performance.

Good luck!

8.06C (06 June 2008)

It's one and a half month since my last post. In between I have testet 8.06C with my changes on WinXP and Win2003 with an Adaptec RAID 3405 and an ICP5165BR. It worked without any problems, so I will remove the "[Req]" from the title of this threat. Thanks again for integrating.

Nabeshin wrote:

I've done some reading and it seems that the LSI Logic 1020/1030 drivers were added at some point but in my device manager via UBCD4win, it shows a "?" and when I check the driver info it is listed as no drivers loaded.

HW ID:
LSI Logic 1020/1030
PCI\VEN_1000&DEV_0030&SUBSYS_10001000&REV_C15&11473D77&0&280010

Your are correct related to the type of controller, DriverPacks massstorage does support LSI Logic 1020/1030 based controllers (D\M\L4), but at this time it is only supported under WindowsXP. If you wish a quick solution of your problem, plaese look at this table and select Windows2000 to download the correct driver archiv (symmpi_SCSI_W2k_P12_12605.zip). After installing this driver via device manager your question mark should have disapeared.
Please read carefully the textfile symmpi2k.txt which is contained in the archiv, especially the part "Performance Tuning for Windows 2000", since a SDLT drive requires a good throughput of the SCSI subsystem.

A long term solution could be to integrate this driver into the DriverPacks massstorage package.

Jaak wrote:

I must have forgotten to hit the subscribe link because I see I was not subscribed to this topic..

I am sorry.

I was guilty on this too, I should have brought on top this thread much earlier.

Jaak wrote:

I wish all posters were as thorough as that.
Why are you not in one of the DriverPacks teams? I see the CSV file and other research you did on this, and I see you know more than most here..
Are you interested?

Your words make me feel honored, but I fear the time I would be able to spend with "DriverPacks.net" will not be enough to fullfill all work expected by a team member. Jaak, you can see what I mean if you compare your number of posts with my one.

I work as a system administrator in a small university. We have about 1000 PCs to be installed with Win2000 / WinXP / Win2003. Keeping the the inhouse driver collection working is only one of my daily working tasks. Until now we have our own driver collection. For about two years I use driverpacks to selectivly "steal" drivers to be used in our own collection. Beginning with XP SP3 I'm in transition to use Driverpack collection completely.

Of course I will try to give back as much as possible of the valuable work to the Driverpack team. So my posts will normally not be "driver xyz is not working for me, please help" but rather "driver xyz has the following problem, my solution is ...". And of course if there are any questions according to my posts I will answer them as deep as possible like you saw in 6th post of this thread.

So just now I'm not interested to become a team member, but thanks again. Maybe I will come back later to this invitation. 

Jaak wrote:

8.06C (06 June 2008)

Thanks, now I'm going to test.

Btw, the drivers of the IBM branding of these Adaptec controllers had been introduced by user zookeeper with this thread.   
@zookeeper, if you read this post and you have the opportunity to test the new version with an IBM controller, please do so. I can only test with Adapec / ICP brandings.

I have updated the first post in this thread. My wish to update the drivers in [ADB], to add the new [ADC] and to remove the obsolete [IB4] and [IB5] ist still pending.

In between (the first post is about 4 month old) I have updated my own [ADB] and [ADC] again from version 5.2.0.15317 to 5.2.0.15728. I also newly found out, that [AD2] is also superseded by [ADB] and [ADC]. The version 4.2.0.7320 of aac.sys in [AD2] is just an old version of aac.sys v. 5.2.0.15728 in (my new) [ADB]/[ADC]. I found this out by searching the original aac.inf file version 4.2.0.7320 which I found in DP_MassStorage_wnt5_x86-32_704.7z:

[ADPT]
%adptMustang.DeviceDesc% = aac_Inst, 		PCI\VEN_1011&DEV_0046&SUBSYS_03649005
%adpt.DeviceDesc% = aac_Inst, 			PCI\VEN_1011&DEV_0046&SUBSYS_03659005
%adpt.DeviceDesc% = aac_Inst, 			PCI\VEN_9005&DEV_0280&SUBSYS_02809005
%adpt.DeviceDesc% = aac_Inst, 			PCI\VEN_9005&DEV_0281&SUBSYS_02819005
%adpt.DeviceDesc% = aac_Inst, 			PCI\VEN_9005&DEV_0282&SUBSYS_02829005
%adpt.DeviceDesc% = aac_Inst, 			PCI\VEN_9005&DEV_0283&SUBSYS_02839005
%adpt.DeviceDesc% = aac_Inst, 			PCI\VEN_9005&DEV_0284&SUBSYS_02849005
%adpt.DeviceDesc% = aac_Inst, 			PCI\VEN_9006&DEV_2140&SUBSYS_21409006
%adptVulcan.DeviceDesc% = aac_Inst, 		PCI\VEN_9005&DEV_0285&SUBSYS_02859005
%adptVulcan.DeviceDesc% = aac_Inst, 		PCI\VEN_9005&DEV_0285&SUBSYS_02879005
%adptCrusader.DeviceDesc% = aac_Inst, 		PCI\VEN_9005&DEV_0285&SUBSYS_02869005
%adptSkyhawkscsi.DeviceDesc% = aac_Inst, 	PCI\VEN_9005&DEV_0285&SUBSYS_028A9005
%adptSkyhawksata.DeviceDesc% = aac_Inst, 	PCI\VEN_9005&DEV_0285&SUBSYS_028E9005
%adptTerminatorscsi.DeviceDesc% = aac_Inst, 	PCI\VEN_9005&DEV_0285&SUBSYS_028B9005
%adptTerminatorsata.DeviceDesc% = aac_Inst, 	PCI\VEN_9005&DEV_0285&SUBSYS_028F9005
%adptJaguar.DeviceDesc% = aac_Inst, 		PCI\VEN_9005&DEV_0285&SUBSYS_02909005
%adptCorsair8.DeviceDesc% = aac_Inst, 		PCI\VEN_9005&DEV_0285&SUBSYS_02929005
%adptCorsair16.DeviceDesc% = aac_Inst, 		PCI\VEN_9005&DEV_0285&SUBSYS_02939005
%adptLancer2ch.DeviceDesc% = aac_Inst,  	PCI\VEN_9005&DEV_0286&SUBSYS_028C9005
%adptLancer1ch.DeviceDesc% = aac_Inst,  	PCI\VEN_9005&DEV_0286&SUBSYS_028D9005
%adptBearcat.DeviceDesc% = aac_Inst,  		PCI\VEN_9005&DEV_0285&SUBSYS_3227103C

All devices with id DEV_0285 we can also find in aac.inf version 5.2.0.15728 in [ADB] (that's why they had been remooved from aacad2.inf to avoid duplicates) and all others that left in newer DriverPacks are IDs of devices that never had been sold publicly. I'm again quite sure on this because nothing is found if I google for "PCI\VEN_9005&DEV_0280" and the others and because their device descritions map to the generic string "Adaptec SCSI RAID Controller" or to "Adaptec SCSI RAID 5400S Controller" which is again a name of a device that does not exist on Adaptec's web site.

There is also another reason to remove [AD2]. I installed a PC with an Adaptec 3405 SAS Controller PCI\VEN_9005&DEV_0285&SUBSYS_02BB9005 with my updated [ADB] drivers. The presence of aacad2.sys (what is the old aac.sys) cased a BSOD 0x0000007B after! textmode setup. I found in the new registry "aacad2" had been installed instaed of "aacsas". The reason for this is that the old aacad2.sys had been loaded before the aacsas.sys in textmode and "told" the system to support  the generic "PCI\VEN_9005&DEV_0285" (without subvendor id). So I first moved the line "AACAD2=AACAD2.sys,4" to the end of the section [SCSI.Load] in txtmode.sif what resolved the BSOD problem. Then I did some more research on [AD2] and found out that it is obsolete and should be removed completely.

Slipstream drivers to the \I386 directory of all supported OSs by DriverPacks always works in "competition" to previous changes done by driverpacks and changes done by other slipstreamers (Nlite, RyanVM, Sereby, ...) So I think the only clean solution to this problem will be an undo file or directory within the destination dirctory. This file must contain all changes done by DP's Base. Each run with slipstreaming "ON" then must do the following steps:
- Search for old DriverPacks changes without this undo information and warn the user if something is found *1)
- Search for the undo file or directory
- If it exists undo all changes *2)
- Delete the undo information
- Do the new slipstream and create the new undo information

*1) changes like that that the current version of Base does.
*2) but only, if no other program has replaced a file that had been updated by DriverPacks. That means we must keep the old and the new version of files replaced by DriverPacks Base and store them in the undo information. If Base detects a change to a file from an external source it should not begin it's undo process and stop with an error message.

So each slipstreaming of DP's Base will internally begin with a clean copy in relation to previous changes from DP's Base. The cache must not contain any information related to the destination OS / directory. It only may contain information from DP's source files that do not depend on the destination of the integration, so the cache only needs to be changed, if there are any changes in source file(s).

@Jaak,

Are you really sure you can delete IB4?

Yes, I'm quite sure. To see why I'm that sure, please store the following code box as a *.csv file and import it into your preferred spreadsheet program.

Archive Name,icp_windows-x86_xp_2000_b15317_cert.exe,ibm_dd_aacraid_5.2.0.12913_windows_32-64.exe,ibm_dd_aacraid_5.2.0.11829_windows_32-64.exe
Name of *.inf file,aacsas.inf,2000\aacsas.inf,2000-XP\aacsas.inf
Driverpack Version / Directory,8.01 / [ADB],Not yet included,8.01 / [IB4] (only some Ids)
,,,
"IBM ServeRAID 8i Controller",PCI\VEN_9005&DEV_0285&SUBSYS_02f21014,PCI\VEN_9005&DEV_0285&SUBSYS_02f21014,PCI\VEN_9005&DEV_0285&SUBSYS_02f21014
"IBM ServeRAID 8k/8k-l Controller",PCI\VEN_9005&DEV_0286&SUBSYS_95801014,PCI\VEN_9005&DEV_0286&SUBSYS_95801014,PCI\VEN_9005&DEV_0286&SUBSYS_95801014
"Adaptec SATA RAID AAR-2420SA Controller",PCI\VEN_9005&DEV_0286&SUBSYS_029D9005,PCI\VEN_9005&DEV_0286&SUBSYS_029D9005,PCI\VEN_9005&DEV_0286&SUBSYS_029D9005
"Adaptec SATA RAID AAR-2620SA Controller",PCI\VEN_9005&DEV_0286&SUBSYS_029C9005,PCI\VEN_9005&DEV_0286&SUBSYS_029C9005,PCI\VEN_9005&DEV_0286&SUBSYS_029C9005
"Adaptec SATA RAID AAR-2820SA Controller",PCI\VEN_9005&DEV_0286&SUBSYS_029B9005,PCI\VEN_9005&DEV_0286&SUBSYS_029B9005,PCI\VEN_9005&DEV_0286&SUBSYS_029B9005
"ICP SATA RAID ICP9047MA Controller",PCI\VEN_9005&DEV_0286&SUBSYS_02A09005,PCI\VEN_9005&DEV_0286&SUBSYS_02A09005,PCI\VEN_9005&DEV_0286&SUBSYS_02A09005
"ICP SATA RAID ICP9067MA Controller",PCI\VEN_9005&DEV_0286&SUBSYS_02A69005,PCI\VEN_9005&DEV_0286&SUBSYS_02A69005,PCI\VEN_9005&DEV_0286&SUBSYS_02A69005
"ICP SATA RAID ICP9087MA Controller",PCI\VEN_9005&DEV_0286&SUBSYS_02A19005,PCI\VEN_9005&DEV_0286&SUBSYS_02A19005,PCI\VEN_9005&DEV_0286&SUBSYS_02A19005
"Adaptec RAID 4000",PCI\VEN_9005&DEV_0285&SUBSYS_02989005,PCI\VEN_9005&DEV_0285&SUBSYS_02989005,PCI\VEN_9005&DEV_0285&SUBSYS_02989005
"Adaptec SAS RAID 4800SAS Controller",PCI\VEN_9005&DEV_0285&SUBSYS_02999005,PCI\VEN_9005&DEV_0285&SUBSYS_02999005,PCI\VEN_9005&DEV_0285&SUBSYS_02999005
"Adaptec SAS RAID 4805SAS Controller",PCI\VEN_9005&DEV_0285&SUBSYS_029A9005,PCI\VEN_9005&DEV_0285&SUBSYS_029A9005,PCI\VEN_9005&DEV_0285&SUBSYS_029A9005
"ICP SAS RAID ICP9085LI Controller",PCI\VEN_9005&DEV_0285&SUBSYS_02A49005,PCI\VEN_9005&DEV_0285&SUBSYS_02A49005,PCI\VEN_9005&DEV_0285&SUBSYS_02A49005
"ICP SAS RAID ICP5085BR Controller",PCI\VEN_9005&DEV_0285&SUBSYS_02A59005,PCI\VEN_9005&DEV_0285&SUBSYS_02A59005,PCI\VEN_9005&DEV_0285&SUBSYS_02A59005
"IBM ServeRAID 8s Controller",PCI\VEN_9005&DEV_0285&SUBSYS_034D1014,PCI\VEN_9005&DEV_0285&SUBSYS_034D1014,PCI\VEN_9005&DEV_0285&SUBSYS_034D1014
"Adaptec RAID 5445",PCI\VEN_9005&DEV_0285&SUBSYS_02B59005,PCI\VEN_9005&DEV_0285&SUBSYS_02B59005,PCI\VEN_9005&DEV_0285&SUBSYS_02B59005
"Adaptec RAID 5805",PCI\VEN_9005&DEV_0285&SUBSYS_02B69005,PCI\VEN_9005&DEV_0285&SUBSYS_02B69005,PCI\VEN_9005&DEV_0285&SUBSYS_02B69005
"Adaptec RAID 5085",PCI\VEN_9005&DEV_0285&SUBSYS_02B79005,PCI\VEN_9005&DEV_0285&SUBSYS_02B79005,PCI\VEN_9005&DEV_0285&SUBSYS_02B79005
"ICP5445SL",PCI\VEN_9005&DEV_0285&SUBSYS_02B89005,PCI\VEN_9005&DEV_0285&SUBSYS_02B89005,
"ICP5085SL",PCI\VEN_9005&DEV_0285&SUBSYS_02B99005,PCI\VEN_9005&DEV_0285&SUBSYS_02B99005,
"ICP5805SL",PCI\VEN_9005&DEV_0285&SUBSYS_02BA9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BA9005,
"Adaptec RAID 3405",PCI\VEN_9005&DEV_0285&SUBSYS_02BB9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BB9005,
"Adaptec RAID 3805",PCI\VEN_9005&DEV_0285&SUBSYS_02BC9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BC9005,
"Adaptec RAID 31205",PCI\VEN_9005&DEV_0285&SUBSYS_02BD9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BD9005,
"Adaptec RAID 31605",PCI\VEN_9005&DEV_0285&SUBSYS_02BE9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BE9005,
"ICP5045BL",PCI\VEN_9005&DEV_0285&SUBSYS_02BF9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BF9005,
"ICP5085BL",PCI\VEN_9005&DEV_0285&SUBSYS_02C09005,PCI\VEN_9005&DEV_0285&SUBSYS_02C09005,
"ICP5125BR",PCI\VEN_9005&DEV_0285&SUBSYS_02C19005,PCI\VEN_9005&DEV_0285&SUBSYS_02C19005,
"ICP5165BR",PCI\VEN_9005&DEV_0285&SUBSYS_02C29005,PCI\VEN_9005&DEV_0285&SUBSYS_02C29005,
"Adaptec RAID 51205",PCI\VEN_9005&DEV_0285&SUBSYS_02C39005,PCI\VEN_9005&DEV_0285&SUBSYS_02C39005,
"Adaptec RAID 51605",PCI\VEN_9005&DEV_0285&SUBSYS_02C49005,PCI\VEN_9005&DEV_0285&SUBSYS_02C49005,
"ICP5125SL",PCI\VEN_9005&DEV_0285&SUBSYS_02C59005,PCI\VEN_9005&DEV_0285&SUBSYS_02C59005,
"ICP5165SL",PCI\VEN_9005&DEV_0285&SUBSYS_02C69005,PCI\VEN_9005&DEV_0285&SUBSYS_02C69005,
"Adaptec RAID 3085",PCI\VEN_9005&DEV_0285&SUBSYS_02C79005,PCI\VEN_9005&DEV_0285&SUBSYS_02C79005,
"ICP5805BL",PCI\VEN_9005&DEV_0285&SUBSYS_02C89005,PCI\VEN_9005&DEV_0285&SUBSYS_02C89005,
"AOC-USAS-S4i RAID Controller",PCI\VEN_9005&DEV_0285&SUBSYS_02B515D9,PCI\VEN_9005&DEV_0285&SUBSYS_02B515D9,PCI\VEN_9005&DEV_0285&SUBSYS_02B515D9
"AOC-USAS-S8i RAID Controller",PCI\VEN_9005&DEV_0285&SUBSYS_02B615D9,PCI\VEN_9005&DEV_0285&SUBSYS_02B615D9,PCI\VEN_9005&DEV_0285&SUBSYS_02B615D9
"AOC-USAS-S4iR RAID Controller",PCI\VEN_9005&DEV_0285&SUBSYS_02C915D9,PCI\VEN_9005&DEV_0285&SUBSYS_02C915D9,
"AOC-USAS-S8iR RAID Controller",PCI\VEN_9005&DEV_0285&SUBSYS_02CA15D9,PCI\VEN_9005&DEV_0285&SUBSYS_02CA15D9,
"Sun STK RAID REM",PCI\VEN_9005&DEV_0285&SUBSYS_7AAC108E,PCI\VEN_9005&DEV_0285&SUBSYS_7AAC108E,
"Sun STK RAID EM",PCI\VEN_9005&DEV_0285&SUBSYS_7AAE108E,,
"Sun STK RAID INT",PCI\VEN_9005&DEV_0285&SUBSYS_0286108E,PCI\VEN_9005&DEV_0285&SUBSYS_0286108E,
"Sun STK RAID EXT",PCI\VEN_9005&DEV_0285&SUBSYS_0287108E,PCI\VEN_9005&DEV_0285&SUBSYS_0287108E,
"Adaptec RAID 51245",PCI\VEN_9005&DEV_0285&SUBSYS_02CE9005,,
"Adaptec RAID 51645",PCI\VEN_9005&DEV_0285&SUBSYS_02CF9005,,
"Adaptec RAID 52445",PCI\VEN_9005&DEV_0285&SUBSYS_02D09005,,
"Adaptec RAID 5405",PCI\VEN_9005&DEV_0285&SUBSYS_02D19005,,
"AOC-USAS-S8i-LP RAID Controller",PCI\VEN_9005&DEV_0285&SUBSYS_02D215D9,,
"AOC-USAS-S8iR-LP RAID Controller",PCI\VEN_9005&DEV_0285&SUBSYS_02D315D9,,
"Adaptec RAID 3800",,,PCI\VEN_9005&DEV_0286&SUBSYS_02A29005
"ICP SAS RAID ICP5445AU Controller",,,PCI\VEN_9005&DEV_0286&SUBSYS_02A39005
"Adaptec RAID 1800",,,PCI\VEN_9005&DEV_0286&SUBSYS_02AC9005
"Adaptec RAID 3805",,,PCI\VEN_9005&DEV_0286&SUBSYS_02A79005
"ICP SAS RAID ICP5085AU Controller",,,PCI\VEN_9005&DEV_0286&SUBSYS_02A99005
"Adaptec RAID 2400",,,PCI\VEN_9005&DEV_0286&SUBSYS_02B39005
"ICP SAS RAID ICP5045AL Controller",,,PCI\VEN_9005&DEV_0286&SUBSYS_02B49005
"Adaptec RAID 3400",,,PCI\VEN_9005&DEV_0286&SUBSYS_02A89005
"ICP SAS RAID ICP5045AU Controller",,,PCI\VEN_9005&DEV_0286&SUBSYS_02AA9005
"Adaptec RAID ARK-1000/8 Controller",,,PCI\VEN_9005&DEV_0285&SUBSYS_02B09005

Yesterday I looked at the HWIDs of IB4 and ADB because you claim IB4 can be left out.
ADB is newer and has newer systemfile versions, but it does NOT list the HWIDs I find in IB4.

This was also my first thought, when I had an look at the IDs under [IB4]. But the spreadsheet shows that these ten IDs are already reduced by the duplicates coming from[ADB]. Futhermore it shows in the first column which contains the clear names of the controllers taken from *.inf files that only three IDs are really IBM devices and all three have been removed as duplicates.
If we have a closer look at these ten IDs then we see that they only exist in IBM's version 5.2.11829 of the aacsas.inf, even IBM has dropped these IDs in its updated version 5.2.12913. There are some reasons that make me sure that devices with names of these ten IDs have never been sold (they are development IDs I think). The only exception is "Adaptec RAID 3805" what is a duplicate name. But also in this case I'm sure that the other entry with ID PCI\VEN_9005&DEV_0285&SUBSYS_02BC9005 is the correct one. The reasons are that none of the nine device names is listed on one of the following pages:

- http://www.adaptec.com/en-US/support/alpha (Alphabetical list of all supported Adaptec devices)
- http://www.adaptec.com/en-US/support/_eol (All Adaptec end of life products)
- http://www.icp-vortex.com/en/product_key_en.html (Descrition of the ICP product keys, pleas note "AL" and "AU" do not exist as series names)
- http://www.icp-vortex.com/english/download/tools_e.htm (All ICP download links)

These ten IDs are also missing in aacraid.ddi, the (ddi=device driver information, the *.inf-files of Novell Netware) 

Jaak, so I hope that you will believe me now, that [IB4] is superseded by [ADB] and of course [IB5] by [ADC] and that my upload http://rapidshare.com/files/89565309/DP … 1b.7z.html from third post in this thread is correct in sections ADB, ADC, IB4 and IB5 and that you will do the changes like I did them.

Thanks in advance,
JSe.

@Jaak,

This driver has references to non-existing files? ( to wit, naacsas.sys, and naacsas.dll )

No it has not! This is a copyfiles directive of a device driver inf file acording to this syntax:

[file-list-section]
destination-file-name[,source-file-name][,temporary-file-name][,flag]

If you wish you can get more information here: http://msdn2.microsoft.com/en-us/library/ms794560.aspx. So these file names beginning with "n" are temporary names. As the  document says, this is only neccesary for Win9x/ME, but it seems that it won't annoy if it is still present in WinNt and its successors.

Some reasons, why it won't annoy:
- the driver works a least with WinXPSP2 and Win2003ServerSP1 ;-)
- its has a microsoft certificate
- the driver versions in C\M\ADB of DP_MassStorage_wnt5_x86-32_801.7z  is the same that I use, so if there would be a problem, it must have been shown in older releases of the DriverPack MassStorage.

I have only shown, that the drivers in C\M\ADB are only intended for Win2000 and WinXP and have added the right versions for Win2003 under C\M\ADC. And I have removed the C\M\IB4 and C\M\IB5 since they are superseded by C\M\ADB and C\M\ADC, even if I would update the IBM-Versions of them, since the IBM- AOC- and SUN-version of these controllers are only brandings of the Adaptec/ICP original and the PCI IDs of the brandings are completly contained in Adaptec's *.inf-files.

I think the developers responsible for this can be found at ICP vortex Computersysteme GmbH a subsidiary of Adaptec http://www.icp-vortex.com/en/index_en.html. Some time ago I had an email contact with one of them. If this contact still exists, I will tell them, that it would be better to change lines like

[DeviceDriverFiles]
aacsas.sys, aacsas.sys, naacsas.sys, 0x00000000

to

[DeviceDriverFiles]
aacsas.sys,,,0

or simply to

[DeviceDriverFiles]
aacsas.sys

@Overflow,

disable if w2k is also not specified

It is specified in [ADB], but it is not in [ADC] because there is ms_1_exc_skipIfOS="wxp,w2k" and my thought was, if this section is completely skipped in Win2000 the option ms_1_exc_disableIfOS="w2k" will not be needed. If I am wrong with this assumption, please add ms_1_exc_disableIfOS="w2k" and ms_2_exc_disableIfOS="w2k" to [ADC].
I will test my changes in MassStorage with Win2000 this weekend.

I did some more testing an changed some entries in DriverPack_MassStorage_wnt5_x86-32.ini, also corrected in my first post.
The changes are:
- used better device names
- corrected error in [ADC] "arc" and "arcsas" instead of "aac" and "aacsas"
- added ms_2_exc_replaceIfOS="w2k3" to [ADC]
- added comments where have [IB4] and [IB5] gone

Jaak, you can download a complete package based on DP_MassStorage_wnt5_x86-32_801.7z from here:
http://rapidshare.com/files/89565309/DP … 1b.7z.html

Thanks for including, it works fine. (Sorry for the late anwer, I was "offline" for a long time.)

JSe

Driverpack Masstorage already contains the Adaptec/ICP RAID Controller family driver for W2K and WXP in directory \D\M\ADB coming from archive "icp_windows-x86_xp_2000_b15317_cert.exe" (edit: the new version is in "icp_windows-x86_xp_2000_b15728_cert.exe") which can be reached via http://www.adaptec.com/en-US/support/ra … /ICP5165BR following the "Microsoft Windows XP" link. This driver is not intended to be used on W2003 Servers. So the ms_1_exc_skipIfOS="w2k3" and ms_2_exc_skipIfOS="w2k3" should be added to DriverPack_MassStorage_wnt5_x86-32.ini under [ADB].

To complete the collection for Win2003 Server there is the archive "icp_xp_x64_ws08-ws03-Vista_x64_ x86_b15728_cert.exe" available following the link "Microsoft Windows Server 2003" on the same URL. I have added this one as \D\M\ADC and the relating section [ADC].

From IBM http://www-304.ibm.com/jct01004c/system … nd=5000008 there is also an update available, named "ibm_dd_aacraid_5.2.0.12913_windows_32-64.exe". This is Version 5.2.12913 which is newer by date but older by version number compared to the Adaptec drivers. But all PCI-IDs of the IBM *.inf files are also available by Adaptec's *.inf files. This means that we can completely remove \D\M\IB4 and \D\M\IB5 and their relating sections in DriverPack_MassStorage_wnt5_x86-32.ini.

By removing these IBM directories we also can avoid the rename of the Adaptec files in [ADB], so I've given back them their original names.

These controllers seem also to be sold under other names like "SUN" and "AOC"

We've already testet this new structure with an ICP 9024RO under Win2003 successfully. I'm going to test this also with WinXP.

I would ask the driver pack experts to verify my changes and to include them into the next update if they are correct.

Thanks in advance.

; [AD2] removed because it is superseded by [ADB] XP/2K and [ADC] W2K3

....

[ADB]
ms_count=2
ms_1_deviceName="ADAPTEC/ICP/IBM/SUN/AOC SATA/SAS RAID Controller (W2K/XP)"
ms_1_tag="aacsas"
ms_1_sysFile="aacsas.sys"
ms_1_hwids="PCI\VEN_9005&DEV_0285&SUBSYS_02f21014,PCI\VEN_9005&DEV_0286&SUBSYS_95801014,PCI\VEN_9005&DEV_0286&SUBSYS_029D9005,PCI\VEN_9005&DEV_0286&SUBSYS_029C9005,PCI\VEN_9005&DEV_0286&SUBSYS_029B9005,PCI\VEN_9005&DEV_0286&SUBSYS_02A09005,PCI\VEN_9005&DEV_0286&SUBSYS_02A69005,PCI\VEN_9005&DEV_0286&SUBSYS_02A19005,PCI\VEN_9005&DEV_0285&SUBSYS_02989005,PCI\VEN_9005&DEV_0285&SUBSYS_02999005,PCI\VEN_9005&DEV_0285&SUBSYS_029A9005,PCI\VEN_9005&DEV_0285&SUBSYS_02A49005,PCI\VEN_9005&DEV_0285&SUBSYS_02A59005,PCI\VEN_9005&DEV_0285&SUBSYS_034D1014,PCI\VEN_9005&DEV_0285&SUBSYS_02B59005,PCI\VEN_9005&DEV_0285&SUBSYS_02B69005,PCI\VEN_9005&DEV_0285&SUBSYS_02B79005,PCI\VEN_9005&DEV_0285&SUBSYS_02B89005,PCI\VEN_9005&DEV_0285&SUBSYS_02B99005,PCI\VEN_9005&DEV_0285&SUBSYS_02BA9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BB9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BC9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BD9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BE9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BF9005,PCI\VEN_9005&DEV_0285&SUBSYS_02C09005,PCI\VEN_9005&DEV_0285&SUBSYS_02C19005,PCI\VEN_9005&DEV_0285&SUBSYS_02C29005,PCI\VEN_9005&DEV_0285&SUBSYS_02C39005,PCI\VEN_9005&DEV_0285&SUBSYS_02C49005,PCI\VEN_9005&DEV_0285&SUBSYS_02C59005,PCI\VEN_9005&DEV_0285&SUBSYS_02C69005,PCI\VEN_9005&DEV_0285&SUBSYS_02C79005,PCI\VEN_9005&DEV_0285&SUBSYS_02C89005,PCI\VEN_9005&DEV_0285&SUBSYS_02B515D9,PCI\VEN_9005&DEV_0285&SUBSYS_02B615D9,PCI\VEN_9005&DEV_0285&SUBSYS_02C915D9,PCI\VEN_9005&DEV_0285&SUBSYS_02CA15D9,PCI\VEN_9005&DEV_0285&SUBSYS_7AAC108E,PCI\VEN_9005&DEV_0285&SUBSYS_7AAE108E,PCI\VEN_9005&DEV_0285&SUBSYS_0286108E,PCI\VEN_9005&DEV_0285&SUBSYS_0287108E,PCI\VEN_9005&DEV_0288&SUBSYS_02CB9005,PCI\VEN_9005&DEV_0288&SUBSYS_02CC9005,PCI\VEN_9005&DEV_0288&SUBSYS_02CD9005,PCI\VEN_9005&DEV_0285&SUBSYS_02CE9005,PCI\VEN_9005&DEV_0285&SUBSYS_02CF9005,PCI\VEN_9005&DEV_0285&SUBSYS_02D09005,PCI\VEN_9005&DEV_0285&SUBSYS_02D19005,PCI\VEN_9005&DEV_0285&SUBSYS_02D215D9,PCI\VEN_9005&DEV_0285&SUBSYS_02D315D9"
ms_1_isBusExtender=false
ms_1_exc_disableIfOS="w2k"
ms_1_exc_skipIfOS="w2k3"
ms_2_deviceName="ADAPTEC/ICP SCSI/SATA RAID Controller (W2K/XP)"
ms_2_tag="aac"
ms_2_sysFile="aac.sys"
ms_2_hwids="PCI\VEN_9005&DEV_0285&SUBSYS_02859005,PCI\VEN_9005&DEV_0285&SUBSYS_02879005,PCI\VEN_9005&DEV_0285&SUBSYS_02869005,PCI\VEN_9005&DEV_0285&SUBSYS_028A9005,PCI\VEN_9005&DEV_0285&SUBSYS_028E9005,PCI\VEN_9005&DEV_0285&SUBSYS_028B9005,PCI\VEN_9005&DEV_0285&SUBSYS_028F9005,PCI\VEN_9005&DEV_0285&SUBSYS_02909005,PCI\VEN_9005&DEV_0285&SUBSYS_02929005,PCI\VEN_9005&DEV_0285&SUBSYS_02939005,PCI\VEN_9005&DEV_0285&SUBSYS_3227103C,PCI\VEN_9005&DEV_0286&SUBSYS_028C9005,PCI\VEN_9005&DEV_0286&SUBSYS_028D9005,PCI\VEN_9005&DEV_0286&SUBSYS_029E9005,PCI\VEN_9005&DEV_0286&SUBSYS_029F9005"
ms_2_isBusExtender=false
ms_2_exc_disableIfOS="w2k"
ms_2_exc_skipIfOS="w2k3"

[ADC]
ms_count=2
ms_1_deviceName="ADAPTEC/ICP/IBM/SUN/AOC SATA/SAS RAID Controller (Win2003)"
ms_1_tag="arcsas"
ms_1_sysFile="arcsas.sys"
ms_1_hwids="PCI\VEN_9005&DEV_0285&SUBSYS_02f21014,PCI\VEN_9005&DEV_0286&SUBSYS_95801014,PCI\VEN_9005&DEV_0286&SUBSYS_029D9005,PCI\VEN_9005&DEV_0286&SUBSYS_029C9005,PCI\VEN_9005&DEV_0286&SUBSYS_029B9005,PCI\VEN_9005&DEV_0286&SUBSYS_02A09005,PCI\VEN_9005&DEV_0286&SUBSYS_02A69005,PCI\VEN_9005&DEV_0286&SUBSYS_02A19005,PCI\VEN_9005&DEV_0285&SUBSYS_02989005,PCI\VEN_9005&DEV_0285&SUBSYS_02999005,PCI\VEN_9005&DEV_0285&SUBSYS_029A9005,PCI\VEN_9005&DEV_0285&SUBSYS_02A49005,PCI\VEN_9005&DEV_0285&SUBSYS_02A59005,PCI\VEN_9005&DEV_0285&SUBSYS_034D1014,PCI\VEN_9005&DEV_0285&SUBSYS_02B59005,PCI\VEN_9005&DEV_0285&SUBSYS_02B69005,PCI\VEN_9005&DEV_0285&SUBSYS_02B79005,PCI\VEN_9005&DEV_0285&SUBSYS_02B89005,PCI\VEN_9005&DEV_0285&SUBSYS_02B99005,PCI\VEN_9005&DEV_0285&SUBSYS_02BA9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BB9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BC9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BD9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BE9005,PCI\VEN_9005&DEV_0285&SUBSYS_02BF9005,PCI\VEN_9005&DEV_0285&SUBSYS_02C09005,PCI\VEN_9005&DEV_0285&SUBSYS_02C19005,PCI\VEN_9005&DEV_0285&SUBSYS_02C29005,PCI\VEN_9005&DEV_0285&SUBSYS_02C39005,PCI\VEN_9005&DEV_0285&SUBSYS_02C49005,PCI\VEN_9005&DEV_0285&SUBSYS_02C59005,PCI\VEN_9005&DEV_0285&SUBSYS_02C69005,PCI\VEN_9005&DEV_0285&SUBSYS_02C79005,PCI\VEN_9005&DEV_0285&SUBSYS_02C89005,PCI\VEN_9005&DEV_0285&SUBSYS_02B515D9,PCI\VEN_9005&DEV_0285&SUBSYS_02B615D9,PCI\VEN_9005&DEV_0285&SUBSYS_02C915D9,PCI\VEN_9005&DEV_0285&SUBSYS_02CA15D9,PCI\VEN_9005&DEV_0285&SUBSYS_7AAC108E,PCI\VEN_9005&DEV_0285&SUBSYS_7AAE108E,PCI\VEN_9005&DEV_0285&SUBSYS_0286108E,PCI\VEN_9005&DEV_0285&SUBSYS_0287108E,PCI\VEN_9005&DEV_0288&SUBSYS_02CB9005,PCI\VEN_9005&DEV_0288&SUBSYS_02CC9005,PCI\VEN_9005&DEV_0288&SUBSYS_02CD9005,PCI\VEN_9005&DEV_0285&SUBSYS_02CE9005,PCI\VEN_9005&DEV_0285&SUBSYS_02CF9005,PCI\VEN_9005&DEV_0285&SUBSYS_02D09005,PCI\VEN_9005&DEV_0285&SUBSYS_02D19005,PCI\VEN_9005&DEV_0285&SUBSYS_02D215D9,PCI\VEN_9005&DEV_0285&SUBSYS_02D315D9"
ms_1_isBusExtender=false
ms_1_exc_disableIfOS="w2k"
ms_1_exc_skipIfOS="wxp,w2k"
ms_2_deviceName="ADAPTEC/ICP SCSI/SATA RAID Controller (Win2003)"
ms_2_tag="arc"
ms_2_sysFile="arc.sys"
ms_2_hwids="PCI\VEN_9005&DEV_0285&SUBSYS_02859005,PCI\VEN_9005&DEV_0285&SUBSYS_02879005,PCI\VEN_9005&DEV_0285&SUBSYS_02869005,PCI\VEN_9005&DEV_0285&SUBSYS_028A9005,PCI\VEN_9005&DEV_0285&SUBSYS_028E9005,PCI\VEN_9005&DEV_0285&SUBSYS_028B9005,PCI\VEN_9005&DEV_0285&SUBSYS_028F9005,PCI\VEN_9005&DEV_0285&SUBSYS_02909005,PCI\VEN_9005&DEV_0285&SUBSYS_02929005,PCI\VEN_9005&DEV_0285&SUBSYS_02939005,PCI\VEN_9005&DEV_0285&SUBSYS_3227103C,PCI\VEN_9005&DEV_0286&SUBSYS_028C9005,PCI\VEN_9005&DEV_0286&SUBSYS_028D9005,PCI\VEN_9005&DEV_0286&SUBSYS_029E9005,PCI\VEN_9005&DEV_0286&SUBSYS_029F9005"
ms_2_isBusExtender=false
ms_2_exc_disableIfOS="w2k"
ms_2_exc_skipIfOS="wxp,w2k"
ms_2_exc_replaceIfOS="w2k3"

; ....

;[IB4] IBM Serverraid drivers (W2K/XP) now are superseded by [ADB]
;[IB5] IBM Serverraid drivers (Win2003) now are superseded by [ADC]

Last edited 2008/06/06:
- links and thread title updated from Version 5.2.0.15317 to 5.2.0.15728
- removed AD2 from DriverPack_MassStorage_wnt5_x86-32.ini see post 11
- added three more device ids from Version 5.2.0.15728 (PCI\VEN_9005&DEV_0288&SUBSYS_02CB9005,PCI\VEN_9005&DEV_0288&SUBSYS_02CC9005,PCI\VEN_9005&DEV_0288&SUBSYS_02CD9005)
- added ms_1_exc_disableIfOS="w2k" and ms_2_exc_disableIfOS="w2k" on advice of "Overflow" in post 10

I wish somebody from Intel responsible for this chaos would see your list. I think if they want they could conclude all drivers with version number 6.14.10.xxxx to one archive. They have demonstrated for example with their chipset collection that they can if they want.

I addition to my dream there is a suggestion we can really do. I saw the HDMI subdirectory under I\1 and I\3 containing the same HWIDs but two diffrent version and an extra copy of their files in the named parent directories. 
We should reduce this to one directory. I would even suggest to move this to one of the sound packages since this is more an audio then a graphics driver. It has only the connector common with graphic hardware.

39

(27 replies, posted in DriverPack Mass Storage)

Jaak wrote:

I liked your suggestion about making an edited  "copy" for that single compaq HWID.
(the other HWIDs this old driver had are still covered by the newest adaptec.)

The idea has been stolen from G\N\1 (nv4_disp.inf and nv4_go.inf) so at the end it is a driverpacks.net idea and not my one.

40

(27 replies, posted in DriverPack Mass Storage)

ad\6 updated to 01/22/2007,7.00.00.06

That's fine, I believed my post http://forum.driverpacks.net/viewtopic.php?id=1944 already forgotten by the experts;-)

ad\6\c deleted (HWID edited into ad\6)

I'm not sure if this is the best solution since it invalidates the driver's signature. I would  write a second *.inf-file (which is copy of the existing one except the HWIDs and strings) so that only the signature of the Compaq brand of this controller is invalid what happens anyway since the *.sys  is newer then the Compaq *.cat.

And as a last point I would ask to cleanup ad\6 a little bit:
- txtsetup.oem not needed in driverpacks (it's function is ported to DriverPack_MassStorage_wnt5_x86-32.ini)
- the disklabel U320DSK1 is not needed
- MAXIO64K is not referenced in *.inf nor txtsetup.oem so its also not needed (for any unattended setup)

Thanks

Jaak wrote:

for folder I\1.
let's see if it does not DROP too many device IDs. (that's a trend with them..) sad

No, this time they did not drop any device ID, I have checked this "by hand".

From http://downloadcenter.intel.com/filter_ … bmit=Go%21
we can download new Intel driver collection 14.31.1. It contains 6 more device IDs of the new G31/G33/Q33/Q35 chipsets which v14.31.0.4859 did not contain.

I've successfully testet this version with an Intel  DG33BU board.

Edit: Removed [REQ] from topic, since there are already newer versions of this driver.

The driver from D\M\AD\6 Version DriverVer=09/08/2004,3.0.000.000
can be replaced by the newer Version DriverVer=01/22/2007,7.00.00.06 available from
http://www.adaptec.com/en-US/speed/scsi … rt_exe.htm 
It contains one more HWID for 29320LPE device (PCI\VEN_9005&DEV_8017&SUBSYS_00459005) which I added to my DriverPack_MassStorage_wnt5_x86-32.ini. I also added the HWIDs PCI\VEN_9005&DEV_801E and PCI\VEN_9005&DEV_801F that were already supported in previous version but still missing in DriverPack_MassStorage_wnt5_x86-32.ini.

So here is the resulting section of DriverPack_MassStorage_wnt5_x86-32.ini:

[AD-6]
ms_count=1
ms_1_deviceName="Adaptec Ultra320 SCSI Controllers"
ms_1_tag="adpu320"
ms_1_sysFile="ADPU320.sys"
ms_1_hwids="PCI\VEN_9005&DEV_801D,PCI\VEN_9005&DEV_801E,PCI\VEN_9005&DEV_801F,PCI\VEN_9005&DEV_800F,PCI\VEN_9005&DEV_800F&SUBSYS_005F9005,PCI\VEN_9005&DEV_8000&SUBSYS_00609005,PCI\VEN_9005&DEV_8010&SUBSYS_00409005,PCI\VEN_9005&DEV_8011&SUBSYS_00419005,PCI\VEN_9005&DEV_8012&SUBSYS_00429005,PCI\VEN_9005&DEV_8014&SUBSYS_00449005,PCI\VEN_9005&DEV_8015&SUBSYS_00409005,PCI\VEN_9005&DEV_8016&SUBSYS_00409005,PCI\VEN_9005&DEV_8017&SUBSYS_00449005,PCI\VEN_9005&DEV_8017&SUBSYS_00459005"
ms_1_isBusExtender=false
ms_1_exc_disableIfOS="w2k"
ms_1_exc_replaceIfOS="w2k3"

The new driver has been tested successfully on WinXP with a second (no boot device) hard disk.

Duplicate driver found in G_B 7.08 test 1:
D\G\V\3 contains PCI\VEN_1106&DEV_7205,  DriverVer=03/09/2005, 6.14.10.0212
D\G\V\6 contains PCI\VEN_1106&DEV_7205 and PCI\VEN_1106&DEV_3344, DriverVer=06/02/2005, 6.14.10.0226
so the second one seems to supersede the first one, because it's newer, contains one more HWID and both seem to be WHQL certified. So I think the first one can safely be removed.

mr_smartepants wrote:

JSe, I'm looking forward to your followup test results.

And here it is:
It works with version 162.50 and it's unmodified nv4_disp.inf. The drivers show up as WHQL certified on NV 7600 GT and NV 8600 GTS after unattended  setup.
Thanks for DriverPacks, it is a great work. ;-)

Sorry, I did not see that there has been uploaded a newer version (DP_Graphics_A_wnt5_x86-32_708test4.7z). My tests took place with  DP_Graphics_A_wnt5_x86-32_708test1.7z which I got on 08/17/2007 and this version did really contain a modified nv4_disp.inf. So using an unmodified nv4_disp.inf is EXACTLY what we do NOW.

mr_smartepants wrote:

What you're finding are errors created by nvidia that they're not catching prior to release.  If we need to, we can roll-back the nvidia drivers back to 94.24 (stable). 
The point of the test/nightly releases is to find what works and what doesn't.

I think this will not be necessary, and it won't be usefull at all in case of my NV8600 GTS which is still not supported in 94.24. I'm going to test  162.50 and will come back here to report if it succeeded or not.

midiboy(post #56 of this thread) wrote:

One comment towards the Graphics_A 7.07test3 build. I recently integrated this version for a Windows XP install CD for a friend of mine who had built a new PC using a GF 8600 card. He now told me that the videocard drivers were installed but the card was marked with a yellow exclamation mark afterwards in the device manager. A reinstall of the driver solved the problem.

I can acknowledge this problem (PCI\VEN_10DE&DEV_0400&SUBSYS_34481458&REV_A1\4&2B9C2F50&0&0008, NVIDIA Geforce 8600 GTS by Gigabyte). So I tied to find the reason for this bevavior:

1. Installed unattended with the same driver (162.18) on a PCI\VEN_10DE&DEV_0391&SUBSYS_34271458&REV_A1\4&31E9B436&0&0008, NVIDIA Geforce 7600 GT which worked fine with version 94.24, result: the system crash on first reboot after setup.

2. Tried BIOS update an changing some BIOS settings, result: problem persits.

3. Tried original nv_disp.inf (48.520 Bytes, from Jun, 29th 20079) and voila it works on both 8600 GTS and 7600 GT although the unattend.txt contains the necessary statements to handle also unsigned driver.

[unattended]
    ...
    NonDriverSigningPolicy = "Ignore"
    DriverSigningPolicy = "Ignore"
    ...

So I did a file compare between the original an the nv_disp.inf from DP_Graphics_A_wnt5_x86-32_708test1.7z what showed me that there have been added many PCI-IDs in the DriverPack-version. 

So I have the following suggestions:

1. Keep the original nv4_disp.inf in driverpacks

2. make a another *.inf file (lets call it nv4_nwhq.inf) which is a copy of the original nv4_disp.inf where all entries under [NVIDIA.Mfg]
will be replaced by the new PCI-IDs which had been added to nv4_disp.inf.

So we would achieve that all hardware with IDs from the original nv4_disp.inf keeps its WHQL signature and only the new IDs from the unsigned files nv4_nwhq.inf and nv4_go.inf.

OverFlow wrote:

because you dont understand something does not mean there is a bug in the base.

disable was not what you wanted
ms_1_exc_skipIfOS=  or set  ms_count = 0  are to "Disable"  a driver (from your perspective) 

the ms_1_exc_disableIfOS= "wxp" means something totaly different to the Base program.

"load the driver for plug and play but; in a DISABLEd state during text mode setup."
We have never needed to do this for any OS except windows 2000.
...

Yes, you are right, I did not completly understand this functionality, but please note:
1. It was not me, who used this ms_1_exc_disabledIfOS="wxp", I was only the one who wrote that this option caused the problem of commenting out _all_ drivers, not only that one, that had this option applied that follow this driver.

2. What I still would call a (possible) bug is that an option, regardless if it is usefull or not at the point it had been used acts on all the following drivers. And if you dont like the word bug then let's call this unpredictable behavior we should be aware of if it happens again.

Thats funny, I'm testing Adaptec ICP RAID controllers ICP9024RO and ICP5085LI just now, so I had updated [AD-2] in my own copy.
I downloaded the XP version from here:
http://www.adaptec.com/en-US/downloads/ … +ICP9085LI
It seems to be the same as your Folder D\M\I\4 v5.2.0.11829, but the Adaptec download is some older and is not signed.

I've also updated my *.ini as follows:

[AD-2]
ms_count 			= 2
ms_1_deviceName		= "Adaptec SATA/SCSI RAID Controllers"
ms_1_tag			= "aac"
ms_1_sysFile		= "aac.sys"
ms_1_hwids			= "PCI\VEN_9005&DEV_0285&SUBSYS_02859005,PCI\VEN_9005&DEV_0285&SUBSYS_02879005,PCI\VEN_9005&DEV_0285&SUBSYS_02869005,PCI\VEN_9005&DEV_0285&SUBSYS_028A9005,PCI\VEN_9005&DEV_0285&SUBSYS_028E9005,PCI\VEN_9005&DEV_0285&SUBSYS_028B9005,PCI\VEN_9005&DEV_0285&SUBSYS_028F9005,PCI\VEN_9005&DEV_0285&SUBSYS_02909005,PCI\VEN_9005&DEV_0285&SUBSYS_02929005,PCI\VEN_9005&DEV_0285&SUBSYS_02939005,PCI\VEN_9005&DEV_0285&SUBSYS_3227103C,PCI\VEN_9005&DEV_0286&SUBSYS_028C9005,PCI\VEN_9005&DEV_0286&SUBSYS_028D9005,PCI\VEN_9005&DEV_0286&SUBSYS_029E9005,PCI\VEN_9005&DEV_0286&SUBSYS_029F9005"
ms_1_isBusExtender	= false
ms_2_deviceName		= "Adaptec SAS RAID Controllers"
ms_2_tag			= "aacsas"
ms_2_sysFile		= "aacsas.sys"
ms_2_hwids			= "PCI\VEN_9005&DEV_0285&SUBSYS_02f21014,PCI\VEN_9005&DEV_0286&SUBSYS_95801014,PCI\VEN_9005&DEV_0286&SUBSYS_029D9005,PCI\VEN_9005&DEV_0286&SUBSYS_029C9005,PCI\VEN_9005&DEV_0286&SUBSYS_029B9005,PCI\VEN_9005&DEV_0286&SUBSYS_02A09005,PCI\VEN_9005&DEV_0286&SUBSYS_02A69005,PCI\VEN_9005&DEV_0286&SUBSYS_02A19005,PCI\VEN_9005&DEV_0285&SUBSYS_02989005,PCI\VEN_9005&DEV_0285&SUBSYS_02999005,PCI\VEN_9005&DEV_0285&SUBSYS_029A9005,PCI\VEN_9005&DEV_0285&SUBSYS_02A49005,PCI\VEN_9005&DEV_0285&SUBSYS_02A59005,PCI\VEN_9005&DEV_0285&SUBSYS_034D1014,PCI\VEN_9005&DEV_0286&SUBSYS_02A29005,PCI\VEN_9005&DEV_0286&SUBSYS_02A39005,PCI\VEN_9005&DEV_0286&SUBSYS_02AC9005,PCI\VEN_9005&DEV_0286&SUBSYS_02A79005,PCI\VEN_9005&DEV_0286&SUBSYS_02A99005,PCI\VEN_9005&DEV_0286&SUBSYS_02B39005,PCI\VEN_9005&DEV_0286&SUBSYS_02B49005,PCI\VEN_9005&DEV_0286&SUBSYS_02A89005,PCI\VEN_9005&DEV_0286&SUBSYS_02AA9005,PCI\VEN_9005&DEV_0285&SUBSYS_02B59005,PCI\VEN_9005&DEV_0285&SUBSYS_02B69005,PCI\VEN_9005&DEV_0285&SUBSYS_02B79005"
ms_2_isBusExtender	= false

So I think this time we can bring them together, since the IBM drivers contain all IDs the Adaptec ICP files also contain as far I can see.

I reproduced the marking out drivers that should not marked out (in textmode.sif and dosnet.inf) using our test Base version, and want to look at that while using current official release.

The same problem here, tried 70414, 70416, 70417. The problem starts after [AU-3], the first commented out is [C] CPQ32FS2.
Compared to the original 704 there some changes at this point 704 also had [AU-4] and [AU-5] bot no [C].
I have already looked twice but I don't see any anomalies.

I will try to remove drivers to locate the problem. Is there a complete changelog from 704 to 70417 available?

Edit:
OK, I have found the problem:
it's the option
ms_1_exc_disableIfOS= "wxp" under the [C] header.  From this point on _all_ drivers that follow will be disabled, this seems to be a bug of the Base program. I have replaced this option by
ms_1_exc_skipIfOS    = "wxp"
This solves the problem under WinXP, other systems I did not test.