[TEST REQUEST] Windows Bluetooth LE build

Lubomir I. Ivanov neolit123 at gmail.com
Sun Sep 30 18:30:28 PDT 2018

On Mon, 1 Oct 2018 at 04:24, Dirk Hohndel <dirk at hohndel.org> wrote:
> > On Sep 30, 2018, at 6:20 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> >> this comes directly from the Windows GATT backend for writing descriptors.
> >> https://docs.microsoft.com/en-us/windows/desktop/api/bluetoothleapis/nf-bluetoothleapis-bluetoothgattsetdescriptorvalue
> >>
> >> ERROR_SEM_TIMEOUT can happen in a case where the service path is
> >> already opened in another process and this process has acquired an
> >> exclusive lock on the path.
> >> for instance, this can happen if i start BLE Explorer, connect to the
> >> same device and start changing values in a service. then run the
> >> qt-bt-discovery test app and try to do the same while both apps are
> >> running.
> >
> > OK, I don't have BLE Explorer. I do have the settings app open, though.
> > And I am not 100% sure if I maybe had Subsurface open as well - but
> > that shouldn't have been in BLE mode.
> >
> > Let me reboot again to make sure nothing else is running and try from there
> Rebooted. Nothing else running, just the cmd.exe
> Same output - semaphore timeout period has expired.

about reboot - i think if left for a while it hybernates and if
brought up, it's not a real shutdown or reboot as it restores state
from RAM.
StartMenu -> Restart should act like a real reboot.

do you have Shearwater software installed on this machine?
my other guess is that the software in question might be running a
background process or a service, that potentially can acquire a lock
on the GATT services.

GATT services are just paths in virtual filesystem, so services are
opened with the CreateFile API.


More information about the subsurface mailing list