It has a function internaly that writes the path... apparently devpath is a retired file.

perhaps KTD needs to be updated to eliminate dopnf and have DP_Inst_Tool added... sounds like a feature request if you ask me.
If dopnf was eliminated then mute would also no longer be neccessary...

devpath %ktd%   = devicepath set to C:\Windows\Driverpacks\D\driverfolders;
devpath "%ktd%" = devicepath set to C:\windows\devpath\D\C\driverfolders;
devpath c:\windows\driverpacks\D = devicepath set to C:\Windows\Driverpacks\D\driverfolders;
devpath "c:\windows\driverpacks\D" = devicepath set to C:\windows\devpath\D\C\driverfolders;
devpath = devicepath set to C:\windows\devpath\D\C\driverfolders

It looks to me like devpath with no path specified scans from the exe location down the tree, and including quotes around the path causes it to ignore the path entirely. Quoting a full path gets ignored, it's not just when quoting the variable. But DPsFnshr pulls it off when KTD is enabled for M2, so it must just be a syntax issue. Any other suggestions?

edit: I've also tried '%ktd%' and 'c:\windows\driverpacks\D', same ignore path result.

Aaaah the old demon RUM... and sleep deprivation, that would make a difference .
No harm no foul! - Clean slate awarded

Keep us in the loop on your progress!

Have a great day & best of luck!

When you first suggested it, I tried the M1 SAD from the local disc. It ran, then deleted the drivers. But it was because my script was calling the cmd from the cd drive - still loaded with the XP disc/OEMfolder rather than the local folder, which resulted in the cmd picking up method 2. (which caused it to delete) Once I ran it from the HDD folder, it worked perfectly. And now that I look at the differences, you are absolutely right about this being the better method.

I wasn't imagining the "more than 3 character pathname" problem with devpath, but I was wrong about the cause. I'm using all of the official packs, most of the 3rd party packs, as well as one of my own. 1,353 folders in all. (sidenote, despite being selected, and in the 3rd party driver pack folder, running dpbase for M1 SAD ignores them, they don't get cab compressed or copied at all. I haven't looked into the reason yet, I'm probably just missing a setting) In the mean time I've just been extracting them to the output folder as is. I didn't test beyond the variation on the root folder name, devpath C:\DRV\D worked (errorlevel 0), but Devpath C:\Windows\Driverpacks\D did not. (errorlevel -1073741819) Devpath would run, but it wouldn't write the reg entry. I added this result and the format for the driverpack folders and arrived at the wrong conclusion. Turns out its not the length of the path, it's the length of the reg entry. (I think anyway) I can run devpath on any of the subfolders of D, for example devpath C:\windows\driverpacks\D\3. Or if I drop a few 3rd party packs, I can run on C:\Windows\Driverpacks\D. Just not when all of the drivers are there. And I think it's because there is enough room on the reg line for C:\(3 characters)\D\eachdriverfolder, but not for the extra 1353 characters added to the line for each extra character in the path.

You get around this in KTD by creating the %ktd% variable for the path, and having devpath write the reg entry using it. I've created %ktd% as a permanent system variable, but I'm not sure how to tell devpath to use the variable in it's output. devpath %ktd% doesn't seem to work, even when I strip down to just a single driverpack in the folder, it writes the line as the full path rather than using the variable.

Lastly, I didn't mean to offend with the .3/.4 comments. Looking at the files, it does look like a different version of AutoIT was used, and I too have seen that cause odd results with identical code. I was basing off the file creation/modified/version/size of the exe's within the 7z of each version, and the fact that the run results were so different.

I can not explain why the issue appears in 8.12.3 and not 8.12.4
- the source files that were compiled are bit for bit identical... The SVN server we use can attest to that, all changes are logged.
   the possability exists that the version of Autoit that I used to compile them was different...
     and I admit I have seen Autoit make changes in the compiler that surfaced in the object code before.
       Saying I snuck a quick fix in there without documenting it is taking a personal shot at me   understand... OK?

I already answered your question in my first reply and you did not read it - or you did not understand it.

from my first response - "the best thing to do is to create a SAD M1 folder and run DevPath.exe"

M1 does not use the 7zip archives it uses cabbed drivers - to save space - windows natively will work just fine with cabbed drivers. cabbing saves over a gig of HDD space verses the fully extracted drivers. if you really don't care then you can save the time of cabbing them and simply extract them. However I recomend you use Base to create a M1 folder structure with a small pack first (Say DriverPack CPU) to create the folder structure and extract the needed files. createing an example for you to use as a template . then you can simply extract the rest of the packs you desire into the \D\ folder.  please remember cabbing saves you over a gig of space if you do decide to use M1 be absolutely sure you enable QSC so you will not have to cab them a second time it caches the cabs - if as you say burning two gig of space is no issue then skip the cabbing OK. A M1 source will not be deleted by the finisher if it is called from the  DP_Install_Tool.cmd  (Hint Hint - look at the finisher INI after the tool is run ).
copy devpath to the path\driverpacks.net\ folder and run 'devpath path\driverpacks.net\D' this WILL populate the device path in the registry (ktd) however if you do not run the finisher many drivers will fail and things like the ATI control panel will not be installed.

I can't make it any easier than that - had you listened to me the first time it would have save us both grief...

PS in case it had not occured to you you can leave the SAD folder on the machine I recomend a network share but whatever...

PSS PLEASE take the TIME to use the SEARCH feature of our forum [IMP] Option to skip driver removal with DPsFnsher EVERYTHING you want to know is WELL documented here!~

As an alternate solution to my entire problem, is there a switch/ini file setting to tell finisher not to delete the extracted local driverpacks, but without going through all the functions (makepnf, devpath, etc) of KTD that cause issues? Even if I have to run a script to call dpsinst and the finisher each time a new device is connected, thats fine. But I'd like to avoid having to a.) use a separate disc for the driver source, or b.)re-extract the zips each time. Disc space isn't an issue.

these functions are documented on this site too... yes the wiki is gone but it did not have the wealth of knowledge that is contained in the posts here at DriverPacks. In fact the answers to all your questions are already answered here in detail. In posts you did not take the time to read. much as you did not take the time to actually read the changelogs for DriverPacks BASE which states clearly that only languages were updated. We are not here to hold your hand nor are we obligated to educate you.

DriverPacks has always had a no noobs policy you are no exception and you are in fact the type of user that reinforces that policy.

no contempt involved I merely observed... You're the one who posted the stupidity, I just narrated.
in fact i tried to offer you help. you ignored the advise and told me I was mistaken about devpath. (i did not make a mistake)

here is the place for noobs http://unattended.msfn.org/unattended.x … 29194ea61/

It is pretty arrogant of you to think you can do a better job than we can after we have been doing this everyday for 6 years.

have a nice day.

PS and you did not follow up with a report of success or offer helmi a thank you the last time you went of half cocked making false assumtions failing to do good research and basicaly needing us to cure problems you chose to create and were totaly unable to understand...  http://forum.driverpacks.net/viewtopic.php?id=3046

don't change presetup.

the finisher finishes installing drivers. not all drivers can be installed simply by pointing hardware at the inf.
In fact some hardware will not function at all if it's setup program does not run.
that is the PRIMARY function of the finisher.
Deleting the files and cleaning up is 1% of what the finisher does.
the finisher is a crucial part of DriverPacks and is why it is included in SAD and is ANOTHER reason KTD fails since KTD can not call the finisher.
I have tried to explain to you that KTD is a looser but, You can lead a horse to water... in this case SAD, but you can't make it drink. (your not listening) The fact that you were not able to find out what the finisher does on your own tells me this is way beyond your current level of experience. plus you were able to get different results with base 8.12.3 and 8.12.4 which are identical. this means you can not limit your changes in testing to a single variable. Furthermore devpath does not have a 3 character limit. It is obvious you just do not have enough experience with DriverPacks, and basic testing in general, to go off on your own. Please don't. This is way beyond your level of experience. Just use SAD when you install new hardware. problem solved.

But is that it? Because if so.....
Run DBbase, including all driverpacks and txt mode drivers. Set for M2, with DPsFnshr set for custom run mode. Modify presetup.cmd, changing the extract to /copy to folders from %systemdrive%\ to %systemdrive%\DRV\ , changing to devpath %systemdrive%\DRV\D , and start dspdsblr from %systemdrive%\DRV\.
If I'm understanding the entire process right, that should use the pre-setup to extract the drivers to where I want them to end up, and set the devicepath reg entry for that location. No need to run DPsFnshr at all, as the drivers are already in the target location, devicepath reg is set. Windows should just look in the folder anytime a new device is connected, right?

But I have to be missing something. I've looked over the dp_install_tool.cmd file, and it looks like for whichever method (m1 or m2) it runs DPSINST.exe on the resulting driverpacks folder, to search for any updated drivers. That much makes sense, but then why does it run DPsFnshr? What does it do other than deleting the extracted files? (when not using KTD that is)