FAQ
First of all, I must point out that Zadig does exactly what you tell it to do. If you select the wrong device, and Zadig happen to replace its driver, the responsibility is entirely yours. Zadig will try to warn about common system drivers, such as HID or Mass Storage, that you don't usually want to replace, but there are only so many drivers Zadig can know about. So, please, try to pay attention to the device you select next time: don't just close your eyes and press the install button on the first device you see, OK?
Now, restoring the previous system driver, if it was replaced, is usually pretty simple (as long as you didn't replace the HID driver for your mouse or keyboard - if you did, you will need to plug in another keyboard or mouse, to navigate the device manager).
In this example, let's say I inadvertently let Zadig install a driver for an USB Flash Drive, which made the system end up using WinUSB instead of the Windows default Mass Storage device. And after finding out that this mean I can no longer access my Flash Drive in Explorer, I need to restore it to the original Mass Storage driver. To do just that:
- Open Device Manager
- Under Universal Serial Bus devices (or possibly libusbk devices/libusb-win32 devices if you didn't pick WinUSB as your driver), right click on your device. In this example, ADATA UFD is our device.
- Select Uninstall and on the dialog box that appears, make sure to check the box that says "Delete the driver software for this device" then click OK.
- Once the uninstallation is complete, unplug and replug your device. The original system driver should now be reinstalled. In our case, we would see the Flash Drive reappearing under the Disk drives category, which is what we want.
Because libwdi can be compiled in very different way (as a static or dynamic library, with or without the WinUSB or libusb-win32 drivers, with or without separate 32 or 64 bit binaries, etc.), and these configuration have a major impact on the size of the resulting binaries, producing regular binary snapshots of libwdi to address various user's needs would require a lot of time, as we would need to produce about 18 different versions to satisfy everyone. We might produce a limited subset of binary snapshots in the future, but for the time being, we require the library to be configured and recompiled according to your needs.
See the paragraph 'Using a custom driver file with libwdi' in the installation & compilation guide.
Absolutely. This can be very convenient if you have a multilib MinGW-w64 cross compiler installed on a Linux host for instance. You will of course need to have the WinUSB (from the MS WDK), libusb-win32, libusbK or your own user driver files available on the build platform.
An example of configuring libwdi for cross-compilation using MinGW-w64, with the libusb-win32 driver, would go something like this:
./configure --host=x86_64-w64-mingw32 --with-libusb0="/usr/src/libusb-win32"
By default, the configure script expects your default build platform's compiler to be able to produce executables that run on that platform. This is necessary so that the build process can compile and run the custom embedder, to add the driver files to the library. If however your default compiler does not produce executables that run on your build platform, the process will fail. This can occur for instance, if you are using a multilib MinGW-w64 on a Windows 32 platform, but the default for gcc is to produce 64 bit executables. If this is the case, you should define a CC_FOR_BUILD environment variable with the relevant options. For instance, in the scenario above, you would issue the following, to ensure that MinGW-w64 produces a 32 bit embedder executable that can be run during the build process: export CC_FOR_BUILD="x86_64-w64-mingw32-gcc -m32
- Use Visual Studio (>= 2005) and select Win32 for the target. Note that Visual Studio Express cannot be used, as it doesn't include a 64 bit compiler.
- Use a multilib version of MinGW-w64. Multilib means a compiler that supports both the -m32 and -m64 options. Currently, the binaries provided on the project page are not multilib, so you need to either find a pre-built MinGW-w64 version that properly supports it, or recompile MinGW-w64 yourself.
Unfortunately, Microsoft's Visual C++ Express is a crippled version that cannot import project files that contain 64 bit builds. You should switch to using the freely available Visual Studio Community Edition
This can occur when compiling Zadig with Visual Studio Express, and is due to Visual Studio Express not officially supporting MFC applications. You can however get zadig compiled if you edit the 'zadig.rc' file and replace the line
#include "afxres.h"with
#include <windows.h> #define IDC_STATIC -1
If this happens with a recent version of libtool (2.2.8 or later), this can be due to a MinGW-w64 packaging problem with the 64 bit libraries in the x86_64-w64-mingw32/lib directory. One way to address that issue is to move all the libraries from lib/ into the lib64/ directory. If you fixed the MinGW-w64 packaging issue yet still have similar issues, you may need to update libtool to version 2.2.8 or later.
You are probably attempting to cross compile on an environment where the default gcc cannot produce executables. Because libwdi requires the compilation and execution of an embedder.exe native to the host, the host's default gcc must be able to produce executables that run on the compilation platform.
What are these "USB\VID_####&PID_####[&MI_##] (Autogenerated)" certificates that libwdi installs in the Trusted certificate stores?
From version 1.1.0, if you are installing a driver on Vista or later versions of Windows, libwdi will attempt to generate and self-sign driver package, and then mark the certificate used for the signing process as trusted, by installing it in the system stores, in order to avoid further security prompts during the driver installation.
During that process, libwdi will copy two autogenerated certificates to the Root (Trusted Root Certification Authorities) and Trusted Publisher system certificate stores.
While the installation of certificates into these stores, without asking the end user, may sound like questionable practice, please understand that none of these certificate actually introduce a security liability as nobody, not even the authors of libwdi, have the ability to reuse these certificates in order to mark malicious software as trusted. This is because:
- The private key for the certificate is generated at runtime, on the end user machine, and is not accessible to anybody else but the libwdi application that does the signing process for a limited time only
- after the driver package has been signed, the private key is destroyed. This effectively means that the certificate is a one-time use only, and cannot be used for anything but to validate driver package that was signed by libwdi, that one time. As a matter of fact, even if you re-install the exact same device using the same driver, libwdi has to generate a brand new certificate (and a new temporary private key), and replace the old one, because it is impossible to reuse it.
For more information, see our Certification Practice Statement page
When run from within an installer script, the wdi-simple sample from examples should be able to achieve just that. An example of Inno Setup installer script is also provided with the libwdi examples. See the wdi-simple.iss sample.
Absolutely. The inf file created by libwdi is written in Unicode (UTF-16) format, to preserve any international characters, and the libwdi API calls and string parameters fully support UTF-8, meaning that you can name your devices with non English characters, or use directories in a different locale than English, and libwdi will happily process that data.
No. Just like Windows provides mechanisms to prevent simultaneous driver installations, most of the libwdi API calls will prevent concurrent access to libwdi to ensure that only one application at a time has the ability to install a system driver.
The default on Windows Vista and later is to create restore a point before installing any driver. Depending on the system, this can be a fairly lengthy operation (20 seconds or, in extreme cases, up to 5 minutes). Because we are installing non bootable drivers, for devices (USB) that can be easily removed in case of problems, from v1.1.0, libwdi does its best to disable the creation of restore points. However, if the Local Group Policies are overridden or cannot be modified, you may have to contend with a restore point and a lengthy driver installation.
They aren't. The reason behind this is twofold. First, it is a bad idea to have an application running in elevated mode to delete files, as, if the extraction directory was user selected, we could end up deleting important data. Secondly, it is possible to use libwdi to setup the driver files for the next time the device is plugged in, in which case we must ensure that the files are still available. Deletion of the file is therefore left either to the end user or your application.
The two main reasons here are the size factor (each dpinst is about 1 MB in size or 300 KB compressed, whereas our installer is a lot smaller) as well as the ability to have greater control over the installation process. We might provide an option to embed and use dpinst in future versions of the library.
If you ask this, you probably would like to have libwdi/Zadig set the class GUID, name or provider in the installed driver package. We have taken the deliberate decision not to add this feature, because:
- With the introduction of WCID for WinUSB devices in Windows 8 and then in Windows 7, Microsoft has effectively defined a unique class name,
Universal Serial Bus devicesas well as a unique class GUID,{88bae032-5a81-49f0-bc3d-a4ff138216d6}, for all USB devices that rely on the WinUSB generic driver. Therefore, if you were to set your own class properties for utilization in your application, not only will you not be able to use WCID as a result, but you will also prevent compatible WCID devices to work with your application, which we see as very detrimental for end users. This also applies even if you don't plan to use WinUSB, as WCID is not limited to WinUSB and the same restrictions will occur with other drivers. - The main reason people want to set class parameters in the inf is either to place their own branding in the device manager (which makes it more confusing for end-users to locate their devices) or to define a class GUID that restricts the generic access that libwdi provides to hardware and software ("walled garden"). We don't think restrictions that impair the ability for end users to use the device of their choosing, including a cloned version, should be part of the libwdi generic driver installation process.
Copyright © 2012-2024 Pete Batard
