Best practices to install an app and associated driver

We have a small exe utility bundled with a companion driver. Looking forward, what is the best way to write an installer for this purpose?

I usually have several utilities that come along with drivers and typically you want to consider three things:

  • Principle of least security … if you expose three IOCTL’s but the utility is only going to be one of them, then create a device interface that only exposes that single IOCTL and have the utility connect to/ use that. You want to expose the least possible attack surface … and you should also ensure that any buffers that you pass are firewalled in the initial IRP handler (“trust no one” is more than a catchy phrase!) and the data contents verified so that you don’t get any accidental buffer overruns. Method_Buffered or Method_Direct is a good place to start for these IOCTL’s
  • Client authentication … you want to be sure that your utility is the one that’s calling you, so at the least the utility should be signed and the driver should validate that signature upon the create call, when you have the process info available to you … here’s a good place to start [ https://www.cybereason.com/blog/code-integrity-in-the-kernel-a-look-into-cidll ]
  • Data in motion … anytime you have data “on the wire” there is a chance that something will attempt to modify that data (such as a filter driver someplace) … so AES256 encryption is a good method to slow someone down. That always boils down to “who has the key” and that can range from a clever registry PBKDF2 hash to using TPM to a hypercall to a cloud server

Your reply says absolutely nothing about how to install an app with driver and thus provides no information about the question asked. Please start a new thread if you wish to talk about other things. Let’s get back on topic please.

Fair enough … although you did ask for “best practices to install …”, not “what program should I use to install …”

For installations of driver and associated apps I use Wix, I’d look into that …

Discussing installer products is welcome as long as they are best practices. I took a glance at wix and it says installing a driver is a DIFx extension. However, Microsoft states that DIFx is deprecated in Windows 10. Thus, wix does not sound like a best practice. This is not a poll to ask what everyone is using. I want to learn strictly best practices for installing an app/driver combo in Windows 10 and later. Thank you.

Mr @Lakelands is raising a very good point here.

I’m eager to see the responses as well, because I have no idea no to do this. We use DIFx… and it’s deprecated… and when our clients ask us about isn’t all, we generally say something like “yeah, we don’t do that” which is a pretty shitty answer.

So… I to would love to hear responses. Please?

Peter

Write your own custom action installer for your driver in wix. Diffx is
very problematic. Don’t use it. Custom Actions have complete access to
win32 apis and it is fairly trivial to install/uninstall pnp or non-pnp
drivers.

Mark Roddy

As @Mark_Roddy mentioned, probably the biggest advantage to Wix are the custom action DLL’s which is how I install drivers, services or anything that requires system services. The interface is clean, it handles the install and uninstall states nicely and its very easy to drop in custom actions to manage various esoteric installation conditions. There’s a learning curve of the custom actions of course, but at least it’s not COM based … :slight_smile:

I have a Wix “template” which contains slots for console app(s) and driver(s), the driver install slot(s) take a custom action specific to that driver and OS … so one for file system filter drivers on Win7, another for software only drivers on Win10, another for services on Win7, another for PCIe drivers on Win10, etc. … literally about 30+ custom action DLL’s for different drivers on different OS’s (depending on what MS changes) … the EULA stuff, localization info, etc. are all handled in Wix

So, suppose I’m doing a medical device USB driver on Win7 with two UI’s … I take my Wix template, drop in the two UI Wix blocks, drop in the Win7 USB driver custom action “install” DLL and custom action “uninstall” DLL and I’m done …

When the user wants to uninstall then Wix handles the rollback and the custom action DLL’s handle the driver uninstalls …

I also have been using WinSparkle [ https://winsparkle.org/ ] for distributed client updates, which matches very nicely with the Wix installer objects. The UI queries the WinSparkle server on a Linux box inside of the infranet, pulls down the latest Wix image and then Wix handles the upgrade install internally … all the user sees is two prompt dialogs and a button … :slight_smile:

WIX is certainly the way to go to make an MSI based installer. MSI installers are a necessity for any enterprise environment.

Also DIFx based (and deprecated), we simply use DPInst.exe to install / uninstall drivers. Works well, no issues from Windows 7 up to Windows 11. Keeps it simple and the same for all Windows versions.

So you’re saying that a simple proven way that just works is a best practice - no matter what Microsoft uttered on this.

So a random exe from some ancient archive or from some dubious internet site, that is explicitly not supported by MSFT, is likely not high on the list of best practices.

Write a Custom Action installer using the devcon sample. It is a ‘3’ for you agile idiots. You do this once. You re-use it for any driver install requirement. Or not. Your choice.

It is a ‘3’ for you agile idiots.

Is playing “planning poker” involved? Because if we get to play “planning poker” then I’m all in.

(sorry… he said “agile” and I couldn’t resist)

Peter

Is playing “planning poker” involved?

Warning: Thread derailment in progress

Agile idiocy like ‘planning poker’ is one of the reasons why I’ve decided to retire. That plus being 40 years older than everyone.

@pwilly said:
Also DIFx based (and deprecated), we simply use DPInst.exe to install / uninstall drivers. Works well, no issues from Windows 7 up to Windows 11. Keeps it simple and the same for all Windows versions.

Ummm … well, there might be some issues to consider with this … first, let’s look at what it does [ https://www.itninja.com/blog/view/driver-package-installer-dpinst ] … then, let’s look at the MS DIFxx page [ https://docs.microsoft.com/en-us/windows-hardware/drivers/install/difx-guidelines ] which is filled with caveats and warnings. You can certainly blow through those, but do so with a clear decision that “I just don’t care about that stuff”

Second, note that probably the biggest problem any install will face is ensuring that either the product is fully, properly installed or completely removed from a machine; anything in between is going to be nightmarish in debugging and recovery. Having the user be able to terminate an installation outside of the installer state machine (like DPInst lets the user do) means that the primary installer has to somehow figure out what happened and handle that, which is a headache I really don’t need

Finally, right here on this very site is a most excellent article [ https://www.osr.com/nt-insider/2014-issue1/guest-article-driver-installers/ ] which describes the DPInst user experience (and why it might not be the best idea). Pay really close attention to the section that talks about uninstallers; again, for a clean experience you want one and only one uninstall per product, not a smorgasbord of Add/Remove entries which will only lead to support calls. One installer, one uninstaller …

For a simple POC driver DPInst is probably a good idea … but for a commercial product, where the user expects a single .MSI to do everything, expects that either everything is properly installed (and running, very important stage here, users like things that are actually running once the installer is done unless a reboot is unavoidably necessary) or completely gone and removed from the machine, expects a unified, consistent user interface (not something that looks like it was written by different UI teams and stitched together) and has the bells and whistles like help files, readme’s and such and expects a single uninstall entry in Add/Remove programs I would again suggest Wix with a raft of custom action DLL’s …

Well these are all valid points and I am glad you pointed this out. At no point we declared it best practise (and declared it explicitly as deprecated). We use DPInst.exe in silent command line mode within our main (un)installer, so the user experience is not altered. The return codes inform the main (un)installer if any issues occurred. So far it worked very well for the last 6 years and for us we currently see no need to change a well running installer only because in the meantime MS has deprecated it. However we have only a simple PnP filter driver to (un)install.

Having said this, once we drop Windows 7 + 8 support we’ll read this thread again for best practice and consider the recommended MS way to (un)install our driver.

So you felt some urge to jump in and add 3 posts to this short thread to tell everyone you are using a deprecated technology and have no interest in best practices today. This is completely useless information. This thread is for discussing forward thinking, best practices advice. Let’s get back on topic please.