Hang/crash at device detection when OS != Linux (Was: Cant Install windows pre-built version)

[Seraph2101]

hey, i have an error when i tried to install for the first time, it says "connection failed" how can i solve this problem

i had a linux version installed on my VirtualBox on my Lubuntu and it works fine, but it's kinda annoying to use because it takes so long to boot, so i want to try the windows version

thank you for your help : )

[Ho-Ro]

Was this related to issue #301 on openhantek?
Please check this info.

[seraphie21]

hey, i'm the same person, and yeah, because i forget about my id, i make a new one, and i just remembered the old id, so yeah i closed this one, sorry for the confusion

[Ho-Ro]

Hi, one remark regarding your comment in the other issue 301 thread:

hey, i've already tried that, and i just read raxis13's success report, and apparently it just work with the build 68, but for the newer version it always failed, so yeah, thank you for your help and time, hopefully there's a new build for window ...

Please provide a more detailed description of "it always failed" so that other Windows user may provide a working solution. I don't have a native Win install, I check from time to time on my old virtual win7, but I'm not able to debug in depth. Another solution would be to build your own version from source, please have a look how it is done by my CI system appveyor (config is there), this is where my win builds come from.
It would be great anyway if one or more volunteers for Windows step in who support build and install as my target is mostly Linux.

[seraphie21]

Hey, sorry for the late reply. Here's the story :
For the other build version (Especially for the newest build 194) except build 68 just straight up not working, after my clean install on WinUSB with Zadig.exe, i replug my scope and check if the scope is recognized as "Universal Serial Bus Device" under "DSO-6022" name or not, if not and it recognized as "Hantek6022" or still the original driver, i try to uninstall the device again until there's an "Other Device" pop-up at the device manager with yellow exclamation mark (Pict 3), and then i reinstall the WinUSB driver using Zadig.exe and replug my scope.

After the computer recognized the scope as an "Universal Serial Bus Device" under name "DSO-6022"(Pict 2), i tried to launch the pre-built "build 194" and after the first command prompt start-up, and "select device" windows pop-up, it recognized the device, but it says "connection failed"(Pict 4).

But with the build 68, after the "select device" windows pop-up, it gonna says "upload in progress" at the device selecting menu (Pict 1), after a couple second, it says "device ready" and i can use it (Pict 2)

Here's a couple screenshot showing the error and the success

1. After WinUSB driver installed, Open Hantek Build 68 First Start-Up
   

2. Device Ready To Use, Open Hantek Build 68
   

3. Device Manager After Uninstalling Original Hantek 6022BE Driver
   

4. OpenHantek Build 194 Failed to Connect to The Scope
   

Hopefully it's useful the other, and yes. i'm planning to check all the build after the build 68 and i'll post the result here or on the new post

[Ho-Ro]

OK, I see the reason, it's an unsupported command, I will ignore the error and carry on with upload. I'll fix it tomorrow evening. Thx for narrowing down the issue.

[iss000]

Just to report the same issue with macOS 10.15.1. (build from current sources)
and NO problem with Fedora (kernel version 5.3.11-200.fc30.x86_64).
Thanks for looking at it.

[Ho-Ro]

It's a different implementation of libusb that doesn't support the auto detach of kernel driver on certain systems. Thx for your comment.

[Ho-Ro]

It was already solved for FreeBSD with an #ifndef __FreeBSD__ :

OpenHantek6022/openhantek/src/usb/uploadFirmware.cpp

Line 41 in 3a8b0c3

#ifndef __FreeBSD__

It should be treated more generally. What I collected so far:

• The function libusb_set_auto_detach_kernel_driver(handle, 1) exist on Linux and works as expected. 👍
• The function exists on FreeBSD and returns always LIBUSB_SUCCESS (= 0), but triggers an error during the successive libusb_claim_interface(handle, 0); (wrong or missing rights?) 👎
• The function does exist on MacOSX and Windows, but has no effect except returning LIBUSB_ERROR_NOT_SUPPORTED (= -12), because these OSs do not support the detaching. 👎

For me, the best solution would be to replace the #ifndef __FreeBSD__ with #ifdef __linux__.
I will review and report on this later in the day.

[tspspi]

As far as I remember the problem with FreeBSD was not missing rights but reference counting not working as expected (but that's just an guess after experimenting with libusb for a few minutes). The problem was definitely that successive accesses to the list of devices went into undefined memory areas after the first release even after reference count on the list has been incremented.

EDIT: I think i can rule out problems with permissions - tried on a clean system with root user, security.bsd.suser_enabled=1 and no mac policies in place. The release lead to an access into an already free'ed memory location.

[iss000]

After changing line 41 as suggested (i.e replace the #ifndef FreeBSD with #ifdef linux) no more error displayed under MacOSX and it seams that everything works just fine.

[Ho-Ro]

Good info, I've just detected why the system sometimes hangs during firmware upload if there are other high speed devices plugged in, (therefore the message "if it takes more than 30 seconds...").
If this is solved I will push the next changes, probably tomorrow.
OK, here is my analysis:
This was caused by this id

OpenHantek6022/openhantek/src/usb/finddevices.cpp

Line 45 in 0b77b94

const UniqueUSBid USBid = USBDevice::computeUSBdeviceID( device );

that wasn't unique (in original it reported the USB port(s) where the device was plugged in). But on uploading the firmware the ports didn't change and there was a race condition if the release/re-enumeration with new VID/PID was too fast, the program could not detect that the device disappeared and came back.
Now the unique ID uses bus, port, VID, PID and FW version and is almost unique unless you have two identical devices on the same bus and they use the same port number because one is directly connected to e.g. port 1 and the other is connected to port 1 of a hub that hangs on port 2 of the bus. At the moment I can live with that limitation.

[Ho-Ro]

@iss000 @tspspi @seraphie21
Please have a look at

OpenHantek6022/openhantek/src/usb/finddevices.cpp

Line 82 in 0b77b94

libusb_free_device_list( deviceList, true );

If the system crashes, try changing true to false.

[seraphie21]

hey, since i'm using pre-built version, where can i find that code

[Ho-Ro]

Download ZIP gives you the source code of the latest commit.
EDIT: Follow the build instructions (they have to be updated, your input is welcome), and get the best overview by checking out how appveyor does it.

[seraphie21]

so i need to rebuilt the source, i'll try when i have the time, thanks :)

[tspspi]

Oh my how could I've been that blind. Yep just tried setting unref_devices on the call to libusb_free_device_list to false of course also solves the issue on FreeBSD.

[Ho-Ro]

@seraphie21 you can always get the latest binary build. If you want to go back in time there's also the history available. Please check if your windows issue is solved now.

[seraphie21]

hey, sorry for long response, i already tried the newest build, it works smoothly, thanks a lot for the help :D, anyways, i'd like to see the x100 or x1000 features, and thank you so much for helping

[seraphie21]

Ho-Ro moved this to #41

hey, i just found out something that quite bothering me, if i minimize the window, then hovering my cursor at the taskbar icon of the app, it will show previous menu that i open in the app, although i already close it.

[Ho-Ro]

Thx for reporting the Windows stratus.
To summarise the status of this construction:

#if defined __FreeBSD__
    libusb_free_device_list( deviceList, false ); // free the list but don't unref the devices
#else
    // TODO check if this crashes on MacOSX, Windows
    // TODO check if change true -> false solves it
    // move it up by appending " || defined __YOUR_OS__" to the line "#if defined ..."
    libusb_free_device_list( deviceList, true ); // linux and some other systems unref also the USB devices
#endif

Linux 👍
FreeBSD 👍
Windows 👍
MacOSX ❓
@iss000, @mpietruschka, @ra1nb0w can you give a positive (or also a negative) MacOSX feedback please to finally close this issue. I wouldn't expect a crash, since the call below was operational from the beginning, but without "#ifdef-ing" and checking the return code of this line, because the call is not supported by all other operating systems and returns LIBUSB_ERROR_NOT_SUPPORTED:

OpenHantek6022/openhantek/src/usb/uploadFirmware.cpp

Line 43 in a7c9eb6

status = libusb_set_auto_detach_kernel_driver( handle, 1 );

#ifdef __linux__
    // Detach kernel driver, reported to lead to an error on FreeBSD, MacOSX and Windows
    status = libusb_set_auto_detach_kernel_driver( handle, 1 );
    if ( status != LIBUSB_SUCCESS && status != LIBUSB_ERROR_NOT_SUPPORTED ) {
        errorMessage = TR( "libusb_set_auto_detach_kernel_driver() failed: %1" ).arg( libusb_error_name( status ) );
        libusb_close( handle );
        return false;
    }
#endif

[iss000]

I confirm it works under macOSX Catalina 10.15.1 (latest update) with #ifdef __linux__
Well done!

---

PS: One another thing I just discovered: immediately after start (probes attached to the generator) start clicking on the UpDown control of 'Samplerate' -> values start to change after 5-6 clicks. I'll not open new issue because I don't know how to describe better the problem, maybe the value list is still not synchronized with the index of the selected item.

[Ho-Ro]

Linux 👍
FreeBSD 👍
Windows 👍
MacOSX 👍

Thx for the last missing 👍, I can close this long issue :)

Regarding your "mini-issue" above: Yes, this is a small annoyance that I also noticed some time ago and keep in mind, but hadn't time to deep dive. Maybe it is caused by the fixed number of samplerate values in the spinbox, but we use only a subsection of them depending on the timebase and "click" over the not sufficient values silently.