Why do I still get stack cookie exception although I disabled /GS flag in VS11 when compiling? Scenario: buffer overflow tutorial test

Question

recently I have tried to test a tutorial application on demonstrating buffer overflows, written in C. I used the Visual Studio 2012 toolchain to compile and link the sources, and made sure the following options were set: address space randomization disabled, /GS disabled, which should disable stack protection and buffer overrun protection on the "victim application", which was vulnerable of stack overflow. Although I did all this, there was extra space added to the stack, besides the size of the buffer which I was going to overwrite with my shellcode. I managed to identify the return address, which I wanted to replace with the start address of the buffer, in order to run my shell code from the stack. I am getting the following message, just as I have /GS flag enabled, but I don't:

Stack cookie instrumentation code detected a stack-based buffer overrun.

Do you know what could be the problem? I use a second application and invoke my victim application with the shellcode as a parameter from it. As far as I know, it should not interfere in any way with the way the victim handles this. I'm using the WinExec call for the victim, from my attack application.

Why do I still get the behaviour just as with GS enabled? I don't think it is overwritten by any other option, I also disabled /sdl - security checks. For the linker, I have the following added: /DYNAMICBASE:NO.

Which other options do I have to configure in order to diasble the stack cookie and buffer overflow protection? Are there any other settings, besides this, for the environment, which I would have to configure in order to make this work? It seems that the /GS- is ignored, for the moment.

Edit: similar problems seems to have been covered here: A buffer overflow attack on Windows results in access violation and I think it is on the root of my problem too. All the behavior mentioned before was due to the /NXCOMPAT:NO flag which seemed to introduce the behavior of placing the return address further down the stack and activating that stack-cookie protection mechanism. With /NXCOMPAT enabled, the return address is placed just after the local variables and the base-pointer, if not omitted. And I get the access violation message. Has anyone managed to bypass this and manage to achieve a successful buffer overflow attack on a program compiled with cl from VS2010 or later?