tattoed_pariah wrote:

"I slipstreamed all DriverPacks as well as used nLite to add all the drivers from the Support cd."

That's probably why your HDD(s) are not recognized.  I would highly recommend starting with a single drive set up as "JBOD".  It will ease the load on your P/S, at the very least; maybe even save some hair follicles.

mr_smartepants wrote:

"1) Never use nlite for drivers."

Quoted from:  http://forum.driverpacks.net/viewtopic. … 539#p48539

After solving that, it could be that some of the other "super-generics" already in DP's may interfere with the install.  If only either floppy worked (symptom?), you would be out of the woods, now.

Another thought is to "clear" your QSC in DP_BASE.

"enable or disable QuickStream Cache (QSC), if not specified: yes
QSC        = "yes""

Otherwise, i see power supply as a "one-in-three" possibility.  The odds increase the older the P/S is and how "loaded" it has been.  Sometimes you can see "burst" capacitors through the fan &/or rear (look closest to mobo power-harness - then by A/C input) with a flashlight.  Power-Supplies in that condition do more to destabalize or even to damage anything connected (nor protected) to it than to simply power it.  (google "capacitor plague")

Aluminum Electrolytic Capacitors are limited in lifespan; although every 10°C decrease in temperature can result in a doubling of it's lifespan.  The "solid polymer" caps are sensitive to high-heat as well, the life-span math differs somewhat though.  Ripple-current is another limiting factor.  Think of "ripple" as akin to audible noise output from an audio amp.

  Dust, debris & detritus are also bad news for electronics.  Beware anything "plated" in and around electronics & airflow.  A power supply is usually a steel "firebox" for a reason.  Avoid Power supplies with aluminum casings; aluminum has a rather low melting-point!

I've seen some nasty holes "gouged" into the steel casings.
I've also seen that "borderline or worse" P/S proper diagnosis are regularly missed in stores, at least the ones that rely upon their "LCD P/S testers" that only measure the 5V line under load (As Dee Schneider @ the House of Hair would possibly say - "They're Crap!!")
It's the 12V line that is most demanding on a P/S.

Caution:  Capacitors can also store a charge, sometimes far longer than would be expected; sometimes even a fatal charge.

An incompatible revision of "MediaShield RAID BIOS" could be a "long-shot" possibility.
  Please quote your MediaShield version number for future reference.


PS:  You are not alone.  Here's someone with the same mobo with a similar issue, yet differing MassStorage HWid's.
see http://forum.driverpacks.net/viewtopic. … 591#p49591 and
http://forum.driverpacks.net/viewtopic.php?id=6266.

777

(75 replies, posted in Software)

BASE links to DP web site at "changelog" tabs (nice there - a link at bottom).
There's also a button to go to the torrent download page.

One idea may be that emulating this approach could suffice, perhaps;
   with DP-Updater as the "torrent client"???

One-at-a-time, use each drive on individual non-RAID SATA, IDE CDrom & run the manufacturer's tools on each drive.  Run four systems to have the operation done fastest.
A complete zeroing of the drive often brings sectors "unreadable" due to power sag back to service.
Then a full "advanced" scan.  Some mfg. tools do this automatically after drive zeroing.
Time consuming, yes!  Effective, YES!

If you want to verify installation with the RAID driver & one drive, just select "JBOD" when you build your "new array" in the RAID BIOS.

Relay which version of RAID BIOS you have.  Sometimes an old mobo bios can stymie your efforts on install, BTW.
If your familiar with BIOS updates, OK.  If not, skip it; if it's done incorrectly, you can "brick" your hardware.  I say this for all audiences.

Not even in the NT6 packs.  There must be a reason for this.  Possibly, it is that "super-generic" thing; i think it possible that this driver "doesn't play well with others".

From the plethora of posts from mr_smartepants, i can deduce that this is not likely to be easy (understatement).  He would know best how to proceed.

Perhaps a solution may involve a new "3rd-party" pack with MassStorage drivers for this specific hardware, to be used in place of the main DP_MassStorage.

"[REQ] nForce Raid / PnP Interface Fix
Original title: [REQ] nForce Raid PCI\VEN_10DE&DEV_0550"

I see that there are some nV test packs http://forum.driverpacks.net/viewtopic.php?id=4742.
Yet, none of those drivers contain those HWid's, nor do they appear in the latest DP_MassStorage.

I wonder why this was never added. 

I'm not making ANY promises (especially since i'm in way over my head here) as these drivers seem to involve "super-generic" HWid's.  hmm


I'm told that nLite corrupts the source.  Search this forum for proper context of that statement.
Integration with RVMi 1.6.1b2.1 previous to DP_BASE is ok.  That appears to support .Iso creation.
I build my test .Iso's with IMGburn (i install w. i'net disabled.  i don't ASK.com).
Take the shortest integration route for tests.

Grab your F6 disc, add the USB-Floppy HWid's as outlined earlier & ensure verification of files on floppy.  done.
Let us know which driver was successful, that it could be added.

see Fernando 1's topic for driver info:
3. "Special MCP65-67 nForce Driverpacks for XP 32/64bit"
possibly, it is relevant to note your RAID BIOS version.

Use a "clean" XP-SP3 Pro source and add latest Chipset & MassStorage using DP_BASE.
Create your .ISO.
Burn to Disc, or USB media with Rufus, or similar.

If it works, you can more easily troubleshoot your current integration.

PS:  HWid's utility is in my signature below these words.  smile

Many USB floppy HWid's can be manually entered into txtsetup.sif:

add to TXTSETUP.SIF after line:
USB\VID_55AA&PID_1234 = "usbstor"

these:

USB\VID_03F0&PID_2001 = "usbstor"
USB\VID_054C&PID_002C = "usbstor"
USB\VID_057B&PID_0001 = "usbstor"
USB\VID_0409&PID_0040 = "usbstor"
USB\VID_0424&PID_0FDC = "usbstor"
USB\VID_08BD&PID_1100 = "usbstor"
USB\VID_055D&PID_2020 = "usbstor"

HWid's tool is linked in my sig. below.   Is it possible that nLite is corrupting your source?
How have you configured the RAID BIOS utility?

783

(75 replies, posted in Software)

"DP_Displays_wnt6-x64_110908.01" and the 32bit version were "Nightlies"; somewhat like an "Alpha"; not to be trusted to "production".  That 2009 version you have listed is a "mine-field", too.

Most do not need to use either pack; others can have troubles caused by this pack.

Most displays are sRGB compatible. 
All one need do now is to set "Color Management" to "sRGB Color Profile.icm".

  Only if a different color profile is desired, or a display not be sRGB compatible, would this pack be convenient and perhaps relevant.

It offers nothing directly for color correction in video; even for Win7 (that's the next spec - included in 8, maybe???)

It offers no automatic detection should a display cable not be I2C compatible, or in the event of a corrupted (or never programmed) EDID chip.  In such events, an appropriate driver would need be manually installed.
Older KVM's can cause I2C communication to be disrupted too.

Registry files are the way to go for customization.
   see http://forum.driverpacks.net/viewtopic. … 983#p49983


Is there a easy way to let people thinking of downloading it facts such as these, to prevent user frustration?
I hope that problems with this or other packs do not hamper people using your "DP-Updater".

Post-Script (PS):  Congratulations on the updates!  That's cool! smile

the HWid is actually "ROOT\WDF01000", methinks.

785

(11 replies, posted in 3rd Party Vista / 7 DriverPacks)

Holy Crap!  Somebody actually uses this?  It must be for a non-sRGB display.  Is there any interest here?
I devoted a month to this & it's NT5 counterpart only to find myself only much less than half-way towards anything comprehensive.

If your monitor/display directly supports sRGB, you don't need drivers, unless your monitor/display is not auto-detected by windows.  Registry-based EDID overrides may allow some non-3D displays to output simple 3D video and allow HDMI1.4-thru-HDMA1.3 passthru support on HDMI 1.4 non-compliant Audio/Video Surround Receivers, etc.
http://forum.driverpacks.net/viewtopic. … 374#p46374

If it's the EDID chip that's at issue; have it reprogrammed.  Enter Service Mode within the Display & write the right chip content & capacity.  End of issue.

786

(12 replies, posted in Other)

Charlie Demerjian wrote:

"Intel kills off the desktop, PCs go with it
Analysis: Broadwell has no socket, PCs have no relevance

Intel logo 63x58 Intel kills off the desktop, PCs go with it  Intel is killing the desktop, but not quite as soon as people expect it to, there will be one last gasp, but that is irrelevant. Word is finally leaking there won’t be a desktop PC chip in a bit over a year.

In a story that SemiAccurate has been following for several months, Broadwell will not come in an LGA package, so no removable CPU. The news was first publicly broken by the ever sharp PC Watch, english version here, but the news has been floating in the backchannel for a bit now. The problem? This information wasn’t floating around the OEMs or the majority of the PC ecosystem, they had no clue. What does all of this mean? Quite a bit.

The most direct effect is that of Broadwell, the 14nm successor to next year’s Haswell CPU, will essentially shut out the enthusiast. Motherboards will still be available, but the CPUs that come with them will be soldered down. In addition to being a inventory management nightmare, OEMs won’t buy CPUs any more, the few remaining mobo vendors and ODMs will. As a side effect, it also cuts the enthusiast out of the picture for good"
Quoted from: http://semiaccurate.com/2012/11/26/inte … o-with-it/"

Charlie Demerjian wrote:

"no new chipsets for Broadwell"
...
"Broadwell cores are also not slated for a major revision, they are mainly being shrunk to 14nm. A few bits of low hanging fruit are being picked with the shrink, but no big bangs. Think performance per watt gains, outright performance will again underwhelm on the CPU side.

Will Broadwell bring anything to the table worth noting? Actually yes, SemiAccurate moles have said that the CPU will have a brand new GPU with a lot of new instructions, and a few radically improved ones too. It will not be the big graphics bang that Haswell is, but it should increase GPU performance by a claimed 40% from what it’s 22nm sibling has. If Broadwell is only at the same TDPs, it will be a clear win, but it will likely drop power by a substantial margin. Unfortunately for the user, Intel graphics drivers are still woeful and broken, and there is no internal impetus to change that."
...
"the state of Intel drivers is going to keep discrete GPUs relevant for another generation."
Quoted from: http://semiaccurate.com/2012/11/29/inte … ails-leak/

Brid-Aine Parnell wrote:

"Cash-hungry Sharp 'offering juicy stakes to US firms'

Sharp is in talks with US firms including Dell, Intel and Qualcomm to sell off bits and pieces of itself, it has been reported."
Quoted from: http://www.theregister.co.uk/2012/11/30 … e_rumours/

The Electronista Staff wrote:

"Banks offer to help Sony sell battery business"

Lawrence Latif wrote:

"Moody's cuts HP's credit rating amid competition concerns
...
"from A3 to Baa1, which is three steps above 'junk' status."

and then there's "Bob".   Cue Homer J. Simpson; "Ding Dong Ding, D'OH!!!"

I sense some market consolidation forces gathering energy; this is not advice, only my humble opinion.

Lee Hutchinson wrote:

"NAND flash gets baked, lives longer
Discovery by ROM manufacturer Macronix could defeat flash's greatest weakness."
...
"It's long been known that annealing NAND flash—that is, subjecting it to high heat—can force the long-trapped electrons out of the NAND floating gate, reducing its retained charge and returning it to usefulness. But it's been thought all along that such annealing was too energy-intensive and too difficult to do precisely—essentially, an entire NAND chip had to be baked for hours.

However, using techniques borrowed from phase-changing RAM, where heat is applied to a material to change its state from conductive to insulating, the Macronix boffins constructed a redesigned NAND flash package with its existing electrical pathways modified to carry heat to the floating gate, the portion of the NAND transistor that is filled and drained to denote a 0 or a 1.

The modification is a complex one and required substantial engineering, but the results are impressive—a brief and restricted jolt at 800C appears to "heal" the flash cell, removing its retained charge. Macronix estimates that this can be done repeatedly as needed, leading to a flash cell that could potentially last for 100,000,000 cycles, instead of the roughly 1,000 cycles that current 21nm TLC flash cells are rated to last.

Since flash cell life cycle decreases as process size shrinks, this method of heating cells back to life is good news for the future of SSDs. Moore's law charges on; the International Technology Roadmap for Semiconductors projects an eventual arrival at 8nm features, and the useful life of NAND flash at that size is very, very short. If Macronix's method can be commercialized it will have profound implications on the future of the medium."
Quoted from: http://arstechnica.com/science/2012/11/ … es-longer/

Wow, if i end up with an out-of-warranty SSD with a wretched-excess of dead cells & redundant data; i'll have to bake it for a few days ("sans" plastic) at 80°C (or more?) to try that one out.

Thanks!  I'll read that tomorrow.

  I need to review more examples of modifications to MS to gain confidence.  I still don't understand why the "etronXHCI" tags didn't ultimately work with "etronx.sys".  hmm

Ah.  That is some real legacy hardware.

Oh, so that was solved?  hmm

Am not a fan of the spam.

From what i read, Samsung Laser printers could represent another class of vectors, as there exists a hidden "admin" acct.; well, that is, they say the ones mfg. after October 31, 2012 are OK.
http://www.theregister.co.uk/2012/11/28 … n_account/
It's amazing, a professer (whose name escapes me) a year or more ago showed that it was possible with some models to overload the fuser after stopping the paper, thereby starting a fire.  yikes

That includes Compaq HWid's from PNPSCSI.inf.
I see those very files {symc8xx, symc810, sym_hi and sym_u3.sys} in my own source both before and after integration, as well as installation on real hardware (without the EISA SCSI adapters, of course).  So this is an issue that occurs for you during your setup.

One can indeed see how those entries in red (below) can cause issues.
It could go in a catagory of drivers that "don't play well with others".
I found one myself some months ago effecting many PCIe controllers.
http://forum.driverpacks.net/viewtopic.php?id=5911

Stumped?  I never looked.
I do thank you for considering others by posting that information.

Here are the HWid's at issue:

DP_MassStorage_wnt5_x86-32_1206.7z\D\M\C\cpq32fs2.inf:
[COMPAQ_HDC]

"%PCI\VEN_1000&DEV_0003.DeviceDesc%=pciScsi825_Inst, PCI\VEN_1000&DEV_0003
%PCI\VEN_1000&DEV_000f.DeviceDesc%=pciScsi825_Inst, PCI\VEN_1000&DEV_000f
%PCI\VEN_1000&DEV_000b.DeviceDesc%=pciScsi825_Inst, PCI\VEN_1000&DEV_000b
%PCI\VEN_1000&DEV_000c.DeviceDesc%=pciScsi825_Inst, PCI\VEN_1000&DEV_000c
%PCI\VEN_1000&DEV_0001.DeviceDesc%=pciScsi825_Inst, PCI\VEN_1000&DEV_0001
%PCI\VEN_1000&DEV_000a.DeviceDesc%=pciScsi825_Inst, PCI\VEN_1000&DEV_000a
%PCI\VEN_1000&DEV_0012.DeviceDesc%=pciScsi825_Inst, PCI\VEN_1000&DEV_0012
%NCRC710.DeviceDesc%=EisaScsi_Inst, NCRC710_SCSI
%CPQFWS2E.DeviceDesc%=EisaScsi_Inst, CPQFWS2E_SCSI
"
...
"[Strings]
COMPAQ                           = "Compaq"
PCI\VEN_1000&DEV_0001.DeviceDesc = "Compaq 32-Bit Fast SCSI Controller /P"
PCI\VEN_1000&DEV_0003.DeviceDesc = "Compaq 32-Bit Fast-Wide SCSI Controller /P"
PCI\VEN_1000&DEV_000f.DeviceDesc = "Compaq 32-Bit Ultra SCSI Controller /P"
PCI\VEN_1000&DEV_000b.DeviceDesc = "Compaq 64-Bit Ultra2 SCSI Controller /P"
PCI\VEN_1000&DEV_000c.DeviceDesc = "Compaq 32-Bit Ultra2 SCSI Controller /P"
PCI\VEN_1000&DEV_000a.DeviceDesc = "Compaq Integrated Dual Channel Wide Ultra2 SCSI Controller"
PCI\VEN_1000&DEV_0012.DeviceDesc = "Compaq Integrated Wide Ultra2 SCSI Adapter"
NCRC710.DeviceDesc               = "Compaq 32-Bit Fast SCSI-2/E Controller"
CPQFWS2E.DeviceDesc              = "Compaq 32-Bit Fast Wide SCSI Controller /E""

PNPSCSI.INF: - included with XP SP3
"[COMPAQ]"
...
"%PCI\VEN_1000&DEV_0012&SUBSYS_001b0e11.DeviceDesc% = sym_hi_Inst, PCI\VEN_1000&DEV_0012&SUBSYS_001b0e11
%PCI\VEN_1000&DEV_000b&SUBSYS_60040e11.DeviceDesc% = sym_hi_Inst, PCI\VEN_1000&DEV_000b&SUBSYS_60040e11

%*CPQFD17.DeviceDesc%=NO_DEV,,*CPQFD17"
...
"COMPAQ = "Compaq"
cpqarray.DeviceDesc = "Compaq Drive Array"
cpqarry2.DeviceDesc = "Compaq Smart Array Controller"
cpqfcalm.DeviceDesc = "Compaq Fibre-Channel Host Controller"
*CPQFD17.DeviceDesc = "Compaq SCSI Tape Adapter"
PCI\VEN_1000&DEV_0012&SUBSYS_001b0e11.DeviceDesc = "Compaq Integrated Wide Ultra2 SCSI Adapter"
PCI\VEN_1000&DEV_000b&SUBSYS_60040e11.DeviceDesc = "Compaq 64-Bit Ultra2 SCSI Controller"
smart_5300.DeviceDesc = "Compaq Smart Array 5300 Controller"
smart_532.DeviceDesc = "Compaq Smart Array 532 Controller"
PCI\VEN_0E11&DEV_A0FC&SUBSYS_A0FC0E11.DeviceDesc = "Compaq StorageWorks 64-Bit/66-MHz Fibre Channel Host Bus Adapter""
...
"[LSI]

%PCI\VEN_1000&DEV_000C.DeviceDesc% = symc8xx_Inst, PCI\VEN_1000&DEV_000C
%PCI\VEN_1000&DEV_000F.DeviceDesc% = symc8xx_Inst, PCI\VEN_1000&DEV_000F

%PCI\VEN_1000&DEV_000A.DeviceDesc% = sym_hi_Inst, PCI\VEN_1000&DEV_000A
%PCI\VEN_1000&DEV_000B.DeviceDesc% = sym_hi_Inst, PCI\VEN_1000&DEV_000B
%PCI\VEN_1000&DEV_0012.DeviceDesc% = sym_hi_Inst, PCI\VEN_1000&DEV_0012"
...
"%PCI\VEN_1000&DEV_0001.DeviceDesc% = symc810_Inst, PCI\VEN_1000&DEV_0001"
...
"%PCI\VEN_1000&DEV_0003.DeviceDesc% = symc8xx_Inst, PCI\VEN_1000&DEV_0003"
...
"LSI = "LSI Logic Inc."
PCI\VEN_1000&DEV_0001.DeviceDesc = "LSI Logic 53C810 Device""
...
"PCI\VEN_1000&DEV_0003.DeviceDesc = "LSI Logic 53C825/53C825A Device""
...
"PCI\VEN_1000&DEV_000C.DeviceDesc = "LSI Logic 8951U/8952U Adapter; 53C895""
...
"PCI\VEN_1000&DEV_000F.DeviceDesc = "LSI Logic 53C875/53C876 Device"

PCI\VEN_1000&DEV_000A.DeviceDesc = "LSI Logic 53C1510 Device"
PCI\VEN_1000&DEV_000B.DeviceDesc = "LSI Logic 53C896 Device"
PCI\VEN_1000&DEV_0012.DeviceDesc = "LSI Logic 8953U PCI SCSI Adapter; 53C895A Device""

I will archive that driver if you remove that spam link.  neutral

Incredible; food in Japan is limited to 100Bq/Kg for human consumption (that used to be the limit for hazardous waste).
Here in North America, the limits are set at an astounding 1000Bq/Kg.  Lesser rad levels in food and children were enough to help convince JFK to sign the Nuclear Test Ban Treaty.

I wonder where the Japanese food exports are going.  Remember, corporations have a right to "free speech", including marketing and advertising, and they exercise that "right" frequently, and at times to people's detriment.  That experimental fusion reactor previously mentioned actually emits Alpha particles; they call it "Helium".
  IMHO, this is probably not a good time to consume a whole lot of bottom-feeding North Pacific seafood at the very least.  Try back in 60-300 years or so.

The previous poster (spammer) calls it "nice information".  It's not nice.
  It is a warning to anyone whom will diligently listen.

Thyroid cancers are already being detected in children in and around Fukushima prefecture.*  That is roughly half the time it took with the "Chornobylska Katastrofa" (it only burned for 10 days, iirc).  Land reclaimation cannot meaningfully begin until emissions are brought to a halt (including incinerated waste - yes the Japanese are burning radioactive debris** AND "Ground Zero" is still collectively emitting).

  Would you knowingly want to purchase any canola from Belarus or Japan for your family?

My humble respect for all victims of radiological poisoning, both known and unknown.
My deepest respect goes towards the Tchernobyl Firefighters, the "Fukushima 50" and the uncounted others that have sacrificed in ways so few have ever previously, that others may live.

*  http://ex-skf.blogspot.ca/2012/11/is-th … re-in.html
    http://fukushima-diary.com/2012/11/the- … a+Diary%29
     http://www.businessinsider.com/fukushim … ths-2012-7
     http://fukushima-diary.com/2012/09/thyr … shma-city/

Charles Digges wrote:

"The incident is yet another unsettling reminder of the tight ties between Japan’s nuclear industry and its regulators, who, it has recently been proved, have distorted, ignored and outright lied about the impact the radiation still spewing from the tsunami-rocked Fukushima Daiichi plant has and will have.

Last week, it was revealed that the Japanese government ignored its own multi-million dollar radiation forecasting system, thereby evacuating hundreds of schoolchildren directly into the path of the radiation plume emitted from the plant. Similarly, no data is available on the exposure on those erroneously settled into zones of high radiation.

According to environmentalists, it will - as in the case of Chernobyl - be a matter of decades before the full extend of radiation on the human population of Japan can begin to be tallied.

Though, while data on human exposure continues to be sparse, it is now clear that the radioactive isotope caesium 137 from Fukushima Daiichi has invaded Japan’s food chain from mushrooms to fish to rice and beef."
     http://www.bellona.org/articles/article … id_coverup

**  http://enenews.com/3-workers-suffer-car … 7-exposure
      http://fukushima-diary.com/2012/11/debr … a+Diary%29
      http://fukushima-diary.com/2012/11/debr … s-protest/
      http://fukushima-diary.com/2012/09/cesi … n-tochigi/

http://fukushima-diary.com/2012/09/3192 … e-tablets/  Smile on, Doctor; it confuses the biometrics.

The Vostro 270 OEM driver (win7) is here --> http://downloads.dell.com/FOLDER0029510 … CK_ZPE.exe
That driver you mentioned cdob seems to offer updates including SA2 & AFA. over the R307709 package, although not as much as the Fujitsu driver.  That driver matches MIXER.ini & ALTMIXER.ini as well as uci32a84.dll.
He's importing the Win7 .cat file from the original, as well as a modified inf and 3 .dll's.  At least the executable is properly signed, so still a chance for 2k3 support?

Congratulations!

Ah, it would seem that you decided to mod the whole thing.  I see now in AFA\AFA\ the existance of "AFAXP32.cab".  I failed to see that before.  That seems to cement the fact that this package was (at least at one time) partly intended to unofficially support XP.  Rather sporting of dell, actually.  If only it were that easy for the USB 3.0 driver.

"Any chance to see this in a new XP package soon?"

This idea of yours is still somewhat in a "proof-of-concept" phase.  It needs a little more research (& wall-time); call it a "testing" phase.  Try some media with differing audio codecs to verify output.  I see that this would be worthy of including in the Sound DriverPack.

Could you give these HWid's a try on a fresh install?  I think, if successful, should preclude earlier HW from installing this driver when added to DP_Sound.
Of course, i am assuming here that this driver won't work for older chips.

It would be good to know if you are receiving any odd issues or errors.  Check the Event Viewer to be certain, if you have not already.  Also, what of Driver Signing (from Device Manager - incl. Driver Files button)?  I assume that with the .cat from the dell driver & the Digital Signature in the chdrt32.sys that at least all the files show as WHQL.

%HdAudioFunctionDriver.CNXTCodec.DeviceDesc% = HdAud2064x.MA3W, HDAUDIO\FUNC_01&VEN_14F1&DEV_50A1&SUBSYS_10280581&REV_1001
%HdAudioFunctionDriver.CNXTCodec.DeviceDesc% = HdAud2064x.MA3W, HDAUDIO\FUNC_01&VEN_14F1&DEV_50A2&SUBSYS_10280581&REV_1001
%HdAudioFunctionDriver.CNXTCodec.DeviceDesc% = HdAud2064x.MA3W, HDAUDIO\FUNC_01&VEN_14F1&DEV_50A1&SUBSYS_10280582&REV_1001
%HdAudioFunctionDriver.CNXTCodec.DeviceDesc% = HdAud2064x.MA3W, HDAUDIO\FUNC_01&VEN_14F1&DEV_50A2&SUBSYS_10280582&REV_1001

I like adding "Thanks" in changelogs & of course in the Forum.
  I'm not certain if i will have time to work on Sound, yet if you post a new Topic in the DP_Sound forum and label it
"[REQ] add this conexant driver fix ... for example".  In your post, ensure that you include the link to the file from the OEM. 
   (for example:  original dell http://downloads.dell.com/audio/CONEXAN … 307709.exe
                          Fujitsu - http://webdownload.ts.fujitsu.com/downl … dvbHR6Yi8xsmile
Someone will "shoehorn" this into the pack for all owners of this HW to enjoy (well, those using DP's).  big_smile
  Include a link to a complete modded pack, if it pleases you.  Just ensure to retain any original license files.

Thank you for considering others.

It sounds like you are making some progress with the .INF files.  I have known similar frustrations, as have many others that post here (and far beyond, of course!).

One thing about HDMI.  You need to plug in the cable ends before it can be usable as an Audio Device.  It doesn't always switch so nicely in XP, from what i've read,  yet a restart all-but guarantees the switchover (unless a prob. w. EDID, iirc) "just-in-case".

[off-topic]
Here's a freeware solution, possibly, with command-line support that i recently remembered.  It is available in German and English.

Quck Sound Switch via tools.toflo

                  for Win2K, XP
http://www.quicksoundswitch.toflo.de/  big_smile

"Even with this utility, most Windows programs can’t switch audio devices while running. "
...
"So, this utility saves you the trip to the Control Panel to change audio devices, but you still need to restart any audio programs you may have already opened in order for the switch to affect them."
...
"Version 2.0 comes with a "Shortcut wizzard" to solve this problem: It creates shortcuts to your Application / Game .. which automatically switches the Soundcard even before the App. / Game starts."

Even if the utility is not relevant (nor anywhere near as impressive as SAD2.2); the License listed in the Version Tab, is actually "Flo"!
[/off-topic]

Remember, any experimentation, you do at your own risk (and/or you employers).

That said, there is, in existence, if i get this correct, a CX20641, a CX20642, and a CX20641/CX20642 (dell, iirc).  hmm

Flow wrote:

"I thought maybe playing around with hwid's in the ini files"

The .inf files are probably the only ones needing editing; to add your SUBSYS & REVision.  There are also some Registry entries that would need updating with the Vostro270 original entries (if applicable).
MIXER.INI & ALTMIXER.INI are the same compared to the official w7x64 driver from dell.

Ensure you manually install only the driver in DeviceManager.  Choose to "Manually Install" & indicate that you "Have Disk".  Sometimes, if you get a Volume Icon in your SystemTray, yet no audio, you may need to check your Audio Properties.  If the AFA or SA3 packages are causing problems, comment out those sections necessary and try again.

a side-Note:
  OEM's are offered multiple choices in configuration of many Audio solutions.  They tend to take advantage of the customizations wherever necessary and/or advantageous.  Often they reuse these customizations and apply them to a variety of models (Chipset-dependent).  There are also those which only apply to few models for a variety of reasons.  Supplies of the chips themselves do change over time as new designs are realized, or old designs improved or updated.
  Operating Systems and their unique Driver Models & Signing Requirements (including Cipher-strength) often change, dependent upon Windows major &/or minor version.  The Driver Signing itself can be upwardly compatible.  Audio drivers are often Manufacturer-specific concerning Notebooks & Tablets, as well as TouchPad (& Touch?) drivers.  Manufacturers tend to focus their driver team(s) to release drivers for Operating Systems that are current, and not already or soon to be decommissioned (although Embedded XP is officially supported by MS into 2016).
  I'm no expert, yet that is a distillation of what i've gleaned over time.

  From your response "no" concerning HDMI, i reason that you don't have an HDMI connector on the back of your Motherboard.  HDMI does usually include an Audio Device.  The clear advantage of this is the one cable.  Installing a PCIe Graphics card with HDMI is another potential solution (nothing fancy or expensive, or POWER-Hungry - you might only have a 300W P/S).  If you have made it this far, still stymied, an addon-card or USB solution may be the last of the options available today.

side-Note #2:
  How has your experience been with Intel USB 3.0 so far?

That could be a reason for adopting 7 earlier (no, i'm not a salesman), as that is the only Windows OS with an available WHQL'ed driver.

  It is not just the Audio that you have no proper driver for concerning XP.  Any other Windows OS is currently limited to USB 2.0, if it is set in BIOS (uEFI?).

  I am uncertain of linux support for your particular intel Chipset, though it seems likely.

I suppose i would have noted this earlier, had you posted your HWid's from the Signature-linked utility
that is below this particular text.

In Win 8, would WDF01000's parallel be "Ucx01000.sys" in the xHCI stack?
   see first graphic --> http://msdn.microsoft.com/en-us/library … 85%29.aspx  hmm

Quoted from above link:
"The USB 3.0 stack is new in Windows 8. Microsoft created the new drivers by using Kernel Mode Driver Framework (KMDF) interfaces. The KMDF driver model reduces complexity and improves stability.
USB 3.0 host controller driver (Usbxhci.sys)

The xHCI driver is the USB 3.0 host controller driver. The responsibilities of the xHCI driver include initializing MMIO registers and host memory-based data structures for xHCI controller hardware, mapping transfer requests from upper layer drivers to Transfer Request Blocks, and submitting the requests to the hardware. After completing a transfer, the driver handles transfer completion events from the hardware and propagates the events up the driver stack. It also controls the xHCI controller device slots and endpoint contexts.

The xHCI driver is new in Windows 8 and is not an extension of the eHCI miniport driver that was available in earlier versions of the operating system. The new driver was written by using Kernel Mode Driver Framework (KMDF) interfaces and uses KMDF for all controller power management and PnP events. Windows loads the xHCI driver as the function device object (FDO) in the device stack for the host controller.
USB host controller extension (Ucx01000.sys)

The USB host controller extension driver (an extension to KMDF) is the new extension to the underlying class-specific host controller driver, such as the xHCI driver. The new driver is extensible and is designed to support other types of host controller drivers that are expected to be developed in the future. The USB host controller extension serves as a common abstracted interface to the hub driver, provides a generic mechanism for queuing requests to the host controller driver, and overrides certain selected functions. All I/O requests initiated by upper drivers reach the host controller extension driver before the xHCI driver. Upon receiving an I/O request, the host controller extension validates the request and then forwards the request to the proper KMDF queue associated with the target endpoint. The xHCI driver, when ready for processing, retrieves the request from the queue. The responsibilities of the USB host controller extension driver are:

    Provides USB-specific objects to the xHCI driver.
    Provides KMDF event callback routines to the xHCI driver.
    Manages and control the operations of the root hub associated with the host controller.
    Implements features that are configurable by the client driver, like chained MDLs, streams, and so on.

USB hub driver (Usbhub3.sys)

The new hub driver, in the USB driver stack for 3.0 devices, uses the KMDF driver model. The hub driver primarily performs these tasks:

    Manages USB hubs and their ports.
    Enumerates devices and other hubs attached to their downstream ports.
    Creates physical device objects (PDOs) for the enumerated devices and hubs.

Windows loads the hub driver as the FDO in the hub device stack. Device enumeration and hub management in the new driver are implemented through a set of state machines. The hub driver relies on KMDF for power management and PnP functions. In addition to hub management, the hub driver also performs preliminary checks and processing of certain requests sent by the USB client driver layer. For instance, the hub driver parses a select-configuration request to determine which endpoints will be configured by the request. After parsing the information, the hub driver submits the request to the USB host controller extension or further processing. "

ArnoBosch wrote:

"VMWare seems to support USB 3.0 on a Windows host system only with NEC xHCI-drivers."
Quoted from:  http://communities.vmware.com/message/2139363#2139363


edit:  oops, i see that i added this last quote after you posted the following:

The above driver links to v1.90A, it is nowhere,
sorry, that is now here --> http://download.gigabyte.us/FileList/Dr … b3_x79.exe  big_smile

RTM Win8 driver known as "0096", not certain which version.
  referenced from http://communities.intel.com/message/171581#171581

intel xHCI USB 3.0 Host Controller/Hub

For those looking for Windows 8 support, other than the in-built "0100" driver (referenced from http://communities.intel.com/message/171581#171581), thusfar you may be in the same boat as 2K, XP, W2k3, & Vista licensees; that is stuck with USB 2.0 speeds.  sad

Squilliam wrote:

"The reason you aren't finding any Intel drivers, is because they aren't providing driver support for Windows 8. Microsoft has taken over the task of writing drivers for USB 3.0 chipsets. This obviously was a mistake on their part. Not because they took over responsibility, but because they didn't handle it properly."
Quoted from:http://answers.microsoft.com/en-us/wind … 702612df4b November 9,2012 @ 2:36:09 AM

There are additional consequences:

Bruce Harrison wrote:

"It seems that the 'universal' USB 3 drivers in windows 8 do not allow installing directly from USB 3."
Quoted from: http://communities.intel.com/message/172275#172275

And a workaround (seemingly lacking newer PM features for 8) by ekko has emerged:

ekko wrote:

"What these changes do is add in the IntelAMD64.6.2 section into the driver INFs (the files that tells Windows HOW to install the driver). This section is blank in the current driver release."
quoted from:http://communities.intel.com/message/171830#171830

What of the possibility of a similar alternate .Inf for Vista support, possibly even W2k3 or XP?
What matter of the status of WHQL on the update .Inf file (in addition to the original), so long as the .Sys files are Digitally Signed?  hmm



PS:

"one important tidbit concerning Driver Signing.  If it's just a modded .Inf that is at issue:"

Laslow wrote:

"Once the driver is installed you don’t need to leave enforcement disabled."

Quoted from: http://forum.driverpacks.net/viewtopic. … 705#p49705

That is, except for removable devices, likely.

Hello & welcome to the DriverPacks forum!  smile

You could try integrating the USB 3.0 files from here, using DP_BASE from a clean XP source.
Use this for a Fresco Logic or a VIAlabs USB 3.0 Host Controller Hub.

Do this before making the "MiniXP" disc with nLite.

Note that it is not possible (as far as i know) for an intel USB 3.0 Host Controller/Hub.

sorry if my comments are not relevant.

Fresco Logic xHCI (USB3) Controller/Hub FL1000, FL1009, FL1100, FL1400 Series

updated to (DriverVer=11/02/2012,3.5.93.0), WHQL'ed for Win7 (x86 & x64)
here --> http://download.gigabyte.us/FileList/Dr … o_usb3.exe  big_smile

Gigabyte wrote:

"OS:Windows XP 32bit,Windows XP 64bit,Windows Vista 32bit,Windows Vista 64bit,Windows 7 32bit,Windows 7 64bit,Windows 8 32bit,Windows 8 64bit "
Quoted from:  http://ca.gigabyte.com/products/product … l=1#driver


Notes:  a) No word on whether or not the following quote from the post above still applies.  hmm

"Note:  If any Intel USB ports stop responding after applying this driver, roll back to v3.5.46.0
          see http://social.technet.microsoft.com/For … 98f588730e"

           b) All executables & libraries are Digitally-Signed