The picoscope is directly connected to one of the USB ports on the computer. It is a very new desktop computer with oodles of RAM and CPU. It also happens whether I choose one of the USB 3.0 or one of the 2.0 ports on the host (it has both).
Other than mouse and keyboard, the device has one other USB input which is a low data-rate device (operates over a serial->usb->virtual serial connection @ 115200).
As more info, I'm free-acquiring at 4MS/s, and asking for the latest samples every 13-30ms. This should run for up to several days at a time. I have desperately tried to find a repeatable setup to recreate the problem but cannot. I have also tried using 3 different 3204a's (we use them in a product, so have a number of them as spares).
Although it is not desired, it would be acceptable to somehow programattically reset the picoscope (thus incurring a delay of about 6-9 seconds of data acquisition). The typical close/open cycle doesn't always work though, as evidenced by my log files. My program also handles error-states properly if I manually unplug the picoscope and plug it back in (without restarting the software), so I feel pretty good about my state-resolution code.
I will say despite this issue, I am much much happier with the 3000a API over the 2203 api