Fencer128

Hi Bashrat, Thanks for this. I'm just creating a build now that I'll test Monday morning. I'll post my results, though I'm pretty sure everything will be fine now. Cheers Andy

Hi, Why not check out the sticky at the top of this forum that is for "DriverPack related articles"? It has a links to the information you require. Good luck, Andy

@nlite0859 Yes, you have understood correctly. The Fedit -rem statement should come before the -add one. @ruudboek Yes, that fixes it. I'm just waiting for Bashrat to check it over. I'd imagine he'd release a new base pack version if he agrees. Andy

Hi, This is a known issue, and the fix is also known. See my post on page 9 of the "DriverPack Base 5.10.5" thread in this forum. Just waiting for Bashrat to get back and release the offical fixed DriverPack. Cheers, Andy

Hi, So do I have this right, the fix is just to update the Sound A DP to the latest Relatek AC97 driver, which in your experience doesn't install on SoundMax hardware when the appropriate SoundMax driver is unavailable, and so the BSOD is permenantly avoided? So Realtek finally fixed their driver? I'm a bit skeptical Cheers, Andy

Hi, Have you tried editing the inf file as per point 79 of: http://www.broadcom.com/drivers/faq_drivers.php This is usually the only workaround that does bot involve waiting for a new release from the manufacturer in my experience. The instructions are for Broadcom products, but it appears to work for any NIC inf file. Good luck, Andy

Hi Bashrat, Just to let you know that new Intel chipset infs are available - 7.2.2.1006. Can download from: http://downloadfinder.intel.com/scripts-df...onal〈=eng Cheers, Andy

@Standard_L RISult has currently not been tested to work with RyanVM's 2.0.0 update pack (see banner screen). The reason for this is that I'm waiting on Bashrat releasing a new version of his Base pack that corrects an issue with High Definition Audio (it's not a big change so hopefully it won't be too long). As soon as this is ready I'll run it (and RyanVM packs) through RISult, make any tweaks that are required and then release a new version. With regard to your issues, my script shouldn't do anyting funny to sp2.cab or txtsetup.sif. If this is something caused by RISult then I suspect it is related to the lack of RVM pack 2.0.0 testing. However, I believe it is not a RISult issue and is most likely related to your source files. RISult expects a clean vanilla SP2 slipstreamed win xp pro source (i.e. no hacking, no nlite, etc). If you have altered your source at all I suggest trying the whole process again, but with untouched files. With regard to nlite, I do not use it and have not built any particular functionality into RISult to support it. Nor have I tested with it. That's not to say it won't work though. Good luck, Andy

Hi there, This sounds very interesting. My colleague uses BartPE via RIS in order to do offline processing on some of our boxes. I'm sure he'd be interested if I could integrate BTS driverpacks for him. I'll have a look at trying this, and then if possible getting it all working via RIS. I admit I persoanlly have limited experience of BartPE at the moment, but if I have any successes I'll report them back here. Don't expect anything too quickly though as I'm fairly busy at the moment! Thanks, Andy

Hi, If know one takes up your challenge, you could always do it yourself http://www.uawiki.org/doku.php?id=wxp:ua:d...driverpacks:diy Good luck, Andy

Hi, I don't know about the specifcs of your problem - but you should be aware that RyanVM has updated both his update pack and the integrator utility used to integrate it. I suggest you give this a go to see if it helps before continuing. Cheers, Andy

Hi djbe, Ok, I've made the alteration and am rebuilding. Will post result to see if HDA now ok again. EDIT 1: svcpack.inf now contains KB888111.cat and KB892559.cat EDIT 2: HDA appears to be working 100% fine Microsoft Update reports no missing patches either I guess that means we have a solution. Cheers, Andy

Hi Bashrat, I have had a look at the HDA problem again now that we have a new RyanVM update pack to play with I've integrated RyanVM Update Pack 2.0.0 (using Integrator 1.0), Base Pack 5.10.05 and all current official Driver Packs. The result is that once the build has installed I am left with the PCI device HDA problem and: C:\Windows\system32\drivers\hdaudbus.sys C:\Windows\system32\drivers\hdaudio.sys C:\Windows\system32\hdaprop.dll C:\Windows\system32\hdashcut.exe C:\Windows\system32\hdaudres.dll C:\Windows\inf\hdaudbus.inf C:\Windows\inf\hdaudio.inf C:\Windows\Driver Cache\i386\driver.cab (contains portcls.sys [5.1.2600.2637]) If I extract portcls.sys to C:\Windows\system32\drivers and then remove the PCI device and redetect hardware, the HDA bus installs correctly. Now, KB888111.ca_ and KB892559.ca_ are present within i386\svcpack of the integrated build files. However, within i386\svcpack.inf there is no reference to either cat file under [ProductCatalogsToInstall] Both KB888111.cat and KB892559.cat ARE present in svcpack.inf if only RyanVM Update pack slipstreamed. I guess from previous posts that this relates to the appropriate CAT file not being installed at build time. I will add a line for KB888111 to svcpack.inf and retry the install. I'll post my results here afterwards. EDIT: Just completed build with KB888111.cat entry added to svcpack.inf. HDA appears to be working fine (no device manager problems), RealTek driver icon in task bar. Unfortunately don't have speakers to test in lab - but it looks ok. Am rebuilding PC with KB892599.cat also in svcpack.inf just to be sure. ** Machine now rebuilt with both CAT file entries ** Everything appears to be working 100% fine. I can only imagine that there is a problem with this section of code in RUN_ME.cmd :KB888111 ROBOCOPY KB888111 I386 *.??_ /MOV %RS%>NUL ROBOCOPY KB888111\SVCPACK I386\SVCPACK KB*.ca_ /MOV %RS%>NUL %INE% I386\SVCPACK.INF ECHO;Generated by Bashrat the Sneaky's DriverPacks>>I386\SVCPACK.INF %IE% I386\SVCPACK.IN_ ( EXPAND -R I386\SVCPACK.IN_ DEL /Q I386\SVCPACK.IN_ ) SET T1=Fedit -rem -f I386\SVCPACK.INF -s Version -l %T1% "Signature=\"$Windows NT$\"" %T1% "MajorVersion=5" %T1% "MinorVersion=1" %T1% "BuildNumber=2600" SET T1=Fedit -add -once -create -f I386\SVCPACK.INF -s Version -l %T1% "Signature=\"$Windows NT$\"" %T1% "MajorVersion=5" %T1% "MinorVersion=1" %T1% "BuildNumber=2600" Fedit -rem -f I386\SVCPACK.INF -s SetupData -l "CatalogSubDir=\"\i386\SVCPACK\"" Fedit -add -once -create -f I386\SVCPACK.INF -s SetupData -l "CatalogSubDir=\"\i386\SVCPACK\"" SET T1=Fedit -add -once -create -f I386\SVCPACK.INF -s ProductCatalogsToInstall -l %T1% "KB888111.CAT" %T1% "KB892559.CAT" SET T1=Fedit -rem -f I386\SVCPACK.INF -s ProductCatalogsToInstall -l %T1% "KB888111.CAT" %T1% "KB892559.CAT" Could it be that the last fedit entries SET T1=Fedit -add -once -create -f I386\SVCPACK.INF -s ProductCatalogsToInstall -l %T1% "KB888111.CAT" %T1% "KB892559.CAT" SET T1=Fedit -rem -f I386\SVCPACK.INF -s ProductCatalogsToInstall -l %T1% "KB888111.CAT" %T1% "KB892559.CAT" are around the wrong way? e.g. should delete before create? I don't know how much help this is to you as this is the behaviour we saw previously with this issue. If you need me to test/report on anything else please do not hesitate to ask as I am as keen as anyone to get this bug squashed. Thanks again, Andy ps - This should possibly be in the "bugs" thread - apologies for that.

Hi, I'll be happy to help resolve this as soon as I get access to my test bed. Just to confirm, the previous 5.10.2 pack fixed the issue so long as RyanVM's pack had the appropriate cat file in place. It then broke from 5.10.4 onwards (never got a chance to check 5.10.3). On a happier note the duplicate entries for HDA files in dosnet.inf, txtsetup.sif, winnt.sif, etc. that occured when both RyanVM and BTS packs were slipstreamed is now (and still) resolved. Thanks for perservering with this, Andy

Hi Bashrat, Just to let you know that the Intel 10.2 WHQL drivers are out. They can be obtained from: http://downloadfinder.intel.com/scripts-df...tems〈=eng 18.9MB in size! Cheers, Andy

Hi Bashrat, Thanks for the update. I now no longer need to remove duplicate entries (for HDA) from dosnet.inf, txtsetup.sif, etc. when integrating both RyanVM and BTS packs. Cheers, Andy

I-AM-NOT-ALONE! thank you Sir! I've got the same problem with same board. I harrassed Bashrat on the Sound driverPack SubForum for this.. waiting for help too. Anyway I have to add that using nLite, KB888111 (inside nLite), BTS drivers, I still get the yellow (!) but doing a search through the disk (I left drivers there) the correct drivers are found and after a reset I get also the mixer in the systray. I hope bashrat have a solution for this annoying issue.. thanks Hi, Please see the DriverPack Base 5.10.5 thread - the issue with HDA now appears to be resolved and will most likely be fixed in an upcoming release of DP Base. Cheers, Andy

Hi, Are you also using the RyanVM update pack? If so this is a known issue. You will need to wait for Ryan to release a new version of his pack - I believe he will try to fix it this way. Regards, Andrew

Hi, Would it not be easier to pick up a couple of cheap PXE capable NICs from ebay, etc. and just work from them? I don't know of another way of getting onto the RIS server via F12 than using a PXE boot disk/on-board ROM Cheers, Andy

Hi, There's a thread here: http://www.msfn.org/board/index.php?showtopic=58118 about using a driver CD. There are many AC 97 audio drivers available. Have a look at the changelog for the sound packs on: http://www.driverpacks.net to see if yours is supported. Someone was looking at a modem driver pack recently, but I do not know what state it reached. Search for "driverpack modem" on the forum to find it. Cheers, Andy

Hi djbe, Don't get me wrong - I realise that your time is your own. I only mentioned the points above in case they hadn't already been considered - I wasn't trying to "hurry" anything along. Keep up the good work Cheers, Andy

The CAT file tells Windows that the drivers are signed and OK. It has to be registered so it's put into the catalog database. I'm not sure I'm really following the rest of your message. EDIT: I realise that I must not fully understand the process here. I'll wait for a pack that contains the necessary cat file before looking at this again. Hi Ryan, When the hotfix is installed outwith any kind of integration (be it your or BTS base pack), the portcls.sys file is placed in the C:\Windows\system32\drivers folder. If I use your 1.3.1 update pack and integrate it and/or BTS base pack 5.10.2 the portcls.sys file is present in the driver.cab, but not anywhere else and HDA is broken. Extracting portcls.sys into C:\Windows\system32\drivers and running "check for new hardware" causes HDA to work again (realtek drivers now install and sound is ok). This is what led me to think that the issue was to do with file location and ask the questions above about whether it was linked to the presence of the associated cat file. I hope that is a little clearer. Cheers, Andy

Thanks for the information Ryan. I understand about the different versions between 888111 and the hotfix you're using. I'm still slightly confused though, if the cat file is required and it is this that is causing the issue, why can I simply copy portcls.sys from the cab file to C:\Windows\system32\drivers (where it is located if you install the hotfix manually) and get everything working? (or is it that the cat file controls whether portcls.sys is copied or not) Cheers, Andy

Hi, I don't think you need a guide to do this - just extract the files from each of the driver packs you wish to include on the CD, move all the the folder structures into a common root directory if you haven't done so already (i.e. a folder called drivers) and then burn a CD containing the folder tree. When you run the install new hardware wizard direct it to the CD drive. Cheers, Andy

Hi, The version of portcls.sys contained within driver.cab when only RyanVM has been integrated is: [5.1.2600.2637] I hope this helps. Let me know if there's anything else I can help with. Cheers, Andy