   Debugging, "vector subscript out of range"
  When I start my program with F5 or “Build->Start Debugging” from within Visual Studio 2005 everything is OK. The application runs without any errors. But when I start the Program with “Build->Start Without Debugging” (Ctrl+F5) I get an error message:Debug assertion Failed!Program: …File:… vectorLine: 756Expression: vector subscript out of range…When I press retry and then choose to debug the program, visual studio opens the file stdthrow.cpp at line 24. The files vector and stdthrow.cpp from the standard library are not causing this problem and everything works fine when I run the program line by line. I am using several libraries and there is a lot of code, so I cannot narrow down the problem.What is the difference between “Start Debugging” and “Start Without Debugging”, and how can I force them produce the same result?   
  You can just use the call stack window when you hit the assert to look up the call stack till you get into your own code. Then you can use the watch windows to look at the variables in your function.   ;  I did not know I could use it with “Start Without Debugging”… at least it doesn’t appear automatically.EDIT: I cannot open the call stack window after running the program with “Build->Start Without Debugging”. Am I missing something?[Edited by - Kambiz on September 7, 2007 3:58:26 PM];  These sorts of errors (works in debugger, crashes when run normally or works in debug, crashes in release) almost always come back to uninitialized data in C++.  This is why C# doesn't let you read uninitialized data.  Its the source of too many errors.Look at the code where you are accessing the vector and make sure that the variables used to index the vector always have a well-defined value for all paths.  The best way to ensure this is to just initialize variables by habit as soon as you declare them.  In other words, always write:int i = 0;instead ofint i;When you run your program in the debugger, uninitialized data is handled differently.  Ditto for release vs. debug builds.  The debugger and the debug builds are generally more forgiving of uninitialized data.   ;  In both situations I am using the debug build… this a strange behavior that making the debugging very hard.By adding many MessageBox calls, I was able to localize the problem in one of the libraries.   ;  Like I said, reading uninitialize data can bite you in several ways.  One of them is debug vs. release and another is inside the debugger vs. running the application normally.Get a tool like Purify or Bounds Checker and validate that you are not attempting to read uninitialized data.  Its not just variable declarations, but also allocated memory.  C++ doesn't initialize allocated memory for you, its your job to ensure that all allocated memory is initialized to a proper state before reading it.You could also have a plain old memory corruption problem.  Again, a tool like Purify or Bounds Checker will find these sorts of problems more aggressively than the CRT.You can also enable memory allocation checks in the CRT and get some simple checking without an exhaustive analysis tool like Purify or Bounds Checker.There's a lot of tools in Visual Studio to help you with this problem; try reading up on them in the documentation.   