It's been a while since I've posted a really substantive problem, but here's one to chew on. Consider this excerpt from my globals list: DIM gameSound& DIM extraSound& DIM phonyVar& DIM backSound1& DIM phonyBack.8 DIM backSound2& DIM backSound3& -- gameSound& is a handle to a sound resource. It is loaded when needed, locked, played in channel 1 (in gameplay terms, foreChannel&) and then kept in memory until the handle is needed for the next sound. -- extraSound& is exactly the same thing except that its sound goes to the other channel, backChannel& -- backSound1& and its siblings are loaded as a group--different scenes use one, two or all three--and are used for background-sound looping. When no longer needed they are unlocked & disposed, whether or not a new group is loaded. The problem: when one or another of these five sounds (which one, exactly, will depend on the individual compile) has been loaded into memory, the program crashes at quit. If "Apple Menu Options" (OS 7.5.5) is active, it also crashes on _any_ menu-bar click (possibly the first time I've _ever_ gotten useful information out of ConflictCatcher!); MacsBug tells me that one of the menus has disappeared from memory. Things I've excluded: --it doesn't matter whether the sound in question has actually been _played_ or simply loaded into memory -- what specific sound resource is involved (each of the five handles calls on a different pool of sounds, with no overlap) -- how large the sound is, though longer sounds may be truncated (a warning that things will go bad) -- whether the sound lives in an external resource file or in the app itself -- whether it has been subsequently disposed or is still in memory -- whether the app explicitly disposes of sounds at quit -- whether it's a proper quit or simply cmd-period END -- whether I'm running a compiled app or within FB -- in the case of the menu bar, it doesn't matter what code (or none at all) would be executed; it's the physical click -- larger-scale wonkies don't seem to be at issue; all this happened both before and after I re-initialized my hard drive ...which brings us to the phonyVar. These are, as you've all guessed, bandaids. Slipping a phonyVar& into the appropriate location in the globals list makes the problem go away. I try four bytes& first; if that isn't enough I go to eight.8. (Six may have been enough; I just haven't tried it.) To anticipate the obvious question: as far as I've been able to establish, no bogus value has ever slipped into any phonyVar. (No, uh, blood on the bandaid.) And, of course, that's "go away" in the sense of the monster that used to be under the bed and has now relocated to the hall closet. Since then I've come up with a bandaid that works even better: shift everything but gameSound& into DIM backSound&(3) ...which, I think, moves the whole thing into a completely different part of memory (where the sound handles are immediately followed by several important global arrays that behave exactly as they ought). But these are still bandaid fixes. Can anyone give any insight into what the _real_ problem is?