Search options (Page 33 of 213)

I never imagined that we would exceed the array size in a single INF and i discovered the array size bug... wow looks like we are going to have to resort to an array per manufacturer section in a single inf... that's crazy!

Hiya Helmi!!!!

Well i am quite glad that MS has provided DPINST.exe ... but like many of it's releases it falls short of the mark.

What did the setupapi log yeild?

I don't know that recommending "enabled" is wrong. That is the way it always was, except for a short time when there was an issue, once I resolved the issue i put it back the way it was.

The clear advantage to having it "Enabled" is: if you EVER need to use it again the compression will not have to be redone. So every run after the first one will be signifigantly faster. Therefore it is recommended! (on my machine it takes about 6 minutes to slipstream, so 2 minutes is 33% faster and that is "signifigant", even though it is only a couple of minutes LOL.

If you know for a fact that you are absolutely never going to slipstream the same mass storage pack ever agian in your whole life you can save about 5 meg of disc space by having it "Disabled".   IE You are a home user reloading your personal desktop. We don't get many of those users here .

So no... I disagree it does NOT wrongly suggest "Enable QSC".  Enabled has always been and still is recomended (other than when we had the bug).

Jeff

as far as i know Wim Leers pioneered the idea at MSFN under the nickname Bâshrat the Sneaky. He was told it was not possable and was laughed almost off the forum... till he made it work.

try it the suggested way with devpath instead of oempnppath... it will save you a boat load of the work you just described.

to get around the reigistry size issue most people do the 3rd party DriverPack with SAD and the main packs with the method described.

this works because the DriverPacks Finisher resets the device path and removes the main packs. if you run sad after the finisher then the tpdps will be an isolated run. first run main packs with minisetup... second run during gui mode after the finisher runs on the main packs and cleans them up and resets the device path in the registry. Clean slate for SAD to run the 3rd party DriverPack from !

QSC makes a cached copy of any cab compressed drivers when you slipstream. (Quick Stream Cache).

for a few versions there was issues related to slipstreaming XP then 2k3 then BartPE. Some of the files were not cached and caused issues. That problem was fixed. So the answer is "It depends which version of BASE you use".

With M2 only the mass storage TextMode drivers are cached.
QSC is only useful if you intend to reslipstream the same packs multiple times. Otherwise it is of little or no benefit. It simply does not take that long to cab compress what few mass storage drivers there are. The reall benefit of QSC dates back to useing M1 when all the packs were CAB compressed and it would take an hour or so to do them. So a second pass would nto take an hour since they would nat have to be compressed again... simply copied.

If you are only making one disc there is no difference if QSC is off or on. QSC only benifits if you are doing multiple slipstreams with the same mass pack. even tehn it only saves you a minute or two based on your machines speed.

I hope that clears it up for you!

Jeff

publicly available test packs for mass storage are posted in the Mass Storage forum. They are only offered to users in direct response to posted issues. If you neeed a test pack post an issue you are having ! (If you are not having any issues then you don't need one LOL)

Do what i said

NOTE:
If you followed the directions above you already have the correct entries int the Device Path Key and don't need OEMPnpDriversPath (this would explain why it worked for you )
>> 3. Extract DevPath.exe from DPBase\bin\wnt5_x86-32\M2.7z and run DevPath.exe C:\D

This way you don't need to fool with OEMPnpDriversPath

OEMPnpDriversPath populates the Device Path Key but has the limit of 4kB

if you use devpath it populates the Device Path Key directly into the registry.... Problem solved. No need to mov folders around and all that other horse sh*t.

I did not ask you to reprovide the same info... just to fill in the gaps. My dismay was cause by the fact that i had to wait till your third post and the fifth post of the thread (four days later) for the info we request in your first post. That ship sailed.

Now five days later i have sufficient info to help you.

DriverPacks BASE copies proxy info from IE... If IE can get to the net then so should DriverPacks BASE. It will use the proxy data copied from IE.
Per your policy this would not be allowed but Should work... Please test to make sure IE can get to DriverPacks.net if so then BASE should ge able to get its list of updates (and presumably not hang).

I have clients with proxy, and my personal setup uses ISA server, this is a known working configuration.

Let me know if you can get to DriverPacks.net from IE on the machine in question. This will identify the specific issue with the machine and / or the BASE issue with your proxy. A better statement is, help me to know more precisely how i go about duplicating the issue.

more info:
On proxy support topics.
http://forum.driverpacks.net/viewtopic. … 225#p17225
http://forum.driverpacks.net/viewtopic. … 224#p17224
http://forum.driverpacks.net/viewtopic.php?id=2585

On syntax for manualy adding proxy values
http://forum.driverpacks.net/viewtopic.php?id=2332
----snip
>>new command line switch by request  /proxy

>>Usage /proxy:"LocalProxy:Port"[,"Username","Password"]
>>examples
>>DPs_BASE.exe /proxy:"192.168.1.1:8080"
>>DPs_BASE.exe /proxy:"LocalProxy:8080","administrator","password"
----snip

So it is possable to let BASE access through a proxy even if IE (and other net apps) is disallowed.
Again your situation is not new or unique and has been integrated from the begining (2003), Bug reported, addressed, tested, debugged and retested by many people for many years. Our main user base is the IT professional. You are not the only one of our hundreds of millions of users who secures a network.

That is why details are important... I must ask myself "what is unique to your setup that thousands of other users in your same situation are not affected by?"

I'll play with a scenario where DNS resolves but Proxy fails... and see where i land, with a little luck I can duplicate your 6 minute freeze. Once i can duplicate the problem then i can fix the problem... since i am 98% done with the next release I would like to included it, and credit you for reporting it. If i can duplicate /find it of course. [thinking out loud] What results on your network take BASE into a 6 minute routine to finnaly fail? Failure usually takes around ten seconds. For a while i had a Cancel / Abort button on that page... perhaps i should put it back for edge cases like this....

Thanks for your persistence in this matter.

PS No it doesn't sound odd... For corp. security it's quite common. Most of our team works in similar environments around the world. I am used to much higher security levels. Two of my previous employers were required to meet Fed Gov level security. I have seen setups that you would not even belive me if i described them to you... Even one setup that had the engineers from cisco call us in to show them how to access it... All of their back doors were failing and they were totally locked out... and they were local to the equiptment (in the room with it).

What is the value of HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion on your reference machine? (IE before sysprep)

Note: if this path is valid then you need not worry about "The OEMPnpDriversPath value in the Sysprep.inf file limit of 2047 characters. . Just completely forget about it... Skip that entirely. That is the point we are making... Just because you got lucky does not mean you will continue to get lucky .  Use tried and proven methods. Especially the ones recomended by MS. OK? 

So your deployment is not broken the way microsoft says it should be... LOL so what are you saying micosoft can't even get a BUG right? LOL Too Funny!!!

Simply Populate that registry entry with the data that you were previously populating OEMPnpDriversPath with. Know in your mind by doing it this way you will never have to fight this issue .

NOTE:
If you followed the directions above you already have the correct entries int the Device Path Key and don't need OEMPnpDriversPath (this would explain why it worked for you )
>> 3. Extract DevPath.exe from DPBase\bin\wnt5_x86-32\M2.7z and run DevPath.exe C:\D
That command populates the Device Path Key and does not suffer the shorcomings of OEMPnpDriversPath.
Again if you did that then that would explain why your setup worked, and it is not because you used OEMPnpDriversPath.

Note HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion  also has a limit. It is much larger, but all things have limits. the limit of a single registry entry is in the neighborhood of 1 megabyte. We have hit this limit with DriverPacks before. certan goofballs have attempted to include ALL of the DriverPacks including the 3rd party DriverPack useing a method called KTD. They did this because they did not understand what KTD did or how it worked. It would not have done what they had hoped it would. But we did discover that if you exceed the 1MB or so limt you just might end up with a blank registry entry, not even %SystemRoot%\INF remained. (quite funny)

Reminder... the DevicePath value is a different limit than the one I refered to regarding mass storage drivers. Textmode Mass storage drivers are cached in RAM and have a pre-specified allocation size. This is true for Textmode and PE stages of setup (PE uses TextMode drivers for mass storage) when you deploy there is a PE stage environment.   

DPInst.exe will not change the path... not by itself.
Were you calling dpinst with a script... Like my SAD script? (or other)
When you ran SAD (AKA DP_Install_Tool.cmd) what packs were included?

Did you provide the logs in the other thread ... checking now.

Jeff

Agian... it was not until you mentioned that fact that the machine you run BASE on does not have internet access that you provided any useful info (third post) and whch version of BASE you were useing (second post).

I get LOTS of feedback when there is an issue...
No feedback means no issues. I said that.
It does not mean the couple of hundred boys deploying to thousands of machines are lazy or not testing. They simply only report if something goes wrong.

However useing BASE on a machine with no internet would put you in a VERY small percentage of our 100+ active member tester group.

Now that i can "reproduce your issue" (something i expect that i would be able to do after your first post. "Read BEFORE you post" item #6). I will test, identify and address the issue.

I'll let you know how it shakes out.

then include setupapi.log and DPsFnshr.log and DPs_BASE.log and HWIDs... then all will be revealed.
(IE follow rule #0)

The timeout for a failed network connections is and has been for some time written in the code.
http://forum.driverpacks.net/viewtopic.php?id=3998
The related posts testing and feedback are in the hidden testing team forum.
 

You FAILED to mention the affected machine had no internet connecton in your first post and di not include your BASE version in the title... (sorry my fault entirely) Please see: "Read BEFORE you post" linked in my signature and was linked in the rules you agreed to when you signed up. AKA Rule #0.

Sorry i have only been doing computer related stuff since 1968...
i didn't realize that i had finally found somone with more experience than me... I must aplogize since I personally have only been into computers for a little over 40 years and started with machine language and assembler, and have only recently gotten my BCS um... 30 years ago.

I'll do a few tests on an isolated machine and report back... I have not retested this since the CDN delivery was cut... I will do so now.
Thanks for letting us know. (finaly with enough details to duplicate the issue)

Based on the fact that you cannot properly detail and issue I don't need you on the testing team (beta access).
IE
Ommission of KEY details,
failure to read directions,
displaying a lack of respect,
continuing to fail to show appreciation for our project.
In other words yeah you appear to me to be a complete noob.
please see the definition of noob in our rules http://forum.driverpacks.net/misc.php?action=rules "Posting Guidelines"