To follow up, I briefly posted about this in an older somewhat related thread, and the advice was that it probably had to do with two objects that have Dispose methods, and one of them being garbage collected and disposed, which eliminates the underlying native resource that the second instance is still using. I went through all of the uses of hardware resources through serial ports, pins, etc. but couldn’t track down or prevent the freezing.
Since I was compiling the TinyCLR libraries from source, one debugging tactic that I tried was to place a “Debug.WriteLine” statement in every finalizer and Dispose method. Should this show where the problem is?
When I tried this and would see the freezing, the only things printed out from this prior to the freeze were many times the finalizer of a “System.Drawing.Bitmap” ran, each one paired with the Dispose method of “System.Drawing.Graphics”. I tracked this down to Buttons being created dynamically during the application on an ongoing basis. I stopped this from happening, but unfortunately my application still freezes even though it doesn’t show any finalizers or Dispose methods being run. How can that be?
Another thing I tried was to comment out parts of the code and see if any particular section caused it to freeze. Commenting things out would help, in that it would go for several garbage collections without freezing, but which parts of the code I uncommented to get it to break didn’t make sense to me. I’m not sure if it ever worked forever.
I also added a static property that calls “GC.Collect” in its “get” accessor, and added this property to the Watch window in Visual studio, so that I could step through the code and the watch window updating would trigger a garbage collection on every step that I took. The line of code that it would freeze on did not make sense to me.
Are there other approaches like this that can find the problem in some kind of methodical fashion? What else can I do? I am going crazy. Thank you for any help you can give me!