I have the following code:
GetNumberOfFormatsFunc getNumberOfFormats = (GetNumberOfFormatsFunc)lib.GetProc("GetNumberOfFormats");
if (getNumberOfFormats != NULL)
{
RINOK(getNumberOfFormats(&numFormats));
}
The function GetProc does this:
GetProcAddress(module, proceName)
when the function 'getNumberOfFormats' is called the debugger does not step into it, even if I press 'F11' on it. It also doesn't tell me I missed a callstack.
The function exists in a separate project and it links to that projects copmiled DLL. Any ideas why I can't step into the code?
Visual Studio can't find debug symbols for your DLL. Check whether PDB file is generated for your DLL and exists.
You can check the symbol loaded information while debugging from Debug->Windows->Modules. Right click on the desired DLL and configure the proper symbol if not properly loaded.
Related
The symbol myLibrary!__scrt_stub_for_is_c_termination_complete+0x12345 appears in the stack trace of a crashed application. It is C++ compiled with MSVC2015 and heavily uses Qt.
myLibrary does not explicitly implement anything of that name.
Google shows some hits on this name, so apparently it is not particular to this one application. But I cannot find an explanation of it.
That is a "no idea where it crashed" diagnostic. The +0x12345 offset is far too large. Not uncommon at all, you need good PDBs to get accurate stack traces. Without them it doesn't know anything about the code you wrote and can only go by named DLL entrypoints.
Since the crash appears to be detected in the C runtime library, you might well get lucky by enabling the Microsoft Symbol Server and let it produce the PDB you need. Assuming you opened the minidump in VS, use Tools > Options > Debugging > Symbols to enable the server. General and WinDbg advice is available in this MSDN page.
Is a library name : myLibrary
Is a function name : __scrt_stub_for_is_c_termination_complete
Is a distance from function offset : +0x12345
If you enter the disassembly mode, then you can see a function's address
Also you can see in the (quick)watch to function name, same as disassembly
you can assuming exception raised from specific function and which line.
Watch out : If you debug in Release build , it would be hard to find which code raise the
exception. In this case you can compare your assembly between Debug and Release (I cannot explain how it works 'til describing.). Use Debug Build to ease to Debug.
Happy Coding :)
I have an excel xll plug-in built in c++ (and with the help of xlw), which, runs pretty well except, when excel exits, exception happens occasionally.
My headache is that though it looks like some destructor issue, I can't see where it went wrong.
Excel window just closes then a Windows system error message pops out.
Even if I run it in Visual Studio debug mode, when the exception happened, it's already in the STL c++ code, also I can't see which part of my code, such as a destructor, is the root cause of the failure.
To be precise, Call Stack shows
[External Code] -> Excel.Exe -> [External Code] -> MSO.DLL ... repeat... OART.DLL... repeat ... ntdll.cll -> [External Code] -> _cexit() -> common_exit -> __acrt_lock_and_call -> ...
The first step with source visible is exit.cpp in C:\Program Files (x86)\Windows Kits\10\Source\10.0.16299.0\ucrt\startup\exit.cpp,
extern "C" void __cdecl _cexit()
{
common_exit(0, _crt_exit_full_cleanup, _crt_exit_return_to_caller);
}
Have you tried setting a conditional breakpoint in Visual Studio settings to break on any exception (or the specific exception you are getting)? You can enable this just before you exit Excel. This might help track down the problem and give you the call stack in the call stack window when the breakpoint hits.
Also make sure to check if your symbol files (.pdb) are getting loaded for your code and any third party dependencies. Another thing that can help is to specify the Microsoft public symbol servers so that the Microsoft system pdb’s are loaded as well as mentioned in this article.
I have seen this question asked several times and I have tried all the nonsense that I have read, but I can't make it work.
I use Visual Studio 2012, in Debug mode. I compile the simple code
#include<iostream>
int main()
{
std::cout << "Hi" << std::endl;
system("pause");
return 0;
}
I put a break-point in line 4 (std::cout...) and I press F5 to execute.
The break-point is ignored and there is an exclamation mark next to it saying that "The breakpoint will not currently be hit. No symbols have been loaded for this document".
EDIT: In the output window after building I get a warning:
main.obj : warning LNK4099: PDB 'vc110.pdb' was not found with 'main.obj' or at 'Z:\Projects\Tools\DebugTest\Debug\vc110.pdb'; linking object as if no debug info DebugTest.vcxproj -> Z:\Projects\Tools\DebugTest\Debug\DebugTest.exe
However, if I go to Properties > Configuration Properties > Linker > Debugging, in "Generate Program Database file" I believe I have the correct "$(OutDir)$(TargetName).pdb" so I don't understand why the pdb file is not being created.
Try rebuild application.
Make sure it's in the debug configuration.
This can happen when the debug info files (.PDB) are out of sync with the real compiled binary.
Here is how I made the breakpoints work, in case this helps anybody, although I don't really understand what I am doing.
In project properties > C/C++ > General, in Debug Information Format setting, I changed "program database" to "C7 compatible". Symbols are now loaded and breakpoints are hit.
It would be great if somebody could elaborate on why this causes the symbols to load, whereas the former option did not.
When I attach to Dllhost process to debug a VC++ COM+ component, the debugger activates and stops on the breakpoints, so I know that debugging part works.
But I cannot inspect any objects in the code such as
MSXML2::IXMLDOMAttributePtr
MSXML2::IXMLDOMElementPtr
_RecordsetPtr
because for them the inspector is showing the error messages
{0x02c09568 <No type information available in symbol file for msado15.dll> {...}}
{0x00a17744 <No type information available in symbol file for msxml3.dll> {...}}
The symbols have been obtained by going into Tools/Options menu of VS2012, switching to Debugging/Symbols tree and hitting "Load all symbols" button". Apparently that did download something for the above mentioned DLLs, as previously I was getting another error
Information not available, symbols not loaded for ...dll
for each of the DLLs.
I find it unlikely that unluckily I am trying to inspect just a handful of classes that are missing symbol information in an otherwise populated symbol file, so obviously something is wrong with the environment that I inherited with the machine. What do I need to do to be able to inspect the objects from the COM DLLs?
Thank you!
I've been just debugging a process (in C++/windows) which uses "GetThreadContext" which is in kernel32.dll.
I noticed that I could get it's address with
unsigned long address = (unsigned long)(&GetThreadContext);
but when I looked at the loaded modules tab - I saw that the symbols for kernel32.dll were not loaded!
How did the VS2008 know the address of "GetThreadContext"?
And how can I do it myself without having the PDBs?
thanks :)
This works for the same reason that
GetThreadContext(hThread, lpContext);
works. Named functions used in your code must be resolved at link-time, or the link would fail. Whether you are taking their address using & or calling them does not matter. At runtime, the DLL is loaded and the function name then resolves to a specific address in the process.
PDB files are used only to provide enhanced symbolic information during debugging. Normally, they are not used at runtime.
[I can't help thinking I'm missing something about this question. Tell me if this is not your problem.]