The VS debugger does some really strange things to available memory. Try doing the same without the debugger running. You could trap the exception and blink a LED and/or write free memory number to an LCD or other display.
I’ve never investigated the details, but have had this exception thrown while debugging. Deployed the same code and the exception magically vanished.
This helpful nugget of information was passed along from another forum member, who has really pushed the envelope of displaying graphic files on the small FEZes. Thanks @ skewworks for going “where no one has gone before”.
@ Gus Is Debug.GC(true) considered a “production” command or only meant for debugging? I’m always worried about using it in release code because it is so unpredictable. I’d rather want to rely on a Dispose but it still doesn’t seem to guarantee free usable memory.
I must say it is fun living on the edge (of memory) but it hurts when you fall off
I would say every effort should be made not to have to use it in production.
In embedded systems, dynamic memory allocation can lead to problems. Every effort should be made to allocate large blocks during initialization.
BTW, dispose frees an object, but the object memory is not available immediately. The actual recovery of the associated memory doesn’t happen until GC occurs, which happens automatically or manually.