Search options (Page 58 of 213)

DriverPacks BASE is written in AutoIt - often times any program written in AutoIt is tagged as a virus .
You should go ahead and report it to SuperAntiSpyware for the benifit of everyone.
Thanks for reporting it!

Jeff

Title updated...
Moved to other...

Posts like "I just wanted to say you have a great site", are specificaly listed as forbidden in the "rules and posting guidlines"
Having users report missing / non-working drivers is the main purpose of the forum, you could have safely included the above comment with one of those missing units. 

Since y'all donated... we'll allow you some slack! (not deleted)

Welcome to DriverPacks neighbor!

Looking forward to your input!

Jeff

that is because the drivers can not be properly installed with nLite...

you must use DriverPacks BASE to install the drivers... and if you select text mode then you wont need f6...

Please follow the DriverPacks BASE tutorial in my signature....
ALSO please note that IT SPECIFICALY SAYS not to install the DriverPacks with nLite in the tut...

nope it was deleted and added

2010-02-21 09:30:24 : <PREP> C:\CDinst\REATOGO-270\plugin\DriverPacks.net\MassStorage was deleted.

2010-02-21 09:30:24 : <PREP> C:\CDinst\REATOGO-270\plugin\DriverPacks.net\MassStorage\MassStorage.inf header info written.
2010-02-21 09:30:32 : <SLIP> Extracted DriverPack MassStorage to a temporary working directory.
2010-02-21 09:30:32 : <SLIP> C:\CDinst\REATOGO-270\plugin\DriverPacks.net\BASE\tmp\DPMtmp\DriverPack_MassStorage_wnt5_x86-32.ini
2010-02-21 09:30:33 : <SLIP> Processing Mass Storage files now. This may take a minute.
2010-02-21 09:30:51 : <SLIP> Copied DriverPack MassStorage text mode driver files to BartPE Plugin folder.
2010-02-21 09:30:51 : <SLIP> Slipstreamed DriverPack MassStorage text mode driver files.
2010-02-21 09:30:54 : <SLIP> Updated the MassStorage.ini [SetValue] sections to support DP MassStorage text mode drivers.

And i set it back to the driver that was in use for DriverPack MassStorage 901 can you confirm that DriverPack MassStorage 901 works either with DriverPacks BASE 8.12.5 or 10.02

Well... That time and effort would not be abandoned, Since UBCD4Win is simply a very well done build of BartPE.

Everything you have learned and all the plugins you have accumulated will still be VERY useful with the UBCD4Win version of BartPE. In fact your experience will be very helpful and all of it will still apply since it is still just BartPE. the difference is that they have already put all of the plugins that are 'must haves' and their dependencies in for you in advance. IE the DriverPacks are included in the download, because obviously what good is a BartPE build without our DriverPacks .

You will simply now apply what you have learned adding the plugins you like, assuming they are not already included, and many of them probably are already in there (again like DriverPacks). If they are not already included you can apply what you already know to add them.

The thing of it is that it is so well done. Starting with a strong basic build makes everything else so much easier. Since there are hundreds of thousands of users for UBCD4Win you don't stumble into the pitfalls of reinventing the wheel. Thousands of issues you may have already encountered or would have soon encountered have already been addressed by their team with the feedback of their large audience.  IE large blank spaces in the txtsetup.sif.  You will find that a Disc built with UBCD4Win will boot much faster than a normal BartPE build because of the post PeBuilder process's that will be run. Things Like the INF optimizer, which will also run on your plugins that you choose to add .

Think of it like this... You want to build a Street Racer. You have the choice of either starting with a Camero or a Corvette . Obviously the Corvette will require much less time and effort to be invested to win races. Likewise any experience from building a Camero would still be useful to help with building a Vette, and many of the parts would also be a good fit . But in both cases the vehicle is still a Chevy with the same basic V8 engine one is just a better basic build to start with!

Logic? LOL This is BartPE... logic does not apply
The simple answer is it is possable for more than one driver to match a HWID.... First match wins.  Change the load order and you change the driver that is found and matched first... simple (no PnP logic or driver signing is available nor can it be used in PE)

answering the first question will help clarify
Naturally you would not find the entire HWID. Seldom does an INF list entire HWIDs notice the RAID section of your HWIDs output

PCI\VEN_8086&DEV_27C3&SUBSYS_01D21028&REV_01\3&172E68DD&0&FA
    Name: Intel(R) 82801GR/GH SATA RAID Controller
    Hardware ID's:
        PCI\VEN_8086&DEV_27C3&SUBSYS_01D21028&REV_01
        PCI\VEN_8086&DEV_27C3&SUBSYS_01D21028
        PCI\VEN_8086&DEV_27C3&CC_010400
        PCI\VEN_8086&DEV_27C3&CC_0104
    Compatible ID's:
        PCI\VEN_8086&DEV_27C3&REV_01
        PCI\VEN_8086&DEV_27C3
        PCI\VEN_8086&CC_010400
        PCI\VEN_8086&CC_0104
        PCI\VEN_8086
        PCI\CC_010400
        PCI\CC_0104

You will not ever find a full HWID like PCI\VEN_8086&DEV_27C3&SUBSYS_01D21028&REV_01\3&172E68DD&0&FA anywhere not even in the OEM INF file, this is true of any device and its driver .

That is why we need the output of the tool,
because it lists all the compatable IDs that we WILL be able to find in any given drivers INF files.
They are searched for in the order listed by the tool

So while you were not able to find the full HWID you will find matches for 'compatable' HWIDs in the list.
IE Try a search for the "super generic" HWID 'PCI\VEN_8086&DEV_27C3' and you wil find several "generic" matches.

super generic = PCI\VEN_&DEV_ only
Generic = PCI\VEN&DEV_&SUBSYS_  -or-  PCI\VEN_&DEV_&CC_

we find several super generic matches and one generic match...

PCI\VEN_8086&DEV_27c3&SUBSYS_83521033="megasr"
PCI\VEN_8086&DEV_27c3&SUBSYS_83511033="megasr"
PCI\VEN_8086&DEV_27c3&SUBSYS_834E1033="megasr"
PCI\VEN_8086&DEV_27c3&SUBSYS_82E81033="megasr"
PCI\VEN_8086&DEV_27c3&SUBSYS_819E1043="megasr"
PCI\VEN_8086&DEV_27c3&SUBSYS_349D8086="MegaINTL"
PCI\VEN_8086&DEV_27c3&SUBSYS_349B8086="MegaINTL"
PCI\VEN_8086&DEV_27c3&SUBSYS_348F8086="MegaINTL"
PCI\VEN_8086&DEV_27c3&SUBSYS_348D8086="MegaINTL"
PCI\VEN_8086&DEV_27c3&SUBSYS_348B8086="MegaINTL"
PCI\VEN_8086&DEV_27c3&SUBSYS_34898086="MegaINTL"
PCI\VEN_8086&DEV_27c3&SUBSYS_346B8086="MegaINTL"
PCI\VEN_8086&DEV_27c3&SUBSYS_34698086="MegaINTL"
PCI\VEN_8086&DEV_27c3&SUBSYS_27C31458="megasr"
PCI\VEN_8086&DEV_27c3&SUBSYS_27C01458="megasr"
PCI\VEN_8086&DEV_27c3&SUBSYS_10a51734="megasr"
PCI\VEN_8086&DEV_27C3&CC_0104="iastor78"

In theory the generic match would be prefered to any super generic match but again Logic does not apply to PE .
So PCI\VEN_8086&DEV_27c3&SUBSYS_83521033="megasr" is matched with PCI\VEN_8086&DEV_27c3 and it fails
By moving PCI\VEN_8086&DEV_27C3&CC_0104="iastor78" to the top of the list it works...

Does it make sense... no.. does it work... yes.
But now you have created the opposite issue now your megasas will be matched to iastor78
and that may work some or most of the time... but sorry you can't win them all
such is the logic of PE (or lack thereof)

Load order is a factor if reference drivers do not support a specfic chip
This occurs frequently with OEMs like Dell that make thier own chips but do not adhere to the Manufacturers standards. Laptops also because often the chips are modded to save power ETC. The OEMs sign an agreement to make ther chips so that they will run correctly on reference drivers as part of thier license agreement but often times they will not. (non compliant) But seriously is INTEL going to sue Dell - LOL - not likely! So we are stuck we must include the Reference driver (Intel) and the OEM driver (Dell) and they conflict... Sucks to be us!

Does it mak sense now that it has been explained... Nope. good. It doesn't make sense to me either and I understand it ROFL...

if you do like i said and use UBCD4Win you won't have all that blank space in your txtsetup.sif and yes it is normal.
However UBCD4Win runs an INF optimizer that elminates blank lines and comments to save space on your disk...
Again no sense in killing yourself only to produce an inferior disk Start with the Good stuff an work from there !

The Fault is mine I had implement a special case into BASE and that DriverPack.
It was a rare case where a driver in the DriverPack MassStorage replaced more than one native driver in windows

In  DP_MassStorage_wnt5_x86-32_100125\D\M\C\ the file CPQ32FS2.sys replaces I386\symc8xx.sy_,  symc810.sy_ and sym_hi.sy_.

While I corrected this situation for a normal Disc method slipstream did not address the issue for BartPE... I believe that I have now.
I is possable i will need to do some additional work to fully implement this special case...

try this DriverPacks BASE 10.02.19

Thank for reporting you have helped us make DriverPacks better for everyone and I bestow upon you the coveted 'Hero of the day' award.

Please test and report

I recomended M1... yes! and cautioned you that you SHOULD use QSC this will keep a copy of the Cabbed drivers so you will not have to do this very consuming process more than once . (unless you add or update a pack, even then it will only have to process the new DriverPack not any previously used DriverPacks)
PS make sure DriverPacks BASE is not run on the target machine you will want Base (with the QSC) on your personal workstation the point of the Quick Stream Cache is to speed up the second, third, forth, ... runs for M1 (Say you update a pack)

once you have a M1 source (created on your workstation) copy all the files from DriverPacks.net to c:\ (on the target) and remove the now empty DriverPacks.net folder.

Please DO run devpath on C:\D (this adds all the drivers into the windows search path, a Registry entry)

Call dp_inst_tool however you like... The tool will call the DriverPacks Finisher for you!
Note: ROE 937
- Simply adds a call to the DriverPacks Finisher
- The call is added to the local registry RunOnceEx (ROE) section so it is called the next time the machine boots )
- If you call the DP_Inst_tool then ROE 937 would be redundant (since it calls the DriverPacks Finisher and the tool also calls the DriverPacks Finisher)

The finisher removes the devpath entry from the registry and deletes all DriverPacks related files, and removes itself by adding a ROE entry to be executed on the next boot

Does that help?

that is becuase chipset is not supported... at least not yet...

That is because you did not use DriverPacks BASE to build your plugin read the tutorial in my signature... rtfm

I belive you meant M1 not M2... devpath has no effect on M2 since the drivers are archived

RE:
ROE.exe 937

Quad and you and many other people are aften confused about what this is...

The DriverPacks Finisher DOES NOT install drivers... let me repeat that the DriverPacks Finsher DOES NOT INSTALL DRIVERS!

the finisher determines if any installed devices need to have installers run...
It uses the info in each packs INI to determine if any of these cases exist.
once the exceptions are processed (cases) it deletes the /D/ folder, devpath, the INI's, and itself (after a reboot).

The finisher does as its name implies... it concludes the driver installation and cleans up the mess...

PS yes include the Mass Pack just don't check "Text Mode"

Well definately don't use both at the same time .

If you have the hardware to test on that hardware please do (with our pack) and report the result .
If it works then we can pass on the result to Ryan and RogueSpear . Please  note those pack are from May of 2008

I made considerable updates to the mass storage code in that release the problem may no longer exist, if it does let's get it fixed .

PS Donors are automaticaly made members of the testing team