Ok, I've just modified the appropriate code and re-compiled.

There is a massive difference in the ammount of memory leaks. Out of about 6000 strings for some reason about 6 leaked. Luckily I've also found that there's a typo in the ini file, causing the instance of the textcontainer class to have been overwriten in his parent array with another array. So the orphaned class never got destroyed. Simple to prevent next time.

I'm sure even in XP on a 2Ghz processor there is a slight speed improvent using the code below rather than CStringsArray. I might even add some performance counters to check.

Thanks again for the help (especially Philip). I would probably banged my head against the wall for days with this one. Even though the program can't be closed, as you have to hard reset the device. I would have gone mad with all those leaks hiding in the program somewhere!

fixed code

Code:
void CTextContainerArray::AddString(TCHAR* pStr)
{
	TCHAR* newstr = NULL;
	int len = 0;
	if (pStr)
	{
		len = wcslen(pStr) + 1;
		newstr = new TCHAR[len];
		if (newstr)	
		{
			wcscpy(newstr,pStr);
		}
	}
	Add(newstr);
}

PS: There is still one other memleak. It's very interesting. It only gets registered by Visual Studio 2003. If you double click on the line in the output window Visual studio crashes. hehe

Looks like this:
Detected memory leaks!
Dumping objects ->
thrdcore.cpp(311) : {230} client block at 0x00D4FC40, subtype c0, 68 bytes long.
a CWinThread object at $00D4FC40, 68 bytes long

What's 68 bytes to friends anyway?