Jump to content

Drivers from CD: Simple Method


a06lp

Recommended Posts

What follows was the AutoIt Method:

I copied here from the first post, since we have now found a better way (see first post).

However, for backup sake, and for those who want to still use this method, here it is:

Drivers From CD (AutoIt Method)

Updated: 10/11/05

This is not my method. I merely tried out hp38guser's method, and outlined the steps.

Thanks also go out to Pyron for making SetupCopyOEMInf.exe, which is used in this method.

The info from this outline is from this post, and, more specifically: here, here, and here.

This is a method of automatically installing drivers (which are located on your CD), for devices that are plugged into the computer that WindowsXP is being installed on. This new way uses AutoIt. Why another way, you ask? The reason is simple:

This method does not need the use of a FAKE setup.exe, nor does it need extra lines in TXTSETUP.SIF (like other methods do). It's very simple and straightforward.

It's as easy as 1, 2, 3:

1. Download the attached zip file, and unzip its contents to $OEM$\.

(There are 4 files in the zip: AutoIt3.exe, Drivers.au3, SetupCopyOEMInf.exe, WatchDriverSigningPolicy.exe)

(These files will run from the CD, and are never even copied to the Hard Drive.)

2. Open up winnt.sif (located in i386), and add two lines under [GuiUnattended], as shown below:

Winnt.sif

[GuiUnattended]
DetachedProgram = ".\system32\cmd.exe"
Arguments="/Q /C FOR /F %I IN (%SystemRoot%\SYSTEM32\$WINNT$.INF) DO (FOR %J IN (%I$OEM$) DO (IF EXIST %J (start /min /D%J Autoit3.exe Drivers.au3)))"

(If you want more info on this coding, see this post.)

3. Place any drivers you want to have auto-detected into $OEM$\Drivers (you must create the directory).

Notes:

-= Plug'n Play devices are detected during Windows Setup after the DetachedProgram stage (which is when this script is run), so Windows Setup will detect and install all applicable drivers.

-= Any type of folder names can be used. (Don't worry about spaces in the folder names.) For example: "Wireless Card Drivers" will work just as well (even though there are spaces in the name) as "WiFi_Drivers". I've personally tested this method, and it works perfectly (I installed laptop OEM drivers, PCI card drivers, etc. - all without a problem).

-= Also, please note this method will not work for MassStorage Device drivers.

-= This method does not require any files to be copied over the the HDD - it runs totally from the CD.

If you are still confused, here is a sample XPCD layout (colors correspond to the steps above):

├───$OEM$

│.......├───Drivers

│................├───C-Media CMI8738 6.39

│................├───Medion SAA7134 2.3.1.0

│................├───Monitor

│.......................├───AL712

│................├───nVidia ForceWare 77.72

│................├───Samsung ML-1210

│................├───Laptop

│.......................├───Touchpad

│.......................├───Infared 12.6

│.......├───AutoIt3.exe

│.......├───Drivers.au3

│.......├───SetupCopyOEMInf.exe

│.......├───WatchDriverSigningPolicy.exe

├───I386

│.......├───winnt.sif

Updates:

08/01/05: Re-uploaded the zip file. The only updated file in the zip is the Drivers.au3 - it's a smaller file, with less coding (i.e., no extra crap, as per hp38guser's request (here). It has been tested, and is working.

10/11/05: New upload again. This time, the Drivers.au3 file is altered again, and the code to be entered into winnt.sif has been changed. This entire method runs from CD (no files copied over!) This is all from this post. Again- I personally tested this method (as has hp38guser) and it works!

Attachment Updated: 10/11/05

DriversAutoIt.zip

Edited by a06lp
Link to comment
Share on other sites


@idle.newbie:

Looks good (in theory), I'm going to test this later.

(Also, the code looks NICE ;))

[Edit]

@idle.newbie:

You said that SetupCopyOEMInf freezes when setup.exe suspended, because something with setupapi.dll has to be updated.

It appears you are right. A while ago, someone asked about the source for SetupCopyOEMInf, and the response was:

If you want to create your own utility it's a matter of scanning a directory structure for INF-Files and use the API call SetupCopyOEMInf (which is inside setupapi.dll) on every INF-File.

So at least we know why setup cannot be paused totally...

Not correct. I think that Windows launches Setup.exe as one process. Using some function from a dll to install a driver is still possible. Reason for Setup to freeze is because of some internal timer-function to detect if Setup fails or not. It has nothing to do with SetupCopyOEMInf.exe

Link to comment
Share on other sites

Not correct. I think that Windows launches Setup.exe as one process. Using some function from a dll to install a driver is still possible. Reason for Setup to freeze is because of some internal timer-function to detect if Setup fails or not. It has nothing to do with SetupCopyOEMInf.exe

Actually, Setup.exe is not freezing. It is simple waiting for instructions to resume.

it's SetupCopyOEMInf freezing, not setup.exe. 'cause SetupCopyOEMInf freeze, so the following psSuspend -r setup.exe not executed, which makes u feel setup.exe freeze.

currently i operate totally manual in command prompt @T-39. the setup.exe's been suspended, then WatchDriverSigningPolicy execute, and then SetupCopyOEMInf. the SetupCopyOEMInf freeze at some device inf, one of my laptop's modem driver. but, if i press Ctrl-C to terminate SetupCopyOEMInf, then execute it again, it works smoothly, nothing paused, everything's fine.

So you can see that the freezing of SetupCopyOEMInf was the problem. Again, the theory was that SetupCopyOEMInf froze since it could not use setupapi.dll (a file which is needed, as said by the creator of the script that led to SetupCopyOEMInf.exe).

In any case, I think we solved the problem. Check the first post for the new method.

Link to comment
Share on other sites

Hmm, I'll do some tests using Process Explorer to find out the problem.

EDIT

Meaby we cause an deadlock between SetupCopyOEMInf.exe and the suspended Setup.exe thread. Setup.exe has already opened a handle to the SetupCopyOEMINF API Call before it get's suspended.

However I found some useful information:

http://www.codeproject.com/threads/RmThread.asp:

rmthread -pSetupCopyOEMINf.exe -dSetupApi.dll -a" Drivers"

might just work for this specific situation. (Best option would be suspending all except the Setupapi.dll threads of Setup.exe so SetupCopyOEMINf coud process the inf's) :boring:

Very complicated stuff. Too bad I know almost nothing about handles, dll's, api calls etc.

Edited by hp38guser
Link to comment
Share on other sites

@hp38user:

the process/thread stuff you said in this page, that's what i thought, but i'm too poor to explain in English. :(

this ticker scripts' kinda hard coded time slicing.

i use NirCmd cmdwait first place, but it pops all immediately, as you said there's something wrong with some timer function. so i back to wait.

freeze is not cause by SetupCopyOEMInf nor setup.exe, only they deadlocked in some place in setupapi.dll.

that's my guess, may be wrong. needs some experts' idea.

@a06lp:

passed another test with huge sets of BtS driver pack Chipset+GraphicsA+Lan+SoundAB(extracted size about 680Mb in HD).

use NirCmd.exe exec hide Drivers.cmd in Arguments block if the script works. hides everything from poping up, save some cpu to repaint cmd window.

edit:

only test with disc made last year, done in command prompt by hand, scripts and BtS DP extraction. dunno what will happen when they're on cd.

you should also note that DO NOT use sourcePath with spaces when people make multiboot disc, can't handle it, Arguments did not allow quotes inside. use regular wording A-Za-z0-9_-..

+--XP Pro

¦.....+--$OEM$

¦.........+--Drivers

¦.............+---blah.blah

¦.....+--i386

¦.............+---winnt.sif

+--XPHome

¦.....+--$OEM$

¦.........+--Drivers

¦.............+---blah.blah

¦.....+--i386

¦.........+--winnt.sif

red=not allow, green=okay Edited by idle.newbie
Link to comment
Share on other sites

passed another test with huge sets of BtS driver pack Chipset+GraphicsA+Lan+SoundAB(extracted size about 680Mb in HD).

use NirCmd.exe exec hide Drivers.cmd in Arguments block if the script works. hides everything from poping up, save some cpu to repaint cmd window.

AWESOME!

Passing using BtS packs means we're working.

As for the NirCmd.exe exec hide Drivers.cmd - I'll leave it up to the user. The cmd window opens minimized for me anyway (minimized for you too?), so all I see is a tiny bar in the bottom left, which I WANT to see, so I know it's working.

Anyone with half a brain can look up what you just posted and use it themselves if they want that cmd window silenced. :whistle:

Great news on the BtS driver pack Chipset+GraphicsA+Lan+SoundAB working, though!! :thumbup:thumbup

[edit]

P.S. - Get yourself a f'n Burner already! LOL ;)

Edited by a06lp
Link to comment
Share on other sites

To HIDE IT

need edit winnt.sif to

[GuiUnattended]

DetachedProgram=".\system32\cmd.exe"

Arguments="/Q /C FOR /F %I IN (%SystemRoot%\SYSTEM32\$WINNT$.INF) DO (FOR %J IN (%I$OEM$) DO (IF EXIST %J (start /min /D%J NirCmd.exe exec hide Drivers.cmd)))"

like this?

i'll test the new method now...

guess what? it is working like champ now! :thumbup

to hide it... i may add

cmdow @ /HID

in the cmd file as well right?

i have cmdow.exe in $OEM$\$$\System32 as well

Edited by cyberloner
Link to comment
Share on other sites

[GuiUnattended]

DetachedProgram=".\system32\cmd.exe"

Arguments="/Q /C FOR /F %I IN (%SystemRoot%\SYSTEM32\$WINNT$.INF) DO (FOR %J IN (%I$OEM$) DO (IF EXIST %J (start /min /D%J NirCmd.exe exec hide Drivers.cmd)))"

...

it is working like champ now! :thumbup

to hide it... i may add

cmdow @ /HID

in the cmd file as well right?

i have cmdow.exe in $OEM$\$$\System32 as well

Glad to hear its working.

As for cmdow - yes, of course you can. But the point is that nircmd is already part of the driver method, so people have it already. it's a matter of preference if they want it hidden or not.

Link to comment
Share on other sites

-= However, DO NOT use spaces on a MultiBoot Disc - it won't work.
it only restrict spaces on SourcePath, anything elses under sourcepath are free.

CD:\XP Pro\i386\... will not work. replace space with _ underscore or - dash.

CD:\XP-Pro_A\i386\... no problem.

CD:\XP-Pro_A\$OEM$\Drivers\nVidia ForceWare 77.72\... no problem

anything using similar DetachedProgram/Arguments to get sourcepath from $winnt$.inf got this problem. no workaround yet. but this method did retrive correct sourcepath on multiboot cd from reliable source, on cd base installation.

edit:

nvm

Edited by idle.newbie
Link to comment
Share on other sites

Updated the guide to reflect all the minor changes in the past few threads:

:: Fixed MultiBoot info regarding spaces in sourcepath (not allowed) and driver names (allowed). [this post.]

:: Added DetachedProgram code for those who want to hide the cmd window. [this post.]

Everything should now be up-to-date. :P

Link to comment
Share on other sites

Updated the guide to reflect all the minor changes in the past few threads:

:: Fixed MultiBoot info regarding spaces in sourcepath (not allowed) and driver names (allowed). [this post.]

:: Added DetachedProgram code for those who want to hide the cmd window. [this post.]

Everything should now be up-to-date. :P

Just updated my UA disc & reformatted using the new pack no issues or hold ups at all, worked very well

Cheers Guys

MC.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...