0

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).

Debugger Information

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.

Community
  • 1
  • 1
Jamie Keeling
  • 9,806
  • 17
  • 65
  • 102
  • One process cannot read the memory of another; they exist in different virtual memory spaces, so that hypothesis is not plausible. It is more likely that you have a non-deterministic bug whose behaviour depends on the value of some uninitialised data, or data referenced by an invalid pointer. These values will depend on the memory environment on start-up, and by affecting the environment, the code may run in a different area of physical memory, and so operate on different values. You may find that for the same reason the behaviour is different outside of the debugger environment. – Clifford Apr 18 '10 at 16:30

1 Answers1

1

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.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • Apparently my edition of the IDE doesn't include it, great. http://msdn.microsoft.com/en-us/library/5d2www5s.aspx – Jamie Keeling Apr 17 '10 at 20:31
  • I've marked this as the answer, although I couldn't use it I'm sure it would of helped me regardless, thank you for your time Clifford. – Jamie Keeling Apr 17 '10 at 21:01
  • @Jamie Keeling: It works for me in VC++ 2008 Express exactly as described on that page, I have not tried in 2010 Beta which perhaps that page applies to. If it does; a good reason *not* to "upgrade"! Simply enter `pBuf` as the data you wish to observe. Failing that, add separate watches for `pBuf[0]`, `pBuf[1]`, `pBuf[2]`, ... etc. – Clifford Apr 18 '10 at 07:15