Guide For Compressed Drivers Unattended Install

[evilvoice]

have you thought about testing if adding the files to dosnet.inf would work...one way to test it to maybe open a batch that pauses the main window, but first opens another cmd window so you can do some tests...the first test would be to run drvz.exe and see what happens...as I dunno if anyone has actually done some error checking at t-39, this would be a way...you could also run regedit and see if the reg keys are in fact being put in the registry...its hard to tell anything after the install has already taken place...and also, if you dont test at t-39 and wait until t-13 it would still cause problems, cause does anyone know for a fact that setup doesnt overwrite the driver reg keys? But this is what I would do to test...

1. add files to dosnet.inf

2. create a cmd file.

@ECHO OFF
start cmd
pause

3. then alt+tab to the one not paused

4. run drvz.exe and see if you get any errors, if not proceed...if yes, write them down

5. proceeding

6. goto location the drivers are supposed to uncompress to...check and see if anything exists...are files being uncompressed here (should be...cant really mess up an extract command)

7. check locations and make sure they are in the correct subfolders

8. run regedit

9. check HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath and see if anything exists in this key

10. check the unsigned driver policy key (dunno where its at, but honestly, if you have your winnt.sif to ignore the policy, you shouldnt have to check this key.

If anyone has done all these steps and verified that it doesnt work, could you post back at what step it failed at (1-10) so maybe serialzs can fix this...I know its asking a lot, but I really dont want to have to run drvz.exe to get reg locations to update the hive.inf file everytime I add a driver/driverpack...but if this truly is the only way, then I guess we are stuck with it...

[keul]

@evilvoice:

These steps have already been done an incredibly number of times by turbomcp and myself and we posted our results a few pages above.

Drvz.exe works :

1- *.7z files are unpacked

2- DevicePath is updated in registry before Windows starts Device Detection

However, when performing device detection, windows doesn't care about the new value of DevicePath. If you edit a vmware snapshot (RAM content) with an hex editor you can easily see that the old value in registry is not updated there (in memory) although it is really updated in \windows\system32\config\software.

So does anyone know a soft to find and replace a value in memory, as this is IMO the only way to get this method working ?

[|00|]

great job serialzs !

But

Bandwidth quota has been exceeded

can't download guide4driver.cab, any other link ?

thank your for your help

|00|

[evilvoice]

@keul...nowhere did I see anyone say that they stopped t-39 from continuing and see what happens at that point...but you say you have, so thats all I wanted to know.

[idle.newbie]

XP setup will not stop @T-39, but you can make it pause for a while. With OemPreinstall=Yes, OemSkipWelcome=0, setup will pause @T-39 before hardware detection.

DetachedProgram = "system32\cmd.exe"
Arguments = "/K START /WAIT PAUSE"

Entries above will make a new cmd window and pause.

Drvz.exe just extract driver sfx @T-39 then call SetDevicePath.exe, big_qie's MT39 is a better solution, Bilou_Gateux tried that for weeks, it's not working without a proper OemPnPDriversPath.

[Thauzar]

I did not take the time to read through all that other post idle.newbie posted but I can't understant a thing in xml and this looks so much more complicated. I hope serialz get the drvz.exe working soon. There must be helpful hints for him on that topic but for a normal user like me, OemPnpDriversPath looks easier to do than any .xml file.

[idle.newbie]

[GuiUnattended]
DetachedProgram = ".\system32\cmd.exe"
Arguments = "/Q /C FOR /F %I IN (%SystemRoot%\system32\$winnt$.inf) DO (FOR %J IN (%I$OEM$\DRV\*.exe) DO (IF EXIST %J (%J -y -o%SystemDrive%\DRV)))"

Entries above extracts every 7zip sfx inside $OEM$\DRV into %SystemDrive%\DRV. No need to modify txtsetup.sif/dosnet.inf, no driver copy @textmode setup, even with OemPreinstall=No, it finds your cd source from $winnt$.inf.

Just edit your OemPnPDriverPath(may do that with my another script), compress all your driver into 7zip sfx, and move it to $OEM$\DRV, that's all.

[Bâshrat the Sneaky]

[GuiUnattended]
DetachedProgram = ".\system32\cmd.exe"
Arguments = "/Q /C FOR /F %I IN (%SystemRoot%\system32\$winnt$.inf) DO (FOR %J IN (%I$OEM$\DRV\*.exe) DO (IF EXIST %J (%J -y -o%SystemDrive%\DRV)))"

Entries above extracts every 7zip sfx inside $OEM$\DRV into %SystemDrive%\DRV. No need to modify txtsetup.sif/dosnet.inf, no driver copy @textmode setup, even with OemPreinstall=No, it finds your cd source from $winnt$.inf.

Just edit your OemPnPDriverPath(may do that with my another script), compress all your driver into 7zip sfx, and move it to $OEM$\DRV, that's all.

One of the main advantages of this program, is ('would be' might be better?) that you don't have to enter the OemPnPDriversPath...

OK, admitted this is very handy when you don't mind using it, but still...

I hope Serialzs gets it to work soon....

[idle.newbie]

I know it's really convenient to omit lengthy OemPnPDriversPath, but sticking on DevicePath regTweak @T-39 is not a good idea, even $winnt$.inf modification @T-39 can't make xp setup to find those drivers. I hope big_qie or Bilou_Gateux can find another approach to overcome this T-39 mist.

By now the only solution to omit OemPnPDriverPath is Pyron's method, using hacked setup.exe to run another .cmd script, and do his regTweak before gui setup.

Or edit our OemPnPDriversPath, then use big_qie's MT39 to extract drivers @T-39.

[Nologic]

Okay silly idea...but hear me out...even tho I'm probably talking out of my a**.

Now I'm not sure what Pyron's method searchs for to build the paths for OemPnPDriversPath, I'm guessing *.inf ...

Any ways would it be possible to create a app that could scan an archive (7zip, zip, rar,...) for directory paths to the needed files contained in the archive. Then take that information and rebuild those paths correctly in OEM but...the folders are all empty execpt for a single dumby ASCII file "driver.dir" that holds nothing...its just some thing to scan for with Pyron's method to build the driver paths.

Any one follow what I'm suggesting?

Basically its just a false directory path and files to sit on the CD taking little to no room up...that will be copied to the HDD, and scanned to create path data, then later filled with the actual drivers from a archive.

Well the idea is out there...maybe some thing will come of it one way or another.

[Metzen]

I know it's really convenient to omit lengthy OemPnPDriversPath, but sticking on DevicePath regTweak @T-39 is not a good idea, even $winnt$.inf modification @T-39 can't make xp setup to find those drivers. I hope big_qie or Bilou_Gateux can find another approach to overcome this T-39 mist.

By now the only solution to omit OemPnPDriverPath is Pyron's method, using hacked setup.exe to run another .cmd script, and do his regTweak before gui setup.

Or edit our OemPnPDriversPath, then use big_qie's MT39 to extract drivers @T-39.

Is it possible to add registry entries during textmode setup that are carried over to GUI mode setup?

I've edited the HIVE*.INF files before with success for adding registry keys to setup (using this method among others), do they carry over to regular Windows setup?

[Pyron]

@Nologic:

SetDevicePath.exe works much simpler, it just scans for directories. It is up to Windows to find drivers there later.

--

Pyron

[Nologic]

Hehe yeah that is much simpler...so then Bâshrat should only need to package a fake directory path with his driver packs, to be extracted into the OEM folder...and the have the drivers archives deployed with DetachedProgram or big_gie's method...and then just use your method for directory discovery.

Seems simple enough.

[evilvoice]

why couldnt we combine the methods of pyrons "drivers from cd" and this thread and figure out some method to fix this...using pyrons setup.exe, it loads presetup.cmd, which we can run drvz.exe form this (start /wait command prolly needed), and then use the rest of serialzs method...like having devicepath.exe instead of setdevicepath.exe from pyron...7za.exe...seriously, I think if someone wanted to, they could combine the 2 methods and get the "guide for compressed drivers" working...

[Pyron]

As I said before, adapting my original guide for compressed drivers is just one additional line in presetup.cmd (uncompressing the drivers to harddisk), so using Drvz.exe there additionally would hardly be worth the effort.

--

Pyron