Hey Jakub, Thanks for the additional details. I can confirm that I've seen some suspicious behavior from with UHD 3.14.1.0 binary on my machine since you sent this in. It seems like libusb 1.0.22 causes crashing behavior with uhd_find_devices. I rolled this back to libusb 1.0.21 and things seem to have improved, but I need to do some more testing. I'd like to know if you have similar results.
I'm going to get a fresh Windows image up and running today and see if I can't characterize this any better on my end. I may reach back out to you offline if there are any setup details we need to work through. Otherwise, I'll try to post an update / resolution here once I have it. Sam On Fri, Aug 30, 2019 at 6:13 AM Jakub Rybka <ry...@mtit.org> wrote: > Sam, > > I do have drivers installed on Windows 10 machine. I can manage the code > to run by modifying UHD driver (commenting out libusb_unref_device), and > my radio is then properly found. What is bugging me, that even original > Ettus compiled UHD installer from files.ettus.com fails. If there are no > UHD devices connected, uhd_find_devices.exe just shows "No UHD Devices > Found". Under Windows, there is no such message. The program just fails, > and does NOT write this message. I tested it on multiple computers > running Windows 10 LTSC and Windows 10 Professional 1903. > > Best regards, > Jakub > > Dne 2019-08-29 16:54, Sam Reiter napsal: > > Jakub, > > > > I'll look into this. The issues you're reporting with the binary are > > probably what I'll want to try to reproduce first. Can you be more > > specific as to the behavior of your system during the crash you're > > reporting? Screenshots would be useful if there are dialogs present > > during / after the crash. > > > > Beyond that, it sounds like you've had this system up and running with > > a B series in the past, right? This would imply that you've installed > > the Windows USB driver successfully: > > > http://files.ettus.com/manual/page_transport.html#transport_usb_installwin > > and that you can see the B series device in the Windows Device manager > > when connected. > > > > Sam > > > > On Thu, Aug 29, 2019 at 3:11 AM Jakub Rybka via USRP-users > > <usrp-users@lists.ettus.com> wrote: > > > >> Hello, > >> > >> I have encountered a strange problem using UHD 3.13 and 3.14 > >> releases > >> under Windows. I am using X310 USRPs for some time now, and didn't > >> have > >> any problem with them. My development environment is Windows 10, > >> VS2017, > >> boost 1.67 and UHD versions 3.13 and 3.14. When I tried to use my > >> software with B200mini USRP device, UHD completely crashed. I did > >> some > >> investigation, and found out, that even original Ettus Research > >> binary > >> distribution crashes on USB devices. > >> > >> Even this tiny bit of code crashes when compiled and run under > >> Windows: > >> > >> int UHD_SAFE_MAIN(int argc, char *argv[]) > >> { > >> std::string hint = ""; > >> uhd::device_addrs_t addrs; > >> > >> addrs = uhd::device::find(hint, uhd::device::ANY); > >> } > >> > >> If you want to verify this does not work with USB devices at all, > >> just > >> run uhd_find_devices from UHD 3.14.1.0 binary release on bus series > >> USRPs. I did use > >> > > > http://files.ettus.com/binaries/uhd/uhd_003.014.001.000-release/Windows-10-x64/uhd_3.14.1.0-release_Winx64_VS2017.exe > >> > >> I did trace the problem with uhd::device::find to destructor > >> ~libusb_device_impl(void), which calls libusb_unref_device. This > >> should > >> be called after libusb_free_device_list in libusb_device_list_impl, > >> but > >> when tracing the code, strange jumps occurs, and I suspect devices > >> are > >> unreferenced in destructor before they can be freed (but not > >> unreferenced) in libusb_free_device_list. This works perfectly under > >> > >> linux, but not in Windows. It can be some compiler optimization > >> problem. > >> > >> This is not the only problem in UHD, just *any* attempts to use USB > >> devices fails. uhd::usrp::multi_usrp::make for example runs, but > >> throws > >> some 4 exceptions. > >> > >> More strangely, I suspect there is more to Windows UHD trouble. If I > >> do > >> this: uhd::device_addr_t addr; code fails with exception, with no > >> USRP > >> devices connected. It is very similar to > >> > > > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-July/057279.html > >> > >> . > >> > >> Does anyone have any clue how to resolve this issue ? I am using > >> linux > >> as primary development OS with UHD, and I am not as fluent with MSVC > >> > >> compilers. I am using Windows just to compile Windows version of my > >> USRP > >> software. > >> > >> Variants tested: > >> > >> Visual Studio 2015 and Visual Studio 2017, in their latest patch > >> versions. > >> Boost 1.67, 1.68, 1.69 and 1.70 > >> libusb 1.0.22 and 1.0.23rc3 > >> debug and release, static and dynamic, and static and dynamic > >> runtime > >> versions of all three libraries. > >> > >> None does work. > >> > >> Best regards, > >> > >> Jakub Rybka > >> > >> _______________________________________________ > >> USRP-users mailing list > >> USRP-users@lists.ettus.com > >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
