EvilBetty

I would not say it solves it. It's a pretty nasty fix. It took me a week to sort through all the extra fonts and sys files that it wanted (beyond the above list) to make this work. I would still really like to see this fixed / figured out. Try out the alternate fix that I posted above. You don't have to copy any files into sysprep\i386 or anything. Just edit the sysprep.inf file. I'm interested to know if that fix works for others as well. Alternate fix works like a champ. Unfortunately I do have many source files in my sysprep folder being fired of by sysprep.

I would not say it solves it. It's a pretty nasty fix. It took me a week to sort through all the extra fonts and sys files that it wanted (beyond the above list) to make this work. I would still really like to see this fixed / figured out. From what I've heard from my employers, Microsoft has no interest in perfecting the sysprep technology for anything but Vista related. So I'd say it's up to us... again... Well correct, but this problem is caused by nLite, not by Sysprep.

I would not say it solves it. It's a pretty nasty fix. It took me a week to sort through all the extra fonts and sys files that it wanted (beyond the above list) to make this work. I would still really like to see this fixed / figured out.

Wow did I leave something out... The HDAUDBUS.SYS problem occured ONLY when RyanVM's pack was used w/ nlite. Now I never noticed or not if the SigmaTel splat occured before I began using RyanVM's pack. Another thing to test out Monday.

@legolash2o I'm sorry... Windows XP Professional SP2 I'm out of the office to try this, but first thing Monday morning I'll try your driver, though it looks awefuly familiar. @BikinDutchman Actually I'm using RyanVM's latest Update Pack with nLite. AND I have tried it with and without the HDAUD 888111 AddOn FiX. http://www.ryanvm.net/forum/viewtopic.php?...hlight=hdaudbus ...with no change in either SigmaTel driver functionality, or in suppression the HDAUDBUS.SYS prompt. I had to edit the HDAUDBUS.INF to include the search for the file in the C:\Sysprep\i386 directory. Now I'm just stuck trying to straighten out this driver problem.

This is the driver I downloaded and installed. Then extracted with Driver Genius Profesional (6.1.2518). http://support.dell.com/support/downloads/...p;fileid=205136

Windows XP SP2 Where did you get your driver?

My Dell D620's and D630's are not loading the SigmaTel HDA audio driver correctly. It shows up in device manager with a nice yellow exclamation mark on it, and no working sound. Running Dell's Audio Driver Install setup, will fix the problem. First off I realize that this problem may not be a problem of nLite. But, since I'm using this product along with several others I'm unable to pinpoint where the problem is occurring at this time. I am building a Universal Image for Dell's business product line. OptiPlex / Latitude. I am using nLite, RyanVM updates, DriverPacks finisher, and MySysprep. I am using my own custom driver pack. I have worked through every issue, except this SigmTel audio driver problem. The driver I am using was collected from a Dell D630 with the above mentioned Dell obtained driver loaded, and harvested with Driver Genius Professional. This resulted in a SigmaTel directory and a Microsoft HDA directory. I combined these files into a single audio directory... ./D/06/06_D630 These files apparently are not adding correctly, and I don't know why. I have also tried the Intel Reference Driver with no success.

Right, it's a problem with the path settings being modified by nLite best I can tell. I'm wondering if skinlayers is still having this issue. Copying the i386 directory to my sysprep folder seems like a lousy fix.

How did you get around using the dreaded "c_20127.nls" during mini-setup? http://www.msfn.org/board/index.php?showto...&pid=663325

First off, you can always use this for your service packs and hot fixes: http://www.ryanvm.net/msfn/ Secondly... it seems nuhi is not interested in discussing or working with the enterprise image community. The stance I'm picking up on is that if your getting this error your using sysprep. If your using sysprep, your using this product outside the "personal use" license, and he does not seem to have plans to license this tool otherwise. It's too bad I know my company would shell out for something like this, and could prevent a lot of system administrators some heart ache and work.

Well crap. I'm positive I could get corp to pay for licensing if you wish, otherwise I'm stuck using something else. Do you have any plans to do this? Any plans on working this issue? Thanks!

Um... BUMP?

What is the status of this issue? I'm still getting the error as of today on v1.3.5. I started from scratch with a clean config and a clean XP-SP2 source. Hitting escape gets around it, but beleive it or not I have techs stupid enough to call me every time they see it (after the 3rd email explaining it).

New: Version 1.2: MySysprep can detect the number of a CPU's logical processors. This feature is implemented by using the CPUID instruction to query the vendor ID and the logical processor count (inlcuding Hyper-Threading and multi-core) . To use this feature, a section [CPU] has to be added to MySysprep.inf. The entry name is the vendor ID with a ".MP" or ".UP" suffix. For example. [CPU] GenuineIntel.MP=mp.inf GenuineIntel.UP=up.inf