   VC80 Optimize for maximum speed bug
 #include <windows.h>    int WINAPI WinMain(HINSTANCE hI, HINSTANCE hPI, LPSTR acCmdLine, int iWinMode)  {  char acXYZPath[260];  strcpy_s(acXYZPath, 260, &acCmdLine[1]);    return 0;  } If a place a breakpoint on return 0; and examine acXYZPath, it is 3 garbage chars + 0 + acCmdLine. (Be sure to supply a command line arg in Configuration Properties/Debugging/Command Arguments. I set mine to "foo").If you enable debug info (C++/General/Debug Information format and Linker/Debugging/Generate Debug Info) in release mode with the optimizer set to "Maximize speed", are you able to reproduce the error that I see?   
  It's just not debugging right due to the optimizations.  Go ahead and put a message box there to display your string, it should come out fine.   ;  And depending on how smart the optimizer is, it might have removed the entire strcpy_s call, since it might have recognized that you never use the result and the CRT function call has no side effects.As MJP said, put in a message box and everything will work as expected. Debugging release code is a lot harder than debugging debug code, and should not be attempted by a beginner.;  Why does the debugger have so much trouble in release mode? All strings are always offset and such, what real differences does it do to the code?   ;  > Why does the debugger have so much trouble in release mode? > All strings are always offset and such, what real differences does it do to the code?What Yann L is getting at is that your code doesn't actually do anything, so therefore there is no reason to generate any code, or even create any of your strings.   ;  An easy way to check if the compiler actually produced the code for the call is to turn on assembly output. That is of course if you can read assembler code. But it's pretty unlikely that the compiler calls strcpy_s in this situtation because - as it has been mentioned - it has no side effects.   