(The "Stupid Way" I used is to manually remove Class Point (functions with very low abstraction levels such as set/get + common onwin messages) + when hit,
With debug output, dynamic outputs call sequence.
But in the final analysis,Finding an accurate call stack is the "core")
The reason for this article is:
1) When debugging com code, a "read violation" error is thrown because a null pointer is referenced. however, the exception lies in the break, but it is 108,000 away from the final bug. view the stack and find that the stack is "affected" by other components of the project, resulting in confusion.
After asking for advice from the predecessors, I got the following solution:
1. Confirm the exception number: 0xc0000005 in the blue box
2. Open the "exception" of Vs and check the exception number just confirmed:
In this way, when an exception occursFirst-hand informationNot NTDLL, but win debugger.
Superficial principle:
1. veh-> she
Debugger (veh)-> try/catch (SHE) or unhandled exception-> NTDLL. dll
Refer:
1. Wikipedia (provides a lot of in-depth materials)
Debugger-veh & she Shanyi