CompuServe Messages

Bob, >> I have a wierd problem. When I run my application it will blow up with a memory assertion in either the allocation or deallocation area. Normally in random things like a CString creation or when I add a CString to a CStringList. This "just started to happen" recently. I've been runing the app for about 5 months in its current state with no trouble. Recently, I've been "tweeking" the resources (dialogs, menus,etc) and rearanging a few things. I just don't know what to do next so I' I just don't know what to do next, so I've been hacking at it. I suddenly tried turning checking the "Disable Resource Load Optimize" on the Options | Project, then Resource button; dialog. When I did this, I no longer get the memory errors. But in reading the helptext on this item, it should have no impact on my program. This is a CRITICAL app that needs to be distributed in about two weeks. Is there ANYTHING I can use, somebody I can check with to see why the code is acting like this? HELP!! << I haven't been able to find any reports of resource loading causing these sorts of problems. This leads me to think that there is likely some memory corruption which just happens to get hit in this case and not in others. What I would suggest first off is, with a build of your application that has the problems, putting the lines afxMemDF |= checkAlwaysMemDF; into your InitInstance before anything else. This will attempt to validate all memory blocks allocated with new whenever you do a new or delete. You can also use the DEBUG_NEW macro to give you the file and line number of the allocated blocks it might find which are getting messed up. These things won't work in a release build. Similarly, have you run under the debugging version of Windows and seen what output it gave you on this? You might want to do so (you can install it from the Visual C++ setup under the tools options) and turn on local heap validation using the DebugWin application. I realize that you've likely already tried these avenues, but I'm afraid I can't suggest much else which might be going on here. One other note. If you're building in large model, you might want to try compiling with /Gx- (check the "Assume extern…far" in your memory options for the compiler). This will *not* attempt to put all your data in on segment, as the default build does. Though this won't fix the actual problem it might, by relocating your data, make what is going on a little more obvious. Good luck with this. Tarn Faulkner Microsoft Developer Support