Yes. It scans a given folder, and any subfolders, looking for inf files, then sets the device path registry line to reflect the locations.
Example line: %systemroot%\inf;C:\Drivers\G\N1;C:\Drivers\D\N5
1 2009-03-07 01:09:33
Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr (16 replies, posted in Feedback and Support - DriverPacks Base)
2 2009-03-05 00:06:16
Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr (16 replies, posted in Feedback and Support - DriverPacks Base)
Well that would explain why I couldn't get the syntax right! Thanks for checking into it.
3 2009-03-04 08:20:24
Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr (16 replies, posted in Feedback and Support - DriverPacks Base)
Tried the quotes, not having much luck. My test method:
Driverpacks are located at C:\Windows\Driverpacks\D\
- cut them back to just the official packs, to avoid any reg entry length issues.
%KTD% set to C:\Windows\Driverpacks\D
Devpath.exe moved to C:\Windows\DevPath\devpath.exe - to verify whether it's scanning down, or using the path provided
C:\Windows\DevPath\D\C - contains a copy of the chipset drivers.
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.
4 2009-03-04 03:38:36
Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr (16 replies, posted in Feedback and Support - DriverPacks Base)
Let me start with an apology. I had a show saturday night, a few drinks after, followed by getting called into work before I'd had a chance to sleep. More than 30 hours without sleep and wired on coffee when I started this project, I made some pretty stupid mistakes.
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.
5 2009-03-02 16:13:19
Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr (16 replies, posted in Feedback and Support - DriverPacks Base)
For the record, http://forum.driverpacks.net/viewtopic.php?id=3290 My exact issue with the 8.12.3 DPsFnshr.7z., which is not present in the 8.05 or 8.12.4 copies. (mind you I'm only swapping the 7z, not dpbase itself)
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.
6 2009-03-02 14:57:03
Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr (16 replies, posted in Feedback and Support - DriverPacks Base)
Functionality of the finisher WAS well documented, or so I hear. And I'm sure at some point so was devpath, and every other script app that dpbase uses. But the wiki site you've linked in several other posts is gone. If you have updated links, I'm happy to do some reading on my own. I'm sure it's less contemptuous than your reply.
7 2009-03-02 13:10:07
Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr (16 replies, posted in Feedback and Support - DriverPacks Base)
Thanks for the reply. I've spent the afternoon experimenting with your suggestion, which brings up a few more questions.
I don't see how DevPath.exe [path:\Driverpacks.net\D\] could work. The app itself seems to refuse path names with more than 3 characters per folder, which I assume is why your driver pack folder names are they way they are. The only solution I see would be to extract the driver packs to a permanent location of C:\DRV, which would result in C:\DRV\D\drivershere. In that setup, [devpath C:\DRV\D] should properly setup the devicepath reg entry.
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)
8 2009-03-02 04:32:07
Topic: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr (16 replies, posted in Feedback and Support - DriverPacks Base)
I am trying my best to troubleshoot this on my own, but I'm now at the end of what I can test, without knowing more about the exact process the apps go through. This post will probably get lengthy, I apologize in advance.
Until recently I was using a fully working (all be it outdated) build using base 8.05, masstorage txtmode integrated. But I needed the updated MassStorage drivers, so I began building a new install. The process: Fresh/Clean Windows XP SP3, copied to a new folder. Boogey's WMP11 integration, followed by nLite customization. I do not remove drivers or anything else, this is strictly for unattended, minor tweaks (remote desktop enable, changing default folderview settings, etc) and then integrating Xable's post-SP3 pack. I then run dpbase (using the latest driver packs), and burn the folder using IMGBurn. (using the XPboot image from nlite)
Initially I was working with base 8.12.3. In base, I use the M2/KTD All(default location) option, and GUIRunOnce for the finisher. I do however remove the DPsFnshr line from winnt.sif, so that I can manually run it from a software install script after windows loads. But I encountered the issue that after dpsfnshr.exe ran, the HKLM/Software/Windows/Current Version/DevicePath line only contains the KTD paths. Instead of showing"%systemroot%\Inf;%KTD%\blablabla", it starts with ";%KTD%\blabla". Obviously the issue here is that when a new device is connected, say a flash drive, windows doesn't search its own inf folder. Prior to running DPsFnshr, the devicepath line shows (mostly) correctly as %systemroot%\inf;C:\D\blablabla. I point this out because it makes me think something is running devpath prior to windows loading, then repeating the process with DPsFnshr runs.
I didn't discover the issue right away, and by the time I had, 8.12.4 was out. I found no reference to this bug in the base changelog, or any reference to version 8.12.3 at all. Which made me think it was something the creator discovered quickly, fixed, and released 8.12.4. So I went back to scratch, this time building with 8.12.4.
But now the problem is that when DPsFnshr.exe runs, it doesn't mute, and I see tons of driversigning popups. (they are closed automatically though) I found a couple threads that reference issues like this, the first of which said the problem was a double call of DPsFnshr. I've checked everywhere I can think of, and I'm not finding a second reference to it. So this is question one.....outside of presetup.cmd and winnt.sif, what files could be calling the process? Unfortunately the second thread I found was edited, removing the actual problem the op was trying to fix.
Skipping ahead through what has been a very long testing process, starting the entire process from scratch, using base 8.12.4 to build, and using VMWare 6.05 as my test machine, I have found the following:
I pulled the DPsFnshr.7z file from each of the base version I have. Changing NOTHING about the build, except dropping a different version of this file in the OEM/bin folder:
8.12.4 - no beeps during windows setup, but when DPsFnshr is run manually, mute doesn't work, hundreds of driver signing popups, devicepath line reads as it should.
8.12.3 - no beeps during windows setup, when DPsFnshr is run the system tray speaker icon does not show that it's muted, but I get no driver signing popups (per the disabler), registry entries are reset, but the devicepath line is missing the %systemroot%/inf start.
8.0.5 - no beeps during windows setup, no driver signing popups, (thus no need for mute) registry entries are reset, devicepath is correct, but video drivers don't install. (shows Unknown device - VGA adapter) I think this is because I'm using the latest graphics packs, which are likely not fully supported by 8.0.5.
I'll point out that even though I didn't get the driversigning popups with the older versions, the drivers were properly dumped in the KTD folder, at least as far as I can tell. (hooking up an HP printer, a scanner, and my Spyder after the fact properly pulled their drivers from the KTD folder)
In each copy of DPsFnshr.7z, the DPsFnshr.exe and DSPdsblr.exe files have a different version. They appear to be AutoIT scripts, but I haven't had any luck opening them as scripts. And thus I'm at a loss as to what to fix. If I understood what was going on, I might have more luck. My assumption here is that something in these earlier versions is disabling windows driversigning checks completely, which prevents the popups from ever happening. But I could be wrong.
My final assumption here is that since any given problem in any of the 3 versions is fixed in one of the other versions, I don't see how the problem could lie anywhere other than the files within the DPsFnshr.7z file. (which is why I haven't posted the log files)
But since I can't examine the files themselves, I'm at a loss as to how to fix it. My temporary fix is to manually run mute.exe before calling DPsFnshr.exe. But that still leaves the popup frenzie. I've seen in other threads the admins have suggested KTD is dead, and that I should be using SAD. But I do need the drivers left on the machine, for future "automated" driver install when new hardware is connected.
Any suggestions or input on how to proceed is appreciated.
9 2008-09-08 02:12:12
Re: Changing the initial "extract to" folder (3 replies, posted in Feedback and Support - DriverPacks Base)
Thanks for the info. I didn't realize it was issuing a move rather than copy command. And you are right, the finisher always failed for me under guirunonce, so I had it executing at the end of my installer script, after the AV software. I'll try moving it to the top and see if that helps.
10 2008-09-07 04:41:39
Topic: Changing the initial "extract to" folder (3 replies, posted in Feedback and Support - DriverPacks Base)
If this has already been discussed, I apologize. I've searched using every keyword I can think of.
I'm trying to use method 2, with KTD set for C:\Drivers
Everything is working, I'm just trying to speed the install a bit. During windows setup the driver zips are extracted to C:\ , needed drivers installed, then the finisher has to copy all of those extracted drivers to C:\Drivers. I'd like to instead do the initial unzip to the final KTD location, so that the finisher doesn't have to copy the 3+Gb of drivers later.
I've tried editing the OEM\DP_Install_Tool.cmd so that the initial extraction goes to %systemdrive%\Drivers\, but my changes seem to be getting ignored. Am I editing the wrong file? Does the extract to location need to be set as a variable first, say using a "set drvpath=%systemdrive%\Drivers" so that the unzip command line runs just as "%drvpath%\" rather than "%systemdrive%\Drivers\" ? I'm not sure why it would make a difference though.
Or am I looking in the wrong place entirely?