About Window Procedures - Win32 apps | Microsoft Learn]
The template would add a subclass procedure to every procedure which is a window, and then that could be sent off to debugview to ultimately save in a log file. The Template would be a starting point to capture as much or as little of the windows messages that you need to help isolate whats happening.
Debugview++ has a command line version so when your app starts, and both accept command line input so you could call debugview from your app and get the output captured and saved to a log file.
Thats basically it, but its the only way I know to trap these random events, but when they happen, get your users to inform you straight away so you can get the most recent log file and then discard the earlier ones. And once a day or once a week clear remove the old log files so they dont junk up their hard drives too much.
Its tedious work but you should be able to start at the last entry and work backwards to see if anything obvious is happening. You might need 2 or 3 or even more of these logs to establish the pattern. It could be time of day, other apps runming, it could be anything, even anti virus. I’m reminded of a program back in the 90’s or early 00’s which intercepted all the DDE messages for itself, which messed up sending faxes to Winfax as that used DDE to control. So dont rule out your app hanging because of another program.
There is a screen shot at this link of one of my templates which works with debugview, which might give you some ideas, for logging.
The Taskkill /IM is a hack, I need to move some code into it to identify the debugview process and kill it more cleanly when the app closes, which should make it work better with Debugview++ as well then, but sysinternals debugview will only capture on the first instance of debugview, so you can start as many instances of debugview as you like, its only the first instance actually capturing any of the debug output.