Why do I receive characters at an offset in the buffer when using ReadFile()?

What I'm trying to do:

I'm trying to write win console which will communicate with my ATMega2560 board via UART. Now it should send string saved in stringToSend to the MCU which should be send back to the PC. String sent from MCU should be saved in receivedString and then written to the win console window.

What the code does:

What it does now is that after I send the string to MCU it will come back, but on the console I see an unexpected sequence of '╠' characters preceding the echoed string, just like this:

You sent:

╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠╠Sended test string!

EDIT: Number of characters is consistent if BUFFER_SIZE is constant, but it scales with BUFFER_SIZE:

If BUFFER_SIZE = 124 then there's 132 of these characters
If BUFFER_SIZE = 1024 then there's 1032 of these characters
If BUFFER_SIZE = 1 then there's 9 of these characters

Weird things (probably just for me):

The weirdest thing is that when I use breakpoints and look into receivedString the string from stringToSend isn't there BUT it will appear in the console.
When I send data via Termite (console for sending data via serial communication) the problem disappear and after that I'm receiving ONLY the right string even with my console.

The questions:

Am I supposed to setup some bit/flag in the MCU which cause this behavior?
May it be problem with format of the string?
Am I just completely missing something what I should do before/after I send the data from PC/MCU?

What did I try:

I tried to find some solution on internet but I can't find nothing
As experimentation I tried nothing because honestly I'm completely clueless what the problem could be

I would really appreciate any help even with refactoring/other coding tips.

Answers to comments:

Could you print values as hexadecimal and add number of these elements?

The output:

ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc >ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc >ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc >ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc >ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc ffffffcc 53 65 6e 64 65 64 20 74 65 73 74 20 73 74 72 69 6e 67 21

Number of these characters is always BUFFER_SIZE + 8 and the character in decimal is represented as -52

Solution:

I already added 4th parameter into functions WriteFile() and ReadFile() and the problem wasn't there (but it definitely can cause some problems because documentation says the last two parameters can't be both NULL).
I found somewhere in documentation that ReadFile() should always come after event occurs and function WaitCommEvent() catch it. The type of event is set by SetCommMask(mainCom, EV_RXCHAR) so it occur when there's character in input buffer (there's documentation to function SetCommMask()). This solution shows the error is caused by the board which doesn't send the data because WaitCommEvent() will end up in infinite loop waiting for receiving data. However without using WaitCommEvent() it seems like the sent data are held by some kind of memory and read from there so even when the board doesn't send them, they're printed (I really don't understand why but see @thebusybee answer). What actually repair the problem is just simple reconnecting the board every time I boot windows (after reconnecting is everything functional even with using WaitCommEvent()) which leads me into completely different question if windows is sending some weird stuff into USB ports when booting so it mess with the board but that's for another topic. It could by also caused by windows using different communication parameters (as baud rate etc.) while booting. But that's for another/different question.

Solution

ReadFile() does not read any bytes from the serial device because of your erroneous call with both last parameters set to NULL. However, ReadFile() did not return FALSE.

The values 0xCC (printed sign-extended as 0xFFFFFFCC) that are filled into receivedString are used as debug aid.

Your PC's compiler apparently locates the variable receivedString before the variable stringToSend on the stack. The additional bytes are most probably canary words.

When you now print receivedString, the function printf scans through the memory until it finds a terminating '\0'. This is the case after the contents of stringToSend was scanned additionally and copied to the output. So what you see is not received by ReadFile(), but the existing characters of stringToSend, which happens to be exactly what you expect to receive.

This visualizes the memory situation:

(lower address)...	`receivedString`	padding	`stringToSend`	...(higher address)
	0xCC, 0xCC, ... 0xCC	0xCC, ... 0xCC	'S', 'e', ... '!', '\0'

What should you do?

Never ignore any return and output values. Check the number of actually read bytes, in this case.
Always read the documentation of a function and use it accordingly. Commonly, and I'm afraid to say this, especially on Windows, the principle "garbage in, garbage out" holds true.