Unhandled Memory Exception on GCCollect?

I've gone back to some code I haven't touched in a few months and I'm getting an error I wasn't getting before. I guess it's a Max update or a syncmods or something, because I don't think I've changed any code.

Anyway, it's giving me an unhandled memory exception error on GCCollect. Not really sure where to begin debugging that. Any thoughts or ideas on where to start with this? A rough idea of what I'm looking for?

I'm thinking something I've put in a delete method which is accessing something which no longer exists? But shouldn't that show up properly in the debugger? I get nothing in the debugger with this. Besides, that shouldn't have changed with an update, should it?

If you are importing old modules, I would make sure you have rebuilt all modules with the new compiler and keep quick build off until you get things working.

There may be I guess a problem with calling other functions from a delete method in respects to the debugger, is release mode any better?

Erk, just came back to this and realized I never replied.

It doesn't happen at all in release mode. No Unhandled Memory Exception at all.

Quick Build is disabled and all modules have been rebuilt ( by which I mean all modules were rebuilt over and over until none would recompile, ensuring that modules which rely upon other modules were not an issue.

I managed to get the debugger to kick in by NOT using GCSetMode 4 ( which I had previously been using as it was supposed to offer verbose GC, but I never noticed any difference. )

The error is being triggered in Win32MaxGUI, specifically in TIntWrapper's create function, on the line which creates a new TIntWrapper. I don't actually have any idea what this is for, but I guess it's related to the way I shut down my GUI stuff? The gadget in question would appear to be a Tabber, if that helps any.

Why this would show up on GCCollect, I really don't know, because I destroy these gadgets in a shutdown method, not in a delete method. This debug information only came up once though, and never again since, so perhaps it was a glitch.