When there are a deep chain of function calls, especially when the managed and unmanaged code are intermingled together, it's getting more trickier to debug. One situation is that an exception is thrown deep at the bottom of the chain and caught at some level after it's relaid/re-thrown by a couple of levels and the message logged by the exception handler code is too generic to help locating the root cause of the exception. In this case Visual Studio could help locate where the exception is actually thrown at the beginning. This helps a lot in narrowing down the problem when debugging in a large code base.
After loading the project into Visual Studio, bring up the exception dialog by menu "Debug" => "Exceptions..." and check the types of the exceptions that you want to investigate. After this attach to the process in question. Whenever the statement will cause exceptions to be thrown, it will prompt and let you choose whether to break at that trouble statement and do further investigation.
