Hi all,
I have a reproducible issue with my Hercules Stream 100: the device freezes completely at irregular intervals (the display stays stuck on its last state, no reaction to button presses anymore). The only way to get it working again is to briefly unplug the USB cable and reconnect it (a full power cycle of the device).
**Environment:**
- Device connected directly to the PC (no USB hub)
- USB 3 port (no USB 2 port available)
- OS: Windows 11 (Build 26100)
- Hercules Stream Control software version: 2.4.10 [01.53] - reported as up to date by the app, no updates available
- Device firmware version: 1.40 - also reported as up to date, no updates available
- Occurs independent of system uptime (already observed after less than 1 hour of PC uptime)
- No identifiable trigger: also occurred during plain YouTube playback (no ad transition, no pause/resume), so it's not specific to games, anti-cheat software, or audio session changes
**Diagnostics performed:**
1. Windows Event Viewer (System log, Kernel-PnP) shows no entries related to the Stream 100 device at the time of the freeze. Windows reports the device status as "OK" throughout.
2. Live USB status monitoring (polling every 2 seconds during a freeze) confirms: no status change, no disconnect/reconnect at the USB level while the device was frozen.
3. A full process memory dump of the Stream Control application was captured exactly at the moment of a freeze (via ProcDump) and analyzed in WinDbg (~*k, all thread stacks).
**Thread analysis result:**
All UI and worker threads (Qt event loops) are in a normal, healthy wait state - no software deadlock in the application. However, the threads belonging to the hsm_api_core_x64 component (the hardware communication layer) are sitting in WaitForSingleObjectEx, apparently waiting for a completion signal from the device that never arrives during the freeze:
```
ntdll!NtWaitForSingleObject
KERNELBASE!WaitForSingleObjectEx
hsm_api_core_x64!HSM_InternalCalls+0x82f1
```
**Assessment:** The application software is behaving correctly and is simply waiting for a response from the device that doesn't come. This points to a hang in the microcontroller/firmware of the Stream 100 itself, which becomes unreachable over the normal HSM communication layer until a physical power cycle is performed.
Since both software and firmware are already reported as up to date (2.4.10 [01.53] and 1.40 respectively), this doesn't seem to be something a simple update would fix.
Is anyone else experiencing this? And/or has anyone from Hercules already looked into it?
Happy to share the full WinDbg thread dump if it would help.
Thanks in advance!
