Crash within CString

I am observing a crash within my application and the call stack shows below

mfc42u!CString::AllocBeforeWrite+5    
mfc42u!CString::operator=+22 

No idea why this occuring. This does not occur frequently also. Any suggestions would help. I have the crash dump with me but not able to progress any further.

The operation i am performing is something like this

iParseErr += m_RawMessage[wMsgLen-32] != NC_SP;

where m_RawMessage is a 512 length char array. wMsgLen is unsigned short and NC_SP is defined as

开发者_如何学Python#define NC_SP   0x20     // Space

EDIT:

Call Stack:

042afe3c 5f8090dd mfc42u!CString::AllocBeforeWrite+0x5 * WARNING: Unable to verify checksum for WP Communications Server.exe 
042afe50 0045f0c0 mfc42u!CString::operator=+0x22 
042aff10 5f814d6b WP_Communications_Server!CParserN1000::iCheckMessage(void)+0x665 [V:\CSAC\SourceCode\WP Communications Server\HW Parser N1000.cpp @ 1279] 
042aff80 77c3a3b0 mfc42u!_AfxThreadEntry+0xe6 
042affb4 7c80b729 msvcrt!_endthreadex+0xa9
042affec 00000000 kernel32!BaseThreadStart+0x37 

Well this is complete call stack and i have posted the code snippet as in my original message

Thanks

I have a suggestion that might be a little frustrating for you:

CString::AllocBeforeWrite does implicate to me, that the system tries to allocate some memory.

Could it be, that some other memory operation (specially freeing or resizing of memory) is corrupted before?

A typical problem with C/C++ memory management is, that an error on freeing (or resizing) memory (for example two times freeing the same junk of memory) will not crash the system immediatly but can cause dumps much later -- specially when new memory is to be allocated.

Your situation looks to me quite like that.

The bad thing is:

It can be very difficult to find the place where the real error occurs -- where the heap is corrupted in the first place.

This also can be the reason, why your problem only occurs once in a while. It could depend on some complicated situation beforehand.

I'm sure you'll have checked the obvious: wMsgLen >= 32