帮助在visual studio中调试C ++

Question

This is a vague question so I am expecting vague (but hopefully helpful) answers.

I am new at C++ and debugging in visual studio and what frustrates me the most is how to interpret the call stack...

So my question is specifically about what I'm seeing on an error at the top of the stack. What should this be indicating? Someone suggested that there are exceptions being thrown in the code that is causing stack corruption. That may be indicated by the __FrameUnwindFilter(_EXCEPTION_POINTERS*...) line in the call stack. How do I interpret what's going on here? There's just so much stuff I possibly don't care about. And then on top of that there's that warning that "Frames below may be incorrect and/or missing" what does that mean? That I can't trust those lines at all? Why show it in the first place? Also, why is dddddddd() at the bottom of the stack frame?

Please help me - I'm looking for general advice and tips on how to interpret the stack.

Thanks,

jbu

On one particular error, what I see is:

mscvcr90d.dll!_NMSG_WRITE(...) Line ###

mscvcr90d.dll!abort() Line ## + 0x7 bytes

mscvcr90d.dll!terminate() Line ###

mscvcr90d.dll!__FrameUnwindFilter(_EXCEPTION_POINTERS* ...) Line ####

mscvcr90d.dll!__FrameUnwindToState(EHRegistrationNode * ...) Line ###

mscvcr90d.dll!@_EH4_CallFilterFunc@8() + 0x12 bytes

ntdll.dll!7c9032a8() 

[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] 

ntdll.dll!7c90327a() 

ntdll.dll 

ntdll.dll 

kernel32.dll 

kernel32.dll 

kernel32.dll 

Other Library 

Other Library

FINALLY MY LIBRARY CODE HERE

END OF MY LIBRARY CODE 

a whole bunch of other libraries here that I haven't heard of 

dddddddd()

Answer 1

Are you running in Release when seeing this kind of thing? Debug builds offer much more helpful information about the call-stack. You can enable this information in the project properties for Release builds too if you like/need (Debugging Information Format, I think). Without that information (including dlls you haven't built like ntdll) it can only tell you the library name and virtual address.

The unwind tells you that an exception caused the error. As a starting point you may want to consider your exception handling is adequate and informative enough and hopefully then you can collect more valuable information about your errors.

Unfortunately if you do corrupt the stack it can get it all wrong and "point to an error" in your code that just makes no sense. That's often where you see the callstack has no decent origin (whereas your example does).

Answer 2

There are a couple of things that are going on here.

The first is that there does appear to be an SEH exception thrown. That is indicated by the FrameUnwindToFilter calls. It's hard to say simply from the call stack exactly what exception is occurring. If you move down to that frame though and look at the parameters one of them should have the exception code.

The second item si the "frames below may be incorrect ..." The Debugger displays this message when you are debugging a native DLL for which symbols are not present. The absence of symbols makes it hard, and sometimes impossible, for the native debugger to accurately determine the call stack. It forces it to guess and hence the warning "may be wrong"

This can be fixed by loading the symbols for the DLL in question. In this case it's nt.dll and kernel32.dll. These are Microsoft owned DLLs for which symbols are publicly available. The following MDN page has more information about how to get the public symbols setup on your machine

• http://msdn.microsoft.com/en-us/library/ff552208(v=vs.85).aspx

Answer 3

好吧，如果你需要调试这里的提示我会帮你解决你的问题，但我不会说我太确定我自己没有问题，我不能从错误日志中说出来