[Testing install on vmware....]

Inside your Vmware install directory, you should find a file called windows.iso. Open it (either by mounting it or with winrar) and go in "program files\VMWare\VmWare Tools\Drivers".

All you need is to put those drivers in your unattended cd. If everything went ok, windows should find them and you shouldn't have "unknown devices" in "device manager".

[Guide For Compressed Drivers Unattended Install]

Thanks serialzs for the updated file. I don't have much time today to test but I'll try. However, regarding our last conclusions about devicepath changed too late during gui setup, I doubt it'll work better than "hybrid method"® . As there was a problem with your last drvz.exe, I used a presetup.cmd file instead, which basically did the same things than drvz.exe, but have had no luck with it either...

As turbomcp suggested it, I tested modifying HIVESFT.INF (adding full devicepath) instead of using devpath.exe so that registry value of devicepath is modified before GUI, and it worked, which tend to confirm that whichever method we use (presetup.cmd, drvz.exe...), modifying devicepath after the GUI starts is too late.

I've also done research about my last theory (use devpath in GUI and then find a way to tell windows that registry has been changed so that it use the updated value of devicepath). I've found a message (WM_SETTINGCHANGE), that should notify windows of a change in the system. So I made a little app to broadcast this message to every foreground window and just launched it after devpath in my presetup.cmd. But although the return value is ok (which tells us that the message as been sent), one more time, changes in devicepath are not used. So maybe windows just doesn't listen to this message during setup...

[Guide For Compressed Drivers Unattended Install]

@serialzs : I don't want to bother anyone with repeating myself but here are the facts (short version this time )

I insist on the fact that the details below are the results of tests done on my computer only (on my current windows / in real enviromnent unattend bootcd / vmware bootcd) (tests done on winxppro french sp1 final and sp2 final) and I don't want to talk for anybody else, maybe it's just me...

- Your new files don't work at all (no driverz folder created, no files copied or even unpacked). I think there is definetly a difference between the autoit script of both drvz.exe version (apart from the call to 7z.exe changed to 7za.exe)

- Your old drvz.exe with 7za.exe renamed to 7z.exe WORKS (I mean, files are copied, unpacked and any directory under c:\driverz is added in devicepath when gui setup is started). BUT the drivers don't get installed (in both enviromnents-real/vmware).

- Yes, the same drivers, unpacked the same way in the same folder but with oempnpdriverpath work.

- as turbomcp just wrote it, it seems that my theory is confirmed and that devicepath is read before t-39

@turbomcp: great news! This is not what we were hoping for, but now we do know why it's not working as expected...

@all:

So what we have to do now, as turbomcp said is adding entries before the gui starts...

Unfortunately, I don't know any way (value in winnt.sif...) to run files before Gui starts. So I see only 3 solutions :

1- use no-dynamic devicepath (oemphpdriverpath or HIVESFT.INF), and that is NOT what we want (in that case, we won't be here)

2- use pyron's method which involves using a false setup.exe doing our stuff (unpack, devpath...) and then launching real setup

3- use the method described in this post (with serialzs's drvz.exe or turbomcp's cmd file) and after the call to DevPath.exe make windows gui setup RELOAD information about devicepath from registry. I am not an expert in registry but I think that there might be a way to make windows refresh values that get written...

Well I'm gonna do some research on thrid point and keep you informed.

[Guide For Compressed Drivers Unattended Install]

Here are the results of my last tests :

As turbomcp said, I looked at DevicePath just before Device detection but it was ok. So I tested his hipothesis (setting %SystemDrive%\ instead of C:\ in devicepath).

So here's what I did :

1. Launched drvz.exe on my current system.

2. exported Devicepath from registry (which gave me the exact same thing as in my previous vmware tests).

3. replaced every C:\ with %SystemDrive%

4. Saved this file in CDRoot\%oem%\%1\test.reg

5. removed DevPath.exe from i386 so that it doesn't interfere with my tests

6. After that I ran Unattend Cd in vmware

7. As soon as Gui setup started, I ran a dos command line "start c:\test.reg" which asked me if I was ok to import value in registry (of course, I was )

Then I verified in registry that reg file was imported (during this time, *.7z files were unpacking thanks to drvz.exe).

But one more time, no driver was installed.

* So this confirms that C:\ and %SystemDrive% have the same effect.

* As I did this only a few seconds after Gui start, I assume that our problem is not related to the fact that devpath.exe is ran a few seconds too late.

@pyron : After reading your method again (the one with presetup.cmd), I see a major difference with this one : you're importing registry settings BEFORE launching setup gui. So what I think is that when launching setup gui, windows loads registry (or at least devicepath value) in memory and then searches in memory for devicepath. So changing this value after setup gui is started may be too late. That's why oempnpdriverspath is working and not devpath (its value is imported before). However, I will test the solution you're giving us (who knows, I may be wrong), tomorrow (well, in 8 or 9 hours).

[Guide For Compressed Drivers Unattended Install]

@Lucius Snow : Here are the old files you asked for, let's hope you will find something interesting...

@turbomcp : great work ! Basically, all you did is replace serialzs's drvz.exe with a batch file . But that was really usefull as we now know (as far as your method isn't working in real environment too) that the problem lies elsewhere than in drvz.exe.

It means that either windows doesn't care about devicepath during install (which is hardly believable since big_gie's / pyron's methods are based on that) or that the registry write is done AFTER device detection...

[Guide For Compressed Drivers Unattended Install]

Oops, just a typo, it's really cmdlines.txt on my cd.

Post edited.

[driver.cab and sp2.cab ?]

You can use jdeboeck's batches to merge driver CABs.

1. Go here

2. Download the file and unzip it

3. You need only 2 files : "Drivers! Before You begin.cmd" and "Drivers! Finishing Off.cmd".

4. Edit them and replace every SP1 reference to SP2

5. Copy them in your Cd root folder

6. Launch them (I let you guess in which order)

7. [optional] Go here and learn how to use the search feature

8. Et voila !

[Guide For Compressed Drivers Unattended Install]

@serialzs:

here is my folder structure :

ROOT
   .$OEM$             (containing cmdlines.txt, registry.inf, apps.inf...)
   ...$1
   .....Apps
   .......Winamp
   .......Winrar
   .......Winzip
   .......[...]
   .....Patch          (empty)
   ...$$
   .....system32     (containing directx.cpl, and oemlogo*.* ...)
   ...Driverz          (containing chipset.7z, sound.7z, video.7z.....)
   .I386                (containing 7za.ex_, devpath.ex_, drvz.ex_)
   ...system32
   ...drw
   .....1033
   .....1036
   ...compdata
   ...asms
   .....1
   .....2
   .....10
   .....[...]
   .Support
   ...Tools
   .ValueAdd
   .Xtra

I tried your new files on my system with everything you said (files copied in system32, drivers burned...) with the same results as in vmware and real environment installation : no error message, but no folder Driverz is created in C:\. But I noticed one thing that might be interesting : my device path (which originally was only "%SystemRoot%\Inf") was transformed in this after launching drvz.exe :

%SystemRoot%\Inf;C:\WINDOWS\System32\1025;C:\WINDOWS\System32\1028;C:\WINDOWS\System32\1031;C:\WINDOWS\System32\1033;C:\WINDOWS\System32\1036;C:\WINDOWS\System32\1037;C:\WINDOWS\System32\1041;C:\WINDOWS\System32\1042;C:\WINDOWS\System32\1054;C:\WINDOWS\System32\2052;C:\WINDOWS\System32\3076;C:\WINDOWS\System32\3com_dmi;C:\WINDOWS\System32\appmgmt\MACHINE;C:\WINDOWS\System32\appmgmt\S-1-5-21-1482476501-1078081533-682003330-500;C:\WINDOWS\System32\appmgmt;C:\WINDOWS\System32\CatRoot\{127D0A1D-4EF2-11D1-8608-00C04FC295EE};C:\WINDOWS\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\TempDir;C:\WINDOWS\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE};C:\WINDOWS\System32\CatRoot;C:\WINDOWS\System32\CatRoot2\{127D0A1D-4EF2-11D1-8608-00C04FC295EE};C:\WINDOWS\System32\CatRoot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE};C:\WINDOWS\System32\CatRoot2;C:\WINDOWS\System32\Com;C:\WINDOWS\System32\config\systemprofile\Application Data\Microsoft\Internet Explorer;C:\WINDOWS\System32\config\systemprofile\Application Data\Microsoft\SystemCertificates\My\Certificates;C:\WINDOWS\System32\config\systemprofile\Application Data\Microsoft\SystemCertificates\My\CRLs;C:\WINDOWS\System32\config\systemprofile\Application Data\Microsoft\SystemCertificates\My\CTLs;C:\WINDOWS\System32\config\systemprofile\Application Data\Microsoft\SystemCertificates\My;C:\WINDOWS\System32\config\systemprofile\Application Data\Microsoft\SystemCertificates;C:\WINDOWS\System32\config\systemprofile\Application Data\Microsoft;C:\WINDOWS\System32\config\systemprofile\Application Data [B][... ok I stop here, there's no use to paste everything : it's every system32 subfolders[/B]]

The same thing happens when I install in vmware or real environment with your new files...

Now, using my "famous" hybrid method (old drvz.exe and 7za.exe renamed to 7z.exe), everything is fine :

Folder strucure of C:\Driverz:

31/08/2004  09:36    <REP>          chipset
31/08/2004  09:37    <REP>          lan
31/08/2004  09:37    <REP>          modem
31/08/2004  09:37    <REP>          monitor
31/08/2004  09:37    <REP>          sound
31/08/2004  09:37    <REP>          video
31/08/2004  09:37    <REP>          vmware
 R‚pertoire de C:\Driverz\chipset
31/08/2004  09:36    <REP>          chipset
 R‚pertoire de C:\Driverz\chipset\chipset
31/08/2004  09:36    <REP>          nF
31/08/2004  09:37    <REP>          SiS
31/08/2004  09:37    <REP>          VIA-k7
 R‚pertoire de C:\Driverz\chipset\chipset\nF
31/08/2004  09:36    <REP>          IDE
31/08/2004  09:36    <REP>          IO
 R‚pertoire de C:\Driverz\chipset\chipset\nF\IDE
31/08/2004  09:36    <REP>          ITB
 R‚pertoire de C:\Driverz\chipset\chipset\nF\IDE\ITB
 R‚pertoire de C:\Driverz\chipset\chipset\nF\IO
 R‚pertoire de C:\Driverz\chipset\chipset\SiS
 R‚pertoire de C:\Driverz\chipset\chipset\VIA-k7
 R‚pertoire de C:\Driverz\lan
31/08/2004  09:37    <REP>          lan
 R‚pertoire de C:\Driverz\lan\lan
31/08/2004  09:37    <REP>          3C
31/08/2004  09:37    <REP>          BR
31/08/2004  09:37    <REP>          BU
31/08/2004  09:37    <REP>          D
31/08/2004  09:37    <REP>          I
31/08/2004  09:37    <REP>          L
31/08/2004  09:37    <REP>          LI
31/08/2004  09:37    <REP>          M
31/08/2004  09:37    <REP>          N
31/08/2004  09:37    <REP>          NV
31/08/2004  09:37    <REP>          O
31/08/2004  09:37    <REP>          R
31/08/2004  09:37    <REP>          S
31/08/2004  09:37    <REP>          V
 R‚pertoire de C:\Driverz\lan\lan\3C
31/08/2004  09:37    <REP>          1
31/08/2004  09:37    <REP>          2
 R‚pertoire de C:\Driverz\lan\lan\3C\1
[...]

And DevicePath :

%SystemRoot%\Inf;C:\Driverz\chipset\chipset\nF\IDE\ITB;C:\Driverz\chipset\chipset\nF\IDE;
C:\Driverz\chipset\chipset\nF\IO;C:\Driverz\chipset\chipset\nF;
C:\Driverz\chipset\chipset\SiS;C:\Driverz\chipset\chipset\VIA-k7;
C:\Driverz\chipset\chipset;C:\Driverz\chipset;C:\Driverz\lan\lan\3C\1;
C:\Driverz\lan\lan\3C\2;C:\Driverz\lan\lan\3C;C:\Driverz\lan\lan\BR\1;
C:\Driverz\lan\lan\BR\2;C:\Driverz\lan\lan\BR;C:\Driverz\lan\lan\BU\1;
C:\Driverz\lan\lan\BU\2;C:\Driverz\lan\lan\BU\3;C:\Driverz\lan\lan\BU;
C:\Driverz\lan\lan\D\1;C:\Driverz\lan\lan\D\500sx;C:\Driverz\lan\lan\D\500T;
C:\Driverz\lan\lan\D\530TX+;C:\Driverz\lan\lan\D\550T;[...]

which is the same result I have in vmware or real environment with "hybrid" method.

So obviously, you did something else in your new script that just changing a call from 7z.exe to 7za.exe, otherwise, it would have given the same results, right ?

What else can I say ?

- Although unpacking driverz and setting devicepath correctly, hybrid method doesn't help installing drivers during setup

- Hybrid method works however when clicking "update drivers" in device manager once windows is installed

- oempnpdriverspath method works ok with those drivers during setup

- Yesterday, I tried installing windows in vmware someting like 10 times (only sp1, adding "UpdateInstalledDrivers=Yes" in winnt.sif, adding "OEMPnPSigningPolicy=ignore" in winnt.sif, putting only vmware.7z file in driverz in case of a bad inf file bugging the whole thing, formating in fat32, in ntfs [who knows ?]...) but with no luck.

So it seems that there are 2 separated problems :

1- New files (with 7za.exe) not working at all on some (all?) systems.

2- The whole method which seems to work regarding to unpack files and modifying registry during setup but doesn't help to install drivers (may be setup doesn't wait for your script to end up at t-39 before detecting devices, may be registry is cached so modification are not applied immediatly...).

What else can I do to help finding what's going wrong ? I tried reversing your autoit script but it seems that you blocked decompilation so I couldn't do anything about it. Any idea before I get mad ?

[Guide For Compressed Drivers Unattended Install]

@Lucius Snow : I think you should be right. I'll keep fingers crossed for you.

@Thauzar : Thank you ! I'm not the only one to be cursed ! Try using old drvz.ex_ and 7za.ex_ renamed to 7z.ex_, (and of course, change txtsetup.sif), it worked for me (i mean, 7z files were unpacked, not installed). I think there is a problem with new drvz.exe, if serialzs is around ...

[Guide For Compressed Drivers Unattended Install]

Ok, I'm back after further tests in real pc environment.

I've got 2 news for you : a bad one, and a... bad one

The bad one is that serialzs updated method does not work at all (at least for me). I copied new files, and didn't forget to update txtsetup.sif. But this time, there was no C:\Drivers forder at all at the end of install (although the 3 files were in windows\system32).

After that, I tried the hybrid method I described a few posts above : renaming 7za.exe to 7z.exe and packing it (using old drvz.exe). Yesterday, with this method in vmware, I had *.7z files unpacked, good device path in registry, but none of them has been installed. I thought I was vmware's fault (my vmware.7z drivers didn't match vmware version.). After that, I tried updating vmware drivers on my unattend cd, but with no success : no drivers were installed during setup. BUT after setup when I clicked on "update drivers" in device manager, new drivers were automatically found in c:\drivers\vmware. .

Then, I blamed vmware one more time and decided to test in real environment but then again, the same thing appened : drivers are unpacked but not installed during setup (although, as in my vmware tests, "update drivers" is working great after setup).

To complete, I would say that I've got SP2 slipstreamed on a XP french version, and that old method (oemdriverspath + self extracting 7z) always worked for me.

So has anyone got this metod to work, or is this a kind of curse above my head ?

[Guide For Compressed Drivers Unattended Install]

I tested this method yesterday with no success. Actually, none of my .7z files were decompressed during install.

After some research in 7z help file, I came to the same conclusion as Bâshrat the Sneaky. So I renamed 7za.exe to 7z.exe, compressed it and replaced the old one in i386. And guess what ? Drivers are now decompressed. B)

Now, the only problem is that they didn't get installed in vmware , but I assume this is because my vmware.7z driver file is not the same version as the software I'm using...

I will test it in "real world" tonight and keep you informed tomorrow.