I hit something similar regularly and have debugged into it on the PC side. I can repro hard hangs by placing breakpoints on delegates that get fired from firmware, and certain other operations (mostly single stepping). One of the hang scenarios is rooted in how the debugger walks the call stack, but another seems rooted in the firmware and I don’t have the ability to debug into that. Both issues may require firmware changes.
If you are not single-stepping or using breakpoints, then your failure scenario may be different than mine, but then again, if you are not single-stepping or using breakpoints (i.e., just watching the debug output) you can do that from the TinyCLR app and should not hit the hangs if they’re the same ones that I am seeing.
The nasty thing about it is that it is not a deterministic failure, but when it happens, what I see is a stack overflow in the debugger code that exits the debugger (VS goes back to edit mode, or exits entirely), but which leaves the interpreter in a stopped state, waiting for the debugger and the only recovery is to reboot the board.
Rearranging your code and avoiding breakpoints in callbacks may reduce the frequency of the hangs, but it’s mostly guesswork and good luck. This is going to take someone with a repro, SDK source, and the ability to do firmware debugging (i.e., GHI).