The potential cause (very probable):
If the customer's firmware application uses STOP mode, IDLE mode, or turns off the TAP controller (to make use of the corresponding GPIO pins), the hardware will stop responding and that will cause the IDE to indicate the debugger/application has stopped responding. If the devices go into low power mode soon after the application starts, it might appear that the chip or the dongle is a door stop (dead). The fact is... the chip is the door stop. The dongle will live to talk to another chip. It is very difficult, but not impossible, to recover a chip that has the "early STOP mode use" disease. It is very easy to "shoot ourselves in the foot" when using STOP mode early in the code flow, so be mindful of this when coding.
If customers use low power modes, they should understand and be acutely aware of the need to disable low power features in the firmware code while using the debugger. Once the application works, the customer can re-enable the low power code. The Rowley IDE has Debug and Release configurations and built-in defines can be used to do this automatically, based on the configuration.
Another possibility (much less probable):
We have seen in app flash loader applications that confused the Rowley IDE by blowing away code that Rowley had just loaded and that it could not find when it tried to verify the code. Rowley has debugger helper routines in the startup code and if a flash routine blows these helpers away, debugging might be erratic. This would probably not appear to be a dead dongle. It would more likely manifest itself as a verify error that occurs every time after loading the application.