PS: I am using C#/XNA and Visual studio 2013

As an addition to above suggestions there is also one more thing you can do. In menu Debug->Exceptions be sure to check also "Thrown" column of relevant exceptions (it is unchecked by default). That way it will break at the time any exception is thrown and you will be able to debug the issue.

Thanks for the tip.. Looking at it. I think the only check box I check is the Common language runtime exception

I have also been known to put a regression test suite into my app or game so you can run it in some special way e.g. With a command line parameter and rather than entering the main loop, it initialises all systems and performs tests with known parameters, logging which functions give unexpected results.

Im lost on this part. Can you give me a simple example or link to explain just how this works or how to do this?

It's simpler than it first sounds.

Simply write down for each function what you expect it to return when called with various parameters. Choose some sane and some insane values and some edge cases which are the extreme inputs.

Then have a function that calls each one, passing it the input you wrote down and checking for the one you expect back. Any that don't return what you expect are broken. It is basically like asserts except you can use it as part of your automated testing to see if your game is broken in some subtle way.

You would then put some code in your game so that if someone did:

Mygame.exe /testsuite

It runs this set of calls instead of starting the game.

The usefulness of this hinges on making sure it does tons of tests of the entire functionality from renderer to sound and that somehow, you can tell if the function is broken without asking the user so it can be automated.

If you look in my open source (non game) project inspircd you will be able to find a C++ example of his, drop me a line if you get stuck :)

Can you give me a simple example or link to explain just how this works or how to do this?

This is just exercising parts of your code automatically and verifying that certain inputs equal certain outputs. If the tests target a specific section of code, they are generally called unit tests. For example, if you have code that reads/writes "save games", your test might supply a save game file, load the game state from it, then save the game state, and verify the new save game file is identical to the old. Or if you had code that determined if two triangles intersect, you'd set up known test cases to verify that the results are true or false, whatever you expect.

If your game supports a replay system (where say all inputs are recorded so that a game can be replayed), then you could use this replay to reproduce bugs that other people have hit. Of course, that requires a lot of planning up front.