Q:

Applications result affected by another running application

This is a follow on from my previous question although this is about something else.
I've been having a problem where for some reason my message that I pass from one process to another only displays the first letter, in this case "M".
My application based on a MSDN sample so to make sure I hadn't missed something I create a separate solution, added the MSDN sample (without any changes for my needs) and unsurprisingly it works fine.
Now for the weird bit, when I run the MSDN sample running (as in debugging) and have my own application running, the text prints out fine without any problems. The second I run my on its own without the original MSDN sample being open it fails to work and only shows an "M".
I've looked in the debugger and don't seem to notice anything suspicious (it's a slightly dated picture, I've fixed the data type inconsistency).

Can anyone provide a solution as to this? I've never encountered anything like this before.
To look at my source code it's easier to just look at the link I posted at the top of the question, there's no point in me posting it twice.
Thank you for any help.
Edit:
After further investigation it almost seems that my own application is somehow reading the other applications memory by accident. If I "poll" for the message without even sending it via the producer window, it still gets the message which must mean it's reading it from the other (MSDN) process, this would also explain why it only works properly when I run the MSDN sample first.
I still don't understand why this happens, how to stop it and how to fix it, this is possibly the strangest thing I've come across.
****Solution:****
Although it does not fix the problem of both applications affecting each other I have managed to fix the text problem. I did not add the necessary #include  to both files, adding this fixed it without any warnings.
It's always the little things.

A:

Take a look at pBuf in the "memory viewer" window.  The string viewer will terminate at the first null terminator, but what lies beyond may be interesting/useful or provide a clue.

