Back in the day there was also a huge security hole which could be exploited with the xwd command. If you knew the dns name of a terminal you could get a screendump from it. It was not secured at all.
I worked on a Java program that was a point of sales terminal. All the registers were reasonably beefy linux machines that ran a Java Web Start application and it worked well... except when it didn't.
Sometimes it had threading deadlocks and that was a pain to debug. In particular, we didn't know where it came from. So we installed a handler on ctl-alt-delete that would find the Java process running and do a thread dump from that (so we could find the methods that were locked) and also did a xwd to capture the screen to see what was happening. Sometimes we were able to pick out "this modal alert window spawned 100x copies of itself" by recognizing an unnaturally thick border around it. Just seeing what the state that the register was in was useful too.
The xwd and thread dumps where then stored in a folder that was sent back as part of nightly reports back to the central office where we'd look at them the next morning.
On one hand it was a bit clunky, on the other hand it really beat trying to get a bug report from cashiers working the registers in a timely manner - they just had to remember to do a ctl-alt-delete rather than power cycling the machine and we'd get it reported back to us automatically.
I worked on a Java program that was a point of sales terminal. All the registers were reasonably beefy linux machines that ran a Java Web Start application and it worked well... except when it didn't.
Sometimes it had threading deadlocks and that was a pain to debug. In particular, we didn't know where it came from. So we installed a handler on ctl-alt-delete that would find the Java process running and do a thread dump from that (so we could find the methods that were locked) and also did a xwd to capture the screen to see what was happening. Sometimes we were able to pick out "this modal alert window spawned 100x copies of itself" by recognizing an unnaturally thick border around it. Just seeing what the state that the register was in was useful too.
The xwd and thread dumps where then stored in a folder that was sent back as part of nightly reports back to the central office where we'd look at them the next morning.
On one hand it was a bit clunky, on the other hand it really beat trying to get a bug report from cashiers working the registers in a timely manner - they just had to remember to do a ctl-alt-delete rather than power cycling the machine and we'd get it reported back to us automatically.