• Registered: 2008-09-06
  • Posts: 10

Topic: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

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.

  • OverFlow
  • DriverPacks Administrator & BASE Developer
  • Offline
  • From: Cincinnati
  • Registered: 2006-12-02
  • Posts: 6,730

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

when you install new hardware run SAD... wink

Outdated drivers are not the answer... and hardware does not install itself your going to be there... wink


KTD uses makePNF which creates duplicate and unsigned INFs these unsigned PNFs are passed over since they are unsigned this is why KTD is dead and is why your video drivers will not install. KTD never worked very well... SAD does...

If you absolutely must have drivers needlessly takeing up space on your machine(s) and that will in all likelyhood never be used and by the time they are used they will be out of date, then the best thing to do is to create a SAD M1 folder and run DevPath.exe [path:\Driverpacks.net\D\] this will give you better than KTD funtionality (because it will not run makepnf which breaks the driversigning).

We don't just say KTD is dead because we like the way it sounds when we say it wink there are many reasons, I have just given you one of many good ones.


PS the ONLY difference between 8.12.2 8.12.3 8.12.4 are language updates wink
no changes were made to code in DriverPacks BASE or finisher

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

OverFlow's Website

  • Registered: 2008-09-06
  • Posts: 10

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

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)

Last edited by Camelot_One (2009-03-02 13:12:13)

  • OverFlow
  • DriverPacks Administrator & BASE Developer
  • Offline
  • From: Cincinnati
  • Registered: 2006-12-02
  • Posts: 6,730

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

the functionality of the finisher is well documented... you should be able to come up with that on your own. but whatever....

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.

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

OverFlow's Website

  • Registered: 2008-09-06
  • Posts: 10

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

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.

  • OverFlow
  • DriverPacks Administrator & BASE Developer
  • Offline
  • From: Cincinnati
  • Registered: 2006-12-02
  • Posts: 6,730

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

if you want to be treated like a big boy. then act like one. you have not listened and you have repeatedly posted inaccurate results. You've failed to verify your results and you have further failed to do good research on your own. you have gone off 'half cocked'  multiple times in every one of your 5 posts. You have failed to demonstrate good trouble shooting skills (or even basic ones).

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

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

OverFlow's Website

  • Registered: 2008-09-06
  • Posts: 10

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

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.

Last edited by Camelot_One (2009-03-02 18:01:16)

  • OverFlow
  • DriverPacks Administrator & BASE Developer
  • Offline
  • From: Cincinnati
  • Registered: 2006-12-02
  • Posts: 6,730

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

much better... thank you for updateing your post,  let's try to move forward

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 wink  understand... OK?

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

Camelot_One wrote:

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 the DP_Install_Tool.cmd 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.

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 wink. 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 wink it caches the cabs big_smile - 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 wink ).
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... wink

PS in case it had not occured to you you can leave the SAD folder on the machine wink 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!~

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

OverFlow's Website

  • Registered: 2008-09-06
  • Posts: 10

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

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.

  • OverFlow
  • DriverPacks Administrator & BASE Developer
  • Offline
  • From: Cincinnati
  • Registered: 2006-12-02
  • Posts: 6,730

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

Did you try enclosing the %ktd% in quotes "%ktd%" ?

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

Keep us in the loop on your progress!

Have a great day & best of luck!

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

OverFlow's Website

  • Registered: 2008-09-06
  • Posts: 10

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

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.

Last edited by Camelot_One (2009-03-04 08:32:46)

  • OverFlow
  • DriverPacks Administrator & BASE Developer
  • Offline
  • From: Cincinnati
  • Registered: 2006-12-02
  • Posts: 6,730

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

Well I learned somthing that I did not know...  the finisher does not use DevPath... LOL

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...

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

OverFlow's Website

  • Registered: 2008-09-06
  • Posts: 10

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

Well that would explain why I couldn't get the syntax right! Thanks for checking into it.

  • From: Springfield, MA, USA
  • Registered: 2007-09-21
  • Posts: 396

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

What's devpath suppose to do anyways, set the path in the registry?

Search your INF's for Hardware ID's with FindHWIDS

stamandster's Website

  • Registered: 2008-09-06
  • Posts: 10

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

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

  • From: Springfield, MA, USA
  • Registered: 2007-09-21
  • Posts: 396

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

Like vernalex's tool. I see. I wrote a function like that into Driverforge way back when.

Last edited by stamandster (2009-05-14 04:31:54)

Search your INF's for Hardware ID's with FindHWIDS

stamandster's Website

  • Acheron
  • DriverPacks Donor!
  • Offline
  • From: Apeldoorn, The Netherlands
  • Registered: 2008-02-23
  • Posts: 65

Re: [DPsFnshr.7z Information request] - KTD DSPdsblr, Mute, and DPsFnshr

I'm working on a similar tool as DPFinisher to support installing all drivers from CD, without copying them to the HDD before. Can anyone please give me access to the DPFinisher source code or any documentation about the DriverPacks ini format. I read some time ago about DriverPacks going open source, http://forum.driverpacks.net/viewtopic.php?id=891, now where's the code?