diagnosing unexplained openbox unresponsiveness

For the past few months, I have experienced periodic unresponsiveness of openbox, the same problem described in this post. My setup is linux 4.9.0-3-amd64, debian 9.0, openbox 3.6.1. As described in the linked post, the session will frequently (every few days) become unresponsive to certain keyboard and mouse inputs. The mouse cursor can still be observed to move across the screen and focus can be transferred to different windows, but modification of windows (movement, minimization, maximization, closing) or use of them (clicking on buttons within the window) are no longer possible (selecting text in an open xterm window by clicking and dragging is still possible). Keyboard input also fails to register: one cannot type in an open xterm emulators, nor do key bindings work (e.g., Alt+tab, custom bindings set in $HOME/.config/openbox/rc.xml). Windows still update their contents (e.g., progress of an ongoing rsync job is dynamically updated) and any jobs that were running continue to run, but interaction with the system by keyboard and mouse is severely limited. Two forms of keyboard input have been found to still work. Firstly, after the display locks (I have slock enabled with a timer by the presence of xautolock -time 60 -locker sloc in ~/.config/openbox/autostart), the screen locker accepts a password and allows resumption of the otherwise frozen X11 session. Secondly, as suggested in this answer to the linked post, Ctrl+Alt+F1 to Ctrl+Alt+F6 works (though Ctrl+Alt+Backspace does not), and I am able to login and startx from the new console, at which point I have a frozen X11/openbox session in the first X11 console (Ctrl+Alt+F1) and a functioning one in the second (Ctrl+Alt+F2). Eventually, the second X11 instance will freeze and interestingly, when this happens, the first instance unfreezes and I am able to work there again. Thus, simply alternating between two instances that periodically freeze and reciprocally unfreeze allows me to avoid having to hard-reboot the system, which was the solution before finding that Ctrl+Alt+F2-6 permits a form of system rescue (though any process with a GUI in the frozen session has to be restarted in the new session if I wish to continue using it).

I have been unable to find the cause of this problem and would appreciate any help in diagnosing it. I have been running debian/openbox for years, and this problem only happened in the last few months. Checking top after X11 freezes does not reveal any obvious problems; dmesg and /var/log/messages are unrevealing as well. I would like to find the source of the problem to prevent it from recurring.