libwdi-devel Mailing List for libwdi

I kind of forgot that this mailing list still exists, so I might as well 
use it once in a while... ;)

New features:
-------------
   - ARM64 driver installation support (WinUSB, USBSer with MSVC only)

Bugfixes:
---------
   - fix MSVC compilation of the shared library
   - fix MinGW compilation when using the shared library (with thanks to 
Joel Holdsworth)

Improvements:
-------------
   - avoid symbol conflicts by using library specific prefixes where needed
   - improve Zadig network support


Also, Zadig has now been updated to embed the latest libusb-win32 driver 
(v1.2.7.3) and should be able to install ARM64 versions of WinUSB and 
USBSer.

Note that ARM64 support still requires x86 emulation on the ARM64 
platform, as Zadig and the libraries are still compiled exclusively as 
x86 applications (I am not planning to produce native ARM64 versions at 
this stage).

Also, only MSVC compilation can produce an ARM64 compatible version of 
the library or of the examples, since MinGW is missing the ability to 
produce ARM64 code, which we need for the underlying installer.

Enjoy!

/Pete

Hi, good afternoon, I'm from Chile haha I don't speak English but I
translated. I mention my problem, my pc does not recognize my ps3
controller and I think it is a driver problem. I think something moved
with zadig, I don't know if it could help me, I would be very
grateful. that you are well, greetingssss take care

Changes for these releases are as follows:

o libwdi 1.2.5
   Bugfixes:
   - fix possible crash when deleting the self signing private key
   - fix detection of modified file during embedding
   Improvements:
   - add USB Serial (CDC) driver installation (Courtesy of Sensics, Inc.)
   - add Arm support provision for WinUSB inf (and remove Itanium support)
   - use SHA-256 instead of SHA-1 where possible
   - report an error when Windows Update is disabled
   - update solution to Visual Studio 2015
   - remove unmaintained inf-wizard sample
-------------------------------------------------------------------------
o Zadig 2.2
   - Add USB Serial (CDC) support (**EXPERIMENTAL**)
   - Use SHA-256 instead of SHA-1 wherever possible
   - Fix a possible crash when deleting the private key
   - Other improvements
   - Embedded drivers: WinUSB v6.1.7600.16385, libusb-win32 v1.2.6.0, 
libusbK v3.0.7.0 & usbser (native)

For additional information and downloads, please visit 
http://libwdi.akeo.ie or http://zadig.akeo.ie respectively.

Regards,

/Pete

Windows 10 is of course supported. Please understand that the 
documentation simply states the highest platform that existed at the 
time it was written, and you will find plenty of projects, like libwdi, 
that mention "up to Windows 8.1" but that work just fine on Windows 10.

Or did you encounter any issues using libwdi on Windows 10?

Regards,

/Pete

On 2015-10-22 03:14, div...@li... wrote:
> Libwdi declared it supports all windows platform from windows XP to
> windows 8.1, then windows 10 is coming now, I wonder how about the
> support for win 10, if it don't support it now, then what about the future?
>
> 通过 Android 版 Outlook <http://taps.io/outlookmobile> 发送
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Libwdi-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libwdi-devel
>

If the device has a driver installed already, then if I can force install my driver? I don't intend to do something bad, but sometimes I need to do this to my device due to the bug in my device driver.


Thanks.


通过 Android 版 Outlook 发送

Libwdi declared it supports all windows platform from windows XP to windows 8.1, then windows 10 is coming now, I wonder how about the support for win 10, if it don't support it now, then what about the future?


通过 Android 版 Outlook 发送

Changes for these releases are as follows:

o libwdi 1.2.4
   Bugfixes
   - fix multiple potential NULL derefs
   - fix a Zadig crash when listing devices
   Improvements
   - upgrade solution files for Visual Studio 2013 Community Edition
   - update the list of known Android devices
   - add support for AMD USB 3.0 hub driver
   - improve error reporting and external DLL handling
-------------------------------------------------------------------------
o Zadig 2.1.1
   - Fix a possible crash when listing devices
   - Update libusbK to latest version
   - Update the list of known Android devices
   - Improve auto-update feature
   - Increase default logging verbosity
   - Embedded drivers: WinUSB v6.1.7600.16385, libusb-win32 v1.2.6.0 & 
libusbK v3.0.7.0

For additional information and downloads, please visit 
http://libwdi.akeo.ie or http://zadig.akeo.ie respectively.

Regards,

/Pete

Hi Alex,

On 2014.08.30 09:23, alex mosky wrote:
> Is there a way to call the zadig executable using some command arguments?

Please look into the zadic (with a C) or wdi-simple samples from the 
library. They are commandline based and can be modified to do exactly 
what you want.

See https://github.com/pbatard/libwdi/tree/master/examples

Regards,

/Pete

Hello,

I've build windows bat script to download and install tools that are part
of the toolchain for an embedded project (yacarto, openOCD, chibiOS, olimex
ARM-USB-OCD-h debugger) and I would also like to download zadig and install
the drivers for olimex ARM-USB-OCD-h debugger from within this script.

Is there a way to call the zadig executable using some command arguments?

Thanks for all the work, made my day easier!

Cheers!

Alex

Changes for these releases are as follows:

o libwdi 1.2.3
   Bugfixes
   - allow spaces and commas in paths and names used for installation
   - don't redefine boolean but use BOOL, so that C++ apps can properly 
invoke libwdi
   Improvements
   - add support for additional xHCI controllers (Intel, VIA...)
   - add timeout for pending installations in wdi_options_install_driver
   - use Google's Device Interface GUID for Android devices
   - major improvements to Zadig
-------------------------------------------------------------------------
o Zadig 2.1.0
   - Fix a crash when listing all devices on machines with intel USB 3.0 
controllers
   - Fix multiple issues with paths containing spaces
   - Use the Google Device Interface GUID when an Android device is 
detected. This means you can now use of Zadig to install the USB driver 
for adb & fastboot.
   - Update versioning scheme
   - Add auto-update feature
   - Embedded drivers: WinUSB v6.1.7600.16385, libusb-win32 v1.2.6.0 & 
libusbK v3.0.6.0

For additional information and downloads, please visit 
http://libwdi.akeo.ie or http://zadig.akeo.ie respectively.

Regards,

/Pete

Hi,

	Thanks again for the detailed explanation. I had gone through some
of the discussions regarding the security 	aspects and libwdi's
approach in the forums earlier and I tend to agree with you in what you have
said earlier 	and in the mail below. It is the business model that has
been built around it (and the following that it has) 	and the notion of
feeling secure makes one think in that direction.

	Thanks once again.

Warm Regards,
Deepak

-----Original Message-----
From: Pete Batard [mailto:pb...@gm...] 
Sent: 19 January 2014 04:20
To: lib...@li...
Cc: dee...@ti...
Subject: Re: [libwdi-devel] Question regarding signing custom driver files

On 2014.01.18 04:48, Deepak Hegde wrote:
> 	We are looking at the second option. We are developing the drivers 
> for our customer (and their device).
> 	We are developing the DLL and planning to package it with the SYS
> (and 	other DLLs) provided by Microchip.
> 	We don't need to change the SYS and DLL files provided by Microchip.
>
> 	However, as we have modified the INF file (to reflect the changes 
> related to the vendor, description etc), we need to package and sign the
> driver files 	(modified INF + Custom DLL + Microchip SYS + Microchip DLL
> file(s)) so that the driver package can be installed on the target 
> (end
> user) systems.

OK.

> 	Our customer is hesitant to go for buying a code signing certificate

> (possibly due to yearly subscription costs and/or other reasons that I 
> am not aware of).

If you are reusing someone else's driver binary, I have to agree with your
customer here.

> 	As tools and examples that are part of libwdi (zdaig, wdi-simple)
and 
> the APIs don't sign the custom packages (and only extract the files), 
> we modified
> 	Wdi-simple. When executed on the end user systems, it now calls
> wdi_prepare_driver() (to extract the files), followed by a call to
> CreateCat() (to create a 	catalog file on the end user system)
> followed by  wdi_create_list() and wdi_install_driver().

Yes, that's what you should do. You basically want to add a new generic
driver, just like WinUSB, libusb-win32 or libusbk, so you should follow the
same steps as what is being done for those.

> 	We found this a convenient way to circumvent the driver signing 
> requirement.

I'll take objection to the use of "circumventing", which, because we've had
this debate before, I know many people wrongly believe is what libwdi is
doing, when they simply fail to understand that a self-signed certificate is
just as valid as a commercial one.

Of course, since a lot of certification authorities have established their
business model on selling certificates, it is in their interest to try to
confuse people in the belief that installing a self-signed certificate is
not a viable solution, but this is just plain wrong.

The only issue with self-signed is whether the OS has been deliberately set
to reject them (as is the case for .sys signing) or not (driver package
signing), but that is an entirely arbitrary decision from the OS maker. And
I say arbitrary because the security model of Windows would not be
diminished in any way if Microsoft allowed their users to do the same when
it comes to using self-signed certificates for .sys as they allow with
regards to self-signed certificates for driver packages.

> It does pop-up the security warning to the user, which is Ok (I
> think, but need 	to check with our customer).

Mmmm, the whole point of this operation is precisely to disable any extra
warning, AFTER the user has accepted to run the application with elevated
privileges.

> 	Considering the above, I was wondering if there is issue in this 
> approach?

None. Anybody who understand PKI and the Windows Security model should
realize that using a self signed certificate or a commercial certificate to
sign your driver package doesn't mean anything different as far as the OS is
concerned.

> Is this permissible (from wdi and/or Microsoft or generic
> security/legal and/or 	license perspective)?

It is permissible, legal and more importantly, it will not diminish the
security of a user's machine in any way.

Saying that it isn't permissible would be exactly the same as Verisign
suddenly declaring that the only certificates that can ever be valid are the
ones they generate, and that those from their competitors or the ones that
users create themselves (self-signed) suddenly aren't.

As much as they would probably like to be able to say so, so that they can
get a monopoly on the profitable certificate generation, there is no legal
ground from them to claim such such a thing. Again, and I have to stress
that out, each certificate, be it generated by a commercial entity, such as
Verisign, Globalsign and others, or one that you generate yourself, is no
less valid. The only difference, which has nothing to do with the
certificate, is that the OS vendor may decide to have already pre-registered
the root certificate from some commercial vendors as a trusted entities,
whereas, for a self-signed certificate, you have to do that yourself (which
is what libwdi really does). That's all.

But the thing is, you should probably place MORE trust into a certificate
that you generate and install yourself, than ones that have been
pre-approved, WITHOUT YOUR CONSENT, from entities that, time and time again,
do get their security compromised, and have had to see some of their root
certificates revoked!

Now, the one last item where people may take objection is that libwdi will
silently install the self-signed certificate part of the credential it
generates, in the machine's certificate store. But this only happens AFTER
the user has indicated that they TRUST the application, by accepting its
request for elevation. So there again, while some people seem to have
trouble wrapping their head around the concept of transitive trust, which is
really a good part of what the whole PKI model is based on, there is still
no security compromise or anything dodgy going on.

In other words, what libwdi does with regards to self-signing the driver
package is entirely permissible, legal, and what's a lot more important,
100% safe for the user.

Finally, I'll just point to the CSP (Certification Practice Statement) that
is publicly available for any of the certificates that libwdi installs [1],
and that should also apply to yours if you didn't change the code. This is
the page you will go to if you examine the certificates and click on the
"Issuer Statement" button, that provides further details on this whole
process.

If you read through all this information, I hope you will come to realize
that there is nothing in what libwdi does, with regards to driver package
signing, that should even remotely be considered as "circumvention". None of
what we're doing qualifies as a trick or a hack, as we are strongly adhering
to the tenets of PKI, security and what the Microsoft framework legally
entitles us to do with regards to driver package installation. All we're
doing is avoiding user annoyances.

Regards,

/Pete

[1] https://github.com/pbatard/libwdi/wiki/Certification-Practice-Statement

On 2014.01.18 04:48, Deepak Hegde wrote:
> 	We are looking at the second option. We are developing the drivers
> for our customer (and their device).
> 	We are developing the DLL and planning to package it with the SYS
> (and 	other DLLs) provided by Microchip.
> 	We don't need to change the SYS and DLL files provided by Microchip.
>
> 	However, as we have modified the INF file (to reflect the changes
> related to the vendor, description etc), we need to package and sign the
> driver files 	(modified INF + Custom DLL + Microchip SYS + Microchip DLL
> file(s)) so that the driver package can be installed on the target (end
> user) systems.

OK.

> 	Our customer is hesitant to go for buying a code signing certificate
> (possibly due to yearly subscription costs and/or other reasons that I am
> not aware of).

If you are reusing someone else's driver binary, I have to agree with 
your customer here.

> 	As tools and examples that are part of libwdi (zdaig, wdi-simple)
> and the APIs don't sign the custom packages (and only extract the files), we
> modified
> 	Wdi-simple. When executed on the end user systems, it now calls
> wdi_prepare_driver() (to extract the files), followed by a call to
> CreateCat() (to create a 	catalog file on the end user system)
> followed by  wdi_create_list() and wdi_install_driver().

Yes, that's what you should do. You basically want to add a new generic 
driver, just like WinUSB, libusb-win32 or libusbk, so you should follow 
the same steps as what is being done for those.

> 	We found this a convenient way to circumvent the driver signing
> requirement.

I'll take objection to the use of "circumventing", which, because we've 
had this debate before, I know many people wrongly believe is what 
libwdi is doing, when they simply fail to understand that a self-signed 
certificate is just as valid as a commercial one.

Of course, since a lot of certification authorities have established 
their business model on selling certificates, it is in their interest to 
try to confuse people in the belief that installing a self-signed 
certificate is not a viable solution, but this is just plain wrong.

The only issue with self-signed is whether the OS has been deliberately 
set to reject them (as is the case for .sys signing) or not (driver 
package signing), but that is an entirely arbitrary decision from the OS 
maker. And I say arbitrary because the security model of Windows would 
not be diminished in any way if Microsoft allowed their users to do the 
same when it comes to using self-signed certificates for .sys as they 
allow with regards to self-signed certificates for driver packages.

> It does pop-up the security warning to the user, which is Ok (I
> think, but need 	to check with our customer).

Mmmm, the whole point of this operation is precisely to disable any 
extra warning, AFTER the user has accepted to run the application with 
elevated privileges.

> 	Considering the above, I was wondering if there is issue in this
> approach?

None. Anybody who understand PKI and the Windows Security model should 
realize that using a self signed certificate or a commercial certificate 
to sign your driver package doesn't mean anything different as far as 
the OS is concerned.

> Is this permissible (from wdi and/or Microsoft or generic
> security/legal and/or 	license perspective)?

It is permissible, legal and more importantly, it will not diminish the 
security of a user's machine in any way.

Saying that it isn't permissible would be exactly the same as Verisign 
suddenly declaring that the only certificates that can ever be valid are 
the ones they generate, and that those from their competitors or the 
ones that users create themselves (self-signed) suddenly aren't.

As much as they would probably like to be able to say so, so that they 
can get a monopoly on the profitable certificate generation, there is no 
legal ground from them to claim such such a thing. Again, and I have to 
stress that out, each certificate, be it generated by a commercial 
entity, such as Verisign, Globalsign and others, or one that you 
generate yourself, is no less valid. The only difference, which has 
nothing to do with the certificate, is that the OS vendor may decide to 
have already pre-registered the root certificate from some commercial 
vendors as a trusted entities, whereas, for a self-signed certificate, 
you have to do that yourself (which is what libwdi really does). That's all.

But the thing is, you should probably place MORE trust into a 
certificate that you generate and install yourself, than ones that have 
been pre-approved, WITHOUT YOUR CONSENT, from entities that, time and 
time again, do get their security compromised, and have had to see some 
of their root certificates revoked!

Now, the one last item where people may take objection is that libwdi 
will silently install the self-signed certificate part of the credential 
it generates, in the machine's certificate store. But this only happens 
AFTER the user has indicated that they TRUST the application, by 
accepting its request for elevation. So there again, while some people 
seem to have trouble wrapping their head around the concept of 
transitive trust, which is really a good part of what the whole PKI 
model is based on, there is still no security compromise or anything 
dodgy going on.

In other words, what libwdi does with regards to self-signing the driver 
package is entirely permissible, legal, and what's a lot more important, 
100% safe for the user.

Finally, I'll just point to the CSP (Certification Practice Statement) 
that is publicly available for any of the certificates that libwdi 
installs [1], and that should also apply to yours if you didn't change 
the code. This is the page you will go to if you examine the 
certificates and click on the "Issuer Statement" button, that provides 
further details on this whole process.

If you read through all this information, I hope you will come to 
realize that there is nothing in what libwdi does, with regards to 
driver package signing, that should even remotely be considered as 
"circumvention". None of what we're doing qualifies as a trick or a 
hack, as we are strongly adhering to the tenets of PKI, security and 
what the Microsoft framework legally entitles us to do with regards to 
driver package installation. All we're doing is avoiding user annoyances.

Regards,

/Pete

[1] https://github.com/pbatard/libwdi/wiki/Certification-Practice-Statement

Hi,

	Thanks for the inputs and clarification. I went through the
walkthrough. I also tried to go through the wdi code.

	We are looking at the second option. We are developing the drivers
for our customer (and their device). 
	We are developing the DLL and planning to package it with the SYS
(and 	other DLLs) provided by Microchip. 
	We don't need to change the SYS and DLL files provided by Microchip.

	However, as we have modified the INF file (to reflect the changes
related to the vendor, description etc), we need to package and sign the
driver files 	(modified INF + Custom DLL + Microchip SYS + Microchip DLL
file(s)) so that the driver package can be installed on the target (end
user) systems.
	
	Our customer is hesitant to go for buying a code signing certificate
(possibly due to yearly subscription costs and/or other reasons that I am
not aware of).

	As tools and examples that are part of libwdi (zdaig, wdi-simple)
and the APIs don't sign the custom packages (and only extract the files), we
modified
	Wdi-simple. When executed on the end user systems, it now calls
wdi_prepare_driver() (to extract the files), followed by a call to
CreateCat() (to create a 	catalog file on the end user system)
followed by  wdi_create_list() and wdi_install_driver().

	We found this a convenient way to circumvent the driver signing
requirement. It does pop-up the security warning to the user, which is Ok (I
think, but need 	to check with our customer).

	Considering the above, I was wondering if there is issue in this
approach? Is this permissible (from wdi and/or Microsoft or generic
security/legal and/or 	license perspective)?
	
	Again, thanks for the inputs.
	
Warm Regards,
Deepak


-----Original Message-----
From: Pete Batard [mailto:pb...@gm...] 
Sent: 18 January 2014 07:54
To: lib...@li...
Subject: Re: [libwdi-devel] Question regarding signing custom driver files

HI Deepak,

On 2014.01.09 04:41, Deepak Hegde wrote:
> My question is, how can I use libwdi to sign the files on-the-fly and 
> install the custom SYS and DLL files using the PKI tools/features 
> available (without using a third-party code/driver signing certificate)?

I'm pretty sure you are misunderstanding what you really need here.

First of all, the only possibility you would ever want to apply on-the-fly
signing is if, AND ONLY IF, you are providing a GENERIC USB driver, that can
be applied for devices which you don't know the VID:PID beforehand, and for
which you have to create the .inf file at runtime, on the user's machine.


If the situation above does not apply to you, especially, especially if you
can build a list of all the VID:PID's of the devices that your driver will
service, then there is NO magic on-the-fly signing solution that you can or
should use.


This is because there really are 2 signing operations that can apply:

One, which is MANDATORY, and which can only be accomplished after PURCHASING
a certificate, for the .sys file. This is because the Microsoft security
model does not let you self-sign your own drivers (unless you want to make
all your users in self-test mode, but that is really a BAD IDEA, especially
as it will make their system vulnerable to attacks).

The second one, which is optional, and which is the only one that can be
accomplished on-the-fly, without PURCHASING an external signing certificate,
is the signing of the driver package (.sys + .inf + .dll + any other files)
to prevent an extra security prompt from being displayed to the users during
installation.


But even for the second one, if you know all your VID:PID's, then your .inf
and all the other files should be static, and therefore, the signing does
not need to be accomplished on the fly, but should instead be done on your
machine before distributing the driver package.


So, really, unless you are providing a generic driver, that can apply to any
VID:PID, and want to avoid your users seeing an extra security prompt (which
won't prevent them from installing the driver), you should read, understand
and follow https://github.com/pbatard/libwdi/wiki/Signed-Driver-Walkthrough
as it should contain all the informations you need.

Regards,

/Pete

----------------------------------------------------------------------------
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical
Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Libwdi-devel mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libwdi-devel

HI Deepak,

On 2014.01.09 04:41, Deepak Hegde wrote:
> My question is, how can I use libwdi to sign the files on-the-fly and
> install the custom SYS and DLL files using the PKI tools/features
> available (without using a third-party code/driver signing certificate)?

I'm pretty sure you are misunderstanding what you really need here.

First of all, the only possibility you would ever want to apply 
on-the-fly signing is if, AND ONLY IF, you are providing a GENERIC USB 
driver, that can be applied for devices which you don't know the VID:PID 
beforehand, and for which you have to create the .inf file at runtime, 
on the user's machine.


If the situation above does not apply to you, especially, especially if 
you can build a list of all the VID:PID's of the devices that your 
driver will service, then there is NO magic on-the-fly signing solution 
that you can or should use.


This is because there really are 2 signing operations that can apply:

One, which is MANDATORY, and which can only be accomplished after 
PURCHASING a certificate, for the .sys file. This is because the 
Microsoft security model does not let you self-sign your own drivers 
(unless you want to make all your users in self-test mode, but that is 
really a BAD IDEA, especially as it will make their system vulnerable to 
attacks).

The second one, which is optional, and which is the only one that can be 
accomplished on-the-fly, without PURCHASING an external signing 
certificate, is the signing of the driver package (.sys + .inf + .dll + 
any other files) to prevent an extra security prompt from being 
displayed to the users during installation.


But even for the second one, if you know all your VID:PID's, then your 
.inf and all the other files should be static, and therefore, the 
signing does not need to be accomplished on the fly, but should instead 
be done on your machine before distributing the driver package.


So, really, unless you are providing a generic driver, that can apply to 
any VID:PID, and want to avoid your users seeing an extra security 
prompt (which won't prevent them from installing the driver), you should 
read, understand and follow 
https://github.com/pbatard/libwdi/wiki/Signed-Driver-Walkthrough as it 
should contain all the informations you need.

Regards,

/Pete

Hi,

                I am trying to use the wdi-simple to install USB device
driver files consisting of .SYS and .DLL files.

These are dependent upon other USB driver files provided by microchip.

We would prefer not to get a driver or code signing certificate but use
libwdi to install these files (which are distributed along with the
application).

I understand that libwdi install documentation provides details of how a
signed custom driver can be installed and the walkthrough of how to sign the
drivers.

My question is, how can I use libwdi to sign the files on-the-fly and
install the custom SYS and DLL files using the PKI tools/features available
(without using a third-party code/driver signing certificate)? Is this
possible?

 

Warm Regards,

Deepak

 

[copying the list on the reply too]

-------- Original Message --------
Subject: 	Re: [libwdi-devel] installer_x86.exe from Zadig extract files
fails on Windows 7 32bit
Date: 	Tue, 12 Nov 2013 21:41:42 +0800
From: 	Ben Skelton
To: 	Pete Batard



Thank you Pete,

this has put me in the right direction and things are working beautifully.

I did need to edit embedder.h directly to set the paths to the DDK for
embedder.exe. Perhaps I could have done this in the ddk_build.cmd, but
the Windows stuff is too strange to me and the header was easier.

Very happy to have everything working. Thanks again,
--Ben

Hi Ben,

On 2013.11.11 08:53, Ben Skelton wrote:

     I hope that this is the correct forum to ask user questions.


Yes it is.

        I have downloaded Zadig and I am able to install drivers from the
     application. However, I need to be able to use the extracted files
     running installer_x86.exe


No you don't. installer_x86.exe is an *internal* libwdi application that
is not meant to be used as a standalone installer.

If you want a driver installer that you can run from the commandline,
then you should use one of wdi_simple or zadic, from the libwdi examples
directory, or create your own command line sample around libwdi.

     I can extract the files to the default location and then open a shell
     and call installer_x86.exe. The expected dialog asking to escalate
     permissions is shown and I select OK, or yes or whatever the option is.
     A window opens quickly running installer_x86.exe (something is
     displayed, but it flashes too fast for me to see what it says). After
     the window disappears, a window called Program Compatibility Assistant
     opens saying that the program might not have installed correctly.
     Choosing any of the options it presents does not help.


Again, that's because neither installer_x86.exe or installer_x64.exe are
meant to be run from the commandline.

     I have tried working with libwdi attempting to build it on my system.


Good. You will need that to use the commandline samples above.

     When I downloaded and installed WDK 7.1.0  (7600.16385), I saw that it
     installed files like ./wdf/x86/WdfCoInstaller01009.__dll. Running
     ./configure --with-ddkdir pointing to the WDK fails with configure
     cmplaining that it cannot find 01011 versions?


Add a --with-wdfver=1009 (or run ./configure --help)

The default configure is set to build for Windows Vista or later (in
which case you'll need the 1011 WinUSB files from the Windows 8 WDK).
If you need XP support, or use an earlier WDK, you need to use 1009.
See the note at the top of
https://github.com/pbatard/__libwdi/wiki/Install#wiki-__Configuration__Compilation 

<https://github.com/pbatard/libwdi/wiki/Install#wiki-Configuration__Compilation>

     WDK did not install these.


If you install the Windows 8 WDK (or the WDK redist - can't remember
right now), you will get these.

Regards,

/Pete

[copying the list, as I forgot to do so with earlier reply]

-------- Original Message --------
Subject: Re: [libwdi-devel] installer_x86.exe from Zadig extract files 
fails on Windows 7 32bit
Date: Mon, 11 Nov 2013 21:22:52 +0000
From: Pete Batard
To: Ben Skelton

Hi Ben,

On 2013.11.11 08:53, Ben Skelton wrote:
> I hope that this is the correct forum to ask user questions.

Yes it is.

>   I have downloaded Zadig and I am able to install drivers from the
> application. However, I need to be able to use the extracted files
> running installer_x86.exe

No you don't. installer_x86.exe is an *internal* libwdi application that
is not meant to be used as a standalone installer.

If you want a driver installer that you can run from the commandline,
then you should use one of wdi_simple or zadic, from the libwdi examples
directory, or create your own command line sample around libwdi.

> I can extract the files to the default location and then open a shell
> and call installer_x86.exe. The expected dialog asking to escalate
> permissions is shown and I select OK, or yes or whatever the option is.
> A window opens quickly running installer_x86.exe (something is
> displayed, but it flashes too fast for me to see what it says). After
> the window disappears, a window called Program Compatibility Assistant
> opens saying that the program might not have installed correctly.
> Choosing any of the options it presents does not help.

Again, that's because neither installer_x86.exe or installer_x64.exe are
meant to be run from the commandline.

> I have tried working with libwdi attempting to build it on my system.

Good. You will need that to use the commandline samples above.

> When I downloaded and installed WDK 7.1.0  (7600.16385), I saw that it
> installed files like ./wdf/x86/WdfCoInstaller01009.dll. Running
> ./configure --with-ddkdir pointing to the WDK fails with configure
> cmplaining that it cannot find 01011 versions?

Add a --with-wdfver=1009 (or run ./configure --help)

The default configure is set to build for Windows Vista or later (in
which case you'll need the 1011 WinUSB files from the Windows 8 WDK).
If you need XP support, or use an earlier WDK, you need to use 1009.
See the note at the top of
https://github.com/pbatard/libwdi/wiki/Install#wiki-Configuration__Compilation

> WDK did not install these.

If you install the Windows 8 WDK (or the WDK redist - can't remember
right now), you will get these.

Regards,

/Pete

I hope that this is the correct forum to ask user questions.  I am on 32bit
Windows 7 Home Premium.

 I have downloaded Zadig and I am able to install drivers from the
application. However, I need to be able to use the extracted files running
installer_x86.ee from the installer of my application.

I can extract the files to the default location and then open a shell and
call installer_x86.exe. The expected dialog asking to escalate permissions
is shown and I select OK, or yes or whatever the option is. A window opens
quickly running installer_x86.exe (something is displayed, but it flashes
too fast for me to see what it says). After the window disappears, a window
called Program Compatibility Assistant opens saying that the program might
not have installed correctly. Choosing any of the options it presents does
not help.

I have tried working with libwdi attempting to build it on my system. When
I downloaded and installed WDK 7.1.0  (7600.16385), I saw that it installed
files like ./wdf/x86/WdfCoInstaller01009.dll. Running ./configure
--with-ddkdir pointing to the WDK fails with configure cmplaining that it
cannot find 01011 versions? WDK did not install these.

Needless to say I am very confused and very much appealing to the list for
guidance.

regards,
--Ben

On 2013.06.10 03:58, Andre Renaud wrote:
> When I run wdi-simple, it all seems to execute ok

Can you try to display the full debug log from wdi-simple? It should 
provide some info from the Windows driver installation subsystem, with 
possible warnings.
Also, you mention that you only tried on XP. Could you please try on 
Vista or later? These platforms usually provide a much more 
comprehensive driver installation log.

Regards,

/Pete

> On 2013.06.06 01:01, Andre Renaud wrote:
>> I appreciate that I haven't supplied many details in this email, but
>> can anyone provide me with the minimal steps I'd need to create a
>> libusb-1.0 compatible program, and driver (using custom vid/pid),
>
> You mean driver package (inf + existing WinUSB files) rather than an
> actual driver, right?
> Also be mindful that the driver installation part, which libwdi can help
> with, is entirely separate from libusb. For instance, you cannot use
> libusb to detect a device that doesn't have a driver installed, in order
> to launch a libwdi based driver installation, if this is what you have
> in mind. Thus, you should consider that you will first need to run a
> libwdi application (similar to wdi-simple) before you can run anything
> libusb or libusbx based.

Yes, I mean the driver package. I've already got is working fine with
libusb-win32 if I manually install the unsigned driver (or use XP,
which doesn't object so much to unsigned drivers).

>> which can be relatively trivially installed using wdi-simple on both
>> 32 & 64-bit platforms? I'm trying to avoid the zadig tool at this
>> stage, as we have an existing NSIS installer that we'd like to push it
>> into in the long run.
>
> See https://github.com/pbatard/libwdi/wiki/Signed-Driver-Walkthrough
> It has an NSIS example with wdi-simple.

I've had a look there, and it seems reasonably straight forward. When
I run wdi-simple, it all seems to execute ok, but when I try and run
my test application against it afterwards, I get LIBUSB_ERROR_ACCESS.
If I manually install the drivers (ie: don't use wdi-simple, but
browse to them when I plug the hardware in), then it all seems to come
right.

I'm currently just trying to get it going on a 32-bit XP system,
before I start shuffling it up to the newer platforms.

Any ideas on what I might have missed?

Regards,
Andre

[CCing libwdi]

Hi Andre,

On 2013.06.06 01:01, Andre Renaud wrote:
> I appreciate that I haven't supplied many details in this email, but
> can anyone provide me with the minimal steps I'd need to create a
> libusb-1.0 compatible program, and driver (using custom vid/pid),

You mean driver package (inf + existing WinUSB files) rather than an 
actual driver, right?
Also be mindful that the driver installation part, which libwdi can help 
with, is entirely separate from libusb. For instance, you cannot use 
libusb to detect a device that doesn't have a driver installed, in order 
to launch a libwdi based driver installation, if this is what you have 
in mind. Thus, you should consider that you will first need to run a 
libwdi application (similar to wdi-simple) before you can run anything 
libusb or libusbx based.

> which can be relatively trivially installed using wdi-simple on both
> 32 & 64-bit platforms? I'm trying to avoid the zadig tool at this
> stage, as we have an existing NSIS installer that we'd like to push it
> into in the long run.

See https://github.com/pbatard/libwdi/wiki/Signed-Driver-Walkthrough
It has an NSIS example with wdi-simple.

Regards,

/Pete

Hi Chris,

On 2013.06.05 15:38, "Christopher Müller" wrote:
> Hello,
> I am using Windows 7 x64 and the zadig version 2.0.1.160 (but it happens
> in oder Versions too).
> I can start zadig as normal, but does not find my device. If i tick the
> option "List all devices", zadig crashes without an error.

I cannot replicate this issue on any of the machines I have (including 
Windows 7 x64 ones).

> As I have installed Visual Studio 2012, Windows asks if I want to debug
> the software.

Could you try to recompile libwdi from source (which will recompile 
Zadig) in Visual Studio 2012 then, and run Zadig in debug mode there?
It should tell what the issue is.

Please see 
https://github.com/pbatard/libwdi/wiki/Install#wiki-Configuration__Compilation

> If i do so, the only thing I could figure out is, that it has something
> to do with the ntdll.dll file.

Nah, this is usually just the generic error that Windows throws when an 
application crashes. If you can debuga recompiled version of Zadig in 
Visual Studio, it should tell where the issue lies.

Regards,

/Pete

Hi Ed,

On 2013.05.31 04:19, Ed Wegryn wrote:
> Trying to install the WinUSB driver for the RTL28232 dongle for SDR.
> Fails with error that the driver is not signed.  The signing options in
> Zadig are checked.  I see from the log that it claims it detected the
> system as Windows 7 – it is definitely Win8 64.  Could that be the
> problem?

Zadig was tested multiple times under Win 8 x64, and no problems were found.

> Other things to try?

Yes: Please run Zadig in advanced mode (Options -> Advanced Mode) and 
set the Log verbosity to debug (Options -> Log verbosity).

Then plug your device, try to install your driver again and send the 
full log.

Regards,

/Pete

Hi,
I've got an existing product for which we provide a Windows-based
firmware upgrade tool. This tool uses libusb-1.0 to talk to the
device, and perform the upgrade. This all works fine under XP, and
32-bit Windows 7, but as the driver is not signed it all falls apart
after that. I've had a bit of a look at using libwdi to fix the issue
up, and have basically not had any luck.

I appreciate that I haven't supplied many details in this email, but
can anyone provide me with the minimal steps I'd need to create a
libusb-1.0 compatible program, and driver (using custom vid/pid),
which can be relatively trivially installed using wdi-simple on both
32 & 64-bit platforms? I'm trying to avoid the zadig tool at this
stage, as we have an existing NSIS installer that we'd like to push it
into in the long run.

Regards,
Andre

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hello,</div>

<div>&nbsp;</div>

<div>I am using Windows 7 x64 and the zadig version 2.0.1.160 (but it happens in oder Versions too).</div>

<div>&nbsp;</div>

<div>I can start zadig as normal, but does not find my device. If i tick the option &quot;List all devices&quot;, zadig crashes without an error.</div>

<div>As I have installed Visual Studio 2012, Windows asks if I want to debug the software.</div>

<div>If i do so, the only thing I could figure out is, that it has something to do with the ntdll.dll file.</div>

<div>But it is the original one from Windows, no other version.</div>

<div>&nbsp;</div>

<div>Can you help me?</div>

<div>&nbsp;</div>

<div>Best regards</div>

<div>Chris</div></div></body></html>