Error libusb-windows backend

[reliassen]

Hi

I'm using libusb 1.0 Windows Backend on Windows 7 (32 bit). My problem is when calling libusb_get_device_list(), i get the following error on the device I've installed the libusb driver for (with zadig):

" libusb:error [cache_config_descriptors] could not access configuration descripto
r (dummy) for '\\.\USB#VID_090C&PID_1000#AA60000000000702': The I/O operation has been aborted because of either a thread exit or an application request. "

The PID and VID are the correct ones for my USB device, and I cannot understand why I get this error. I've searched the mailinglist and found a few mails where the same problem seem to be presented, but no solution. I have also tried on another computer (win 7 64bit) and get the same error.

I have attached my code.txt as well as the debug_libusb.txt. Im using Code::Blocks 10.05 with gcc-compiler if that is of any interest.

[Xiaofan Chen]

On Mon, Jun 27, 2011 at 9:42 PM, reliassen <[hidden email]> wrote:
> I'm using libusb 1.0 Windows Backend on Windows 7 (32 bit). My problem is
> when calling libusb_get_device_list(), i get the following error on the
> device I've installed the libusb driver for (with zadig):
>
> " libusb:error [cache_config_descriptors] could not access configuration
> descriptor (dummy) for '\\.\USB#VID_090C&PID_1000#AA60000000000702':
> The I/O operation has been aborted because of either a thread exit or an
> application request. "

Firstly make sure the device driver (WinUSB) is installed correctly
to the device.

Secondly it seems to me this device is a USB Mass Storage Device,
right? If that is the case, why do you want to use libusb for the device?

> The PID and VID are the correct ones for my USB device, and I cannot
> understand why I get this error. I've searched the mailinglist and found a
> few mails where the same problem seem to be presented, but no solution. I
> have also tried on another computer (win 7 64bit) and get the same error.
>
> I have attached my  http://libusb.6.n5.nabble.com/file/n4528429/code.txt
> code.txt  as well as the
> http://libusb.6.n5.nabble.com/file/n4528429/debug_libusb.txt
> debug_libusb.txt . Im using Code::Blocks 10.05 with gcc-compiler if that is
> of any interest.

You can see that the device is listed. You should use hex for the vid/pid.

Interfaces: 1 ||| libusb:debug [libusb_get_device_descriptor]
Number of possible configurations: 1  Device Class: 0
VendorID: 2316  ProductID: 4096

That is 0x090c:0x1000 and it is your device. Maybe you can do further
things with the device and see if it is okay or not. If it is okay, then the
error message does not really matter (it can probably change to warning).

--
Xiaofan

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard]

 From what I can see from the log, you are not using the latest version
of libusb for Windows, as the version you use still has HID support,
which was removed about 4 months ago (either that or you are using the
HID branch). Can you please run a test using the latest libusb-pbatard?

Also, since you are using an USB stick (QDI U2Disk 64 MB), can you try
running the xusb test program instead, so that we eliminate any
possibility of your application interfering.

You should be able to get a dump of the first bootblock of your USB
device, with logging, using the command: 'xusb -d 090c:1000'

Regards,

/Pete




------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[reliassen]

>Firstly make sure the device driver (WinUSB) is installed correctly
>to the device.

I'm not sure how to confirm if the driver is correctly installed, but i used the 'zadig.exe' and it said "installed successfully", for what it's worth..
I checked device manager and in "driverdetails" it lists 3 files: winusb.sys, WdfCoInstaller01009.dll and WinUsbCoInstaller2.dll, which i believe is correct.

>Secondly it seems to me this device is a USB Mass Storage Device,
>right? If that is the case, why do you want to use libusb for the device?

I'm using a USB Mass Storage Device for testing only, ultimately I'm to use it towards a GSM-modem.


>You can see that the device is listed. You should use hex for the vid/pid.

>Interfaces: 1 ||| libusb:debug [libusb_get_device_descriptor]
>Number of possible configurations: 1  Device Class: 0
>VendorID: 2316  ProductID: 4096

>That is 0x090c:0x1000 and it is your device. Maybe you can do further
>things with the device and see if it is okay or not. If it is okay, then the
>error message does not really matter (it can probably change to warning).

I'm not sure how i switch the logging to hex, if that's what you mean, but I am aware of it being logged in decimal. I have successfully written to the device, so libusb seem to manage to communicate correctly with it, but when I try to use i.e libusb_endpoint_descriptor::bEndpointAddress i get a segmentation fault and the program exits with 0xc0000005.

[reliassen]

>  From what I can see from the log, you are not using the latest version
> of libusb for Windows, as the version you use still has HID support,
> which was removed about 4 months ago (either that or you are using the
> HID branch). Can you please run a test using the latest libusb-pbatard?

I used git to retreive it about a week ago, so I can't see how it can
be outdated. Maybe i somehow managed to use the HID branch?
Is there an easy way to go back in that case?

> Also, since you are using an USB stick (QDI U2Disk 64 MB), can you try
> running the xusb test program instead, so that we eliminate any
> possibility of your application interfering.

I'm actually using a Corsair 2GB.
I tried the xusb test program and it seemed to work perfect, log attached.

I tested the program again now, and for some reason the error posted
in my original mail did not occur..
However, I continued testing and I still get the error I mentioned in
the reply to Xiaofan.
I have attached the "new" code, as well as the debug log for it.

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard]

On 2011.06.27 19:43, Roger Eliassen wrote:
>>   From what I can see from the log, you are not using the latest version
>> of libusb for Windows, as the version you use still has HID support,
>> which was removed about 4 months ago (either that or you are using the
>> HID branch). Can you please run a test using the latest libusb-pbatard?
>
> I used git to retreive it about a week ago, so I can't see how it can
> be outdated. Maybe i somehow managed to use the HID branch?

Looks like this is what happened then.
Please issue the following:
   git clean -fdx
   git checkout master
and then rebuild libusb from the master branch and let us know if you
still see the issue.

> I tried the xusb test program and it seemed to work perfect, log attached.
> I tested the program again now, and for some reason the error posted
> in my original mail did not occur..
> However, I continued testing and I still get the error I mentioned in
> the reply to Xiaofan.

So does that mean that xusb always work then?

If that is the case, then it looks like you may be doing something in
your test application that causes the I/O operation to abort (though I
don't see anything obvious from the code from having had a quick look at
it).

I'll see if I can use your code and reproduce the error, but it could
take a little while before I do so.

Regards,

/Pete

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[reliassen]

> Looks like this is what happened then.
> Please issue the following:
>   git clean -fdx
>   git checkout master
> and then rebuild libusb from the master branch and let us know if you
> still see the issue.


I'm not very familiar with git, and the commands you gave me kind of
failed. I use the latest MSysGit, and with "git clean -fdx" i got
several "Unlink of file 'filepath/file' failed." I ran the program as
Administrator and still got the same errors.
Tried the "git checkout master" (even though the above failed) and got
"error: pathspec 'master' did not match any file(s) known to git. I
ran the commands after cd to msysgit installdir.


> So does that mean that xusb always work then?

It seems so now yes.

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard]

On 2011.06.27 22:35, Roger Eliassen wrote:
> I'm not very familiar with git, and the commands you gave me kind of
> failed. I use the latest MSysGit, and with "git clean -fdx" i got
> several "Unlink of file 'filepath/file' failed." I ran the program as
> Administrator and still got the same errors.
> Tried the "git checkout master" (even though the above failed) and got
> "error: pathspec 'master' did not match any file(s) known to git. I
> ran the commands after cd to msysgit installdir.

OK, then don't bother with branches. Just delete or rename the whole
libusb-pbatard directory, and clone a new one with:

git clone git://git.libusb.org/libusb-pbatard.git

That's all you need to do have the latest source.

Regards,

/Pete


------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Tue, Jun 28, 2011 at 1:44 AM, reliassen <[hidden email]> wrote:

>>You can see that the device is listed. You should use hex for the vid/pid.
>
>>Interfaces: 1 ||| libusb:debug [libusb_get_device_descriptor]
>>Number of possible configurations: 1  Device Class: 0
>>VendorID: 2316  ProductID: 4096
>
>>That is 0x090c:0x1000 and it is your device. Maybe you can do further
>>things with the device and see if it is okay or not.
>
> I'm not sure how i switch the logging to hex, if that's what you mean, but I
> am aware of it being logged in decimal.

Know, I do not mean the log but rather your program. You should try to
output in hex to make things easier for you and others.

        cout<<"VendorID: "<<desc.idVendor<<"  ";
        cout<<"ProductID: "<<desc.idProduct<<endl;

> I have successfully written to the
> device, so libusb seem to manage to communicate correctly with it, but when
> I try to use i.e libusb_endpoint_descriptor::bEndpointAddress i get a
> segmentation fault and the program exits with 0xc0000005.

I do not know C++ so probably Pete can help you better here.

--
Xiaofan

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Tue, Jun 28, 2011 at 10:11 AM, Xiaofan Chen <[hidden email]> wrote:
> I do not know C++ so probably Pete can help you better here.
>

Anyway, the code is obvious not correct. You are listing all the USB device
and some of the device may not have the number of interfaces or altsettings or
endpoints you hard-coded. So it is nature the program crashes.

You should look at the xusb.c example and learn from the function
int test_device(uint16_t vid, uint16_t pid).

--
Xiaofan

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Michael Plante]

Roger Eliassen wrote:
>> I'm not very familiar with git, and the commands you gave me kind of
>> failed. I use the latest MSysGit, and with "git clean -fdx" i got
>> several "Unlink of file 'filepath/file' failed." I ran the program as
>> Administrator and still got the same errors.

Git can fail to remove files if they're open (on Windows, anyway).  I don't
remember the exact error message, though.



>> Tried the "git checkout master" (even though the above failed) and got
>> "error: pathspec 'master' did not match any file(s) known to git. I
>> ran the commands after cd to msysgit installdir.

That's really weird.  Maybe something in .git/ got corrupted.



Michael


------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard]

Hi Roger,

Please try the program attached. I see nothing wrong with libusb on my
platform when testing against an USB key. On the other hand, a lot of
problems will arise from using fixed values for the maxima in your 3 for
loops, when you should be using the maximum values you get from the USB
device itself. Also, make sure you always check the return values of
your libusb calls: libusb_get_config_descriptor must be checked, as it
returns an error for root hubs.

Below is the output I get on my platform, with an heterogeneous set of
devices plugged in, including an USB key. The "config descriptor"
errors, which I added, are expected, as we can't read those from the
root hubs. Everything else behaves as expected.

Regards,

/Pete

----------------------------------------------------------------------

14 Devices in list.
Number of possible configurations: 1  Device Class: 0  VendorID: 8086
ProductID: 2830
failed to get config descriptor
Number of possible configurations: 1  Device Class: 0  VendorID: 8086
ProductID: 2834
failed to get config descriptor
Number of possible configurations: 1  Device Class: 0  VendorID: 8086
ProductID: 2831
failed to get config descriptor
Number of possible configurations: 1  Device Class: 0  VendorID: 8086
ProductID: 2832
failed to get config descriptor
Number of possible configurations: 1  Device Class: 0  VendorID: 8086
ProductID: 2835
failed to get config descriptor
Number of possible configurations: 1  Device Class: 0  VendorID: 8086
ProductID: 283a
failed to get config descriptor
Number of possible configurations: 1  Device Class: 0  VendorID: 8086
ProductID: 2836
failed to get config descriptor
Number of possible configurations: 1  Device Class: 0  VendorID: 204
ProductID: 6025
Interfaces: 1 ||| Number of alternate settings: 1 | Interface Number: 0
| Number of endpoints: 2 | Descriptor Type: 5 |
EP Address: 1 | Descriptor Type: 5 | EP Address: 81 |


Number of possible configurations: 1  Device Class: 9  VendorID: 424
ProductID: a700
Interfaces: 1 ||| Number of alternate settings: 2 | Interface Number: 0
| Number of endpoints: 1 | Descriptor Type: 5 |
EP Address: 81 | Interface Number: 0 | Number of endpoints: 1 |
Descriptor Type: 5 | EP Address: 81 |


Number of possible configurations: 1  Device Class: 9  VendorID: 45e
ProductID: 288
Interfaces: 1 ||| Number of alternate settings: 1 | Interface Number: 0
| Number of endpoints: 1 | Descriptor Type: 5 |
EP Address: 81 |


Number of possible configurations: 1  Device Class: 0  VendorID: 45e
ProductID: 289
Interfaces: 1 ||| Number of alternate settings: 1 | Interface Number: 0
| Number of endpoints: 2 | Descriptor Type: 5 |
EP Address: 81 | Descriptor Type: 5 | EP Address: 2 |


Number of possible configurations: 1  Device Class: 0  VendorID: 46d
ProductID: c03e
Interfaces: 1 ||| Number of alternate settings: 1 | Interface Number: 0
| Number of endpoints: 1 | Descriptor Type: 5 |
EP Address: 81 |


Number of possible configurations: 2  Device Class: 0  VendorID: 4d8
ProductID: 33
Interfaces: 1 ||| Number of alternate settings: 1 | Interface Number: 0
| Number of endpoints: 2 | Descriptor Type: 5 |
EP Address: 81 | Descriptor Type: 5 | EP Address: 1 |


Number of possible configurations: 1  Device Class: ef  VendorID: 1234
ProductID: 1
Interfaces: 2 ||| Number of alternate settings: 1 | Interface Number: 0
| Number of endpoints: 2 | Descriptor Type: 5 |
EP Address: 1 | Descriptor Type: 5 | EP Address: 81 | Number of
alternate settings: 1 | Interface Number: 1 | Number of
endpoints: 2 | Descriptor Type: 5 | EP Address: 2 | Descriptor Type: 5 |
EP Address: 82 |
------------------------------------------------------------------------

#include <iostream>
#include "libusb.h"
using namespace std;

void printdev(libusb_device *dev); //prototype of the function

int main() {
        libusb_device **devs; //pointer to pointer of device, used to retrieve a list of devices
        libusb_context *ctx = NULL; //a libusb session
        int r; //for return values
        ssize_t cnt; //holding number of devices in list
        r = libusb_init(&ctx); //initialize a library session
        if(r < 0) {
                cout<<"Init Error "<<r<<endl; //there was an error
                                return 1;
        }
        libusb_set_debug(ctx, 3); //set verbosity level to 3, as suggested in the documentation
        cnt = libusb_get_device_list(ctx, &devs); //get the list of devices
        if(cnt < 0) {
                cout<<"Get Device Error"<<endl; //there was an error
        }
        cout<<cnt<<" Devices in list."<<endl; //print total number of usb devices
                ssize_t i; //for iterating through the list
        for(i = 0; i < cnt; i++) {
                                printdev(devs[i]); //print specs of this device
                }
                libusb_free_device_list(devs, 1); //free the list, unref the devices in it
                libusb_exit(ctx); //close the session
                return 0;
}

void printdev(libusb_device *dev) {
        libusb_device_descriptor desc;
        int r = libusb_get_device_descriptor(dev, &desc);
        if (r < 0) {
                cout<<"failed to get device descriptor"<<endl;
                return;
        }
        cout<<"Number of possible configurations: "<<(int)desc.bNumConfigurations<<"  ";
        cout<<"Device Class: "<<(int)desc.bDeviceClass<<"  ";
        cout<<"VendorID: "<<hex<<desc.idVendor<<"  ";
        cout<<"ProductID: "<<hex<<desc.idProduct<<endl;
        libusb_config_descriptor *config;
        if (libusb_get_config_descriptor(dev, 0, &config) != LIBUSB_SUCCESS) {
                cout<<"failed to get config descriptor"<<endl;
                return;
        }
       
        cout<<"Interfaces: "<<(int)config->bNumInterfaces<<" ||| ";
        const libusb_interface *inter = NULL;
        const libusb_interface_descriptor *interdesc = NULL;
        const libusb_endpoint_descriptor *epdesc = NULL;

        for(int i=0; i<config->bNumInterfaces; i++) {
                inter = &config->interface[i];
                cout<<"Number of alternate settings: "<<inter->num_altsetting<<" | ";

                for(int j=0; j<inter->num_altsetting; j++) {
                        interdesc = &inter->altsetting[j];
                        cout<<"Interface Number: "<<(int)interdesc->bInterfaceNumber<<" | ";
                        cout<<"Number of endpoints: "<<(int)interdesc->bNumEndpoints<<" | ";

                        for(int k=0; k<interdesc->bNumEndpoints; k++) {
                                epdesc = &interdesc->endpoint[k];
                                cout<<"Descriptor Type: "<<(int)epdesc->bDescriptorType<<" | ";
                                cout<<"EP Address: "<<(int)epdesc->bEndpointAddress<<" | ";
                        }
                }
        }
        cout<<endl<<endl<<endl;
        libusb_free_config_descriptor(config);

}

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[reliassen]

> Please try the program attached. I see nothing wrong with libusb on my

> platform when testing against an USB key. On the other hand, a lot of
> problems will arise from using fixed values for the maxima in your 3 for
> loops, when you should be using the maximum values you get from the USB
> device itself. Also, make sure you always check the return values of your
> libusb calls: libusb_get_config_descriptor must be checked, as it returns an
> error for root hubs.
>
> Below is the output I get on my platform, with an heterogeneous set of
> devices plugged in, including an USB key. The "config descriptor" errors,
> which I added, are expected, as we can't read those from the root hubs.
> Everything else behaves as expected.

Oh god, I now realized i attached a temporary testing code. The one I
were supposed to show you is attached now.
The code seems to be identical to the changes you did though.
I will do more testing tomorrow morning, and let you know what
happens. Sorry for the mixup..

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[reliassen]

On Thu, Jun 30, 2011 at 12:27 AM, Roger Eliassen <[hidden email]> wrote:

>> Please try the program attached. I see nothing wrong with libusb on my
>> platform when testing against an USB key. On the other hand, a lot of
>> problems will arise from using fixed values for the maxima in your 3 for
>> loops, when you should be using the maximum values you get from the USB
>> device itself. Also, make sure you always check the return values of your
>> libusb calls: libusb_get_config_descriptor must be checked, as it returns an
>> error for root hubs.
>>
>> Below is the output I get on my platform, with an heterogeneous set of
>> devices plugged in, including an USB key. The "config descriptor" errors,
>> which I added, are expected, as we can't read those from the root hubs.
>> Everything else behaves as expected.

After taking a closer look at the code you supplied, I realize that
what makes the difference (not getting errors) is the checking of
"libusb_get_config_descriptor". Thanks for pointing that out.

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel