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.]
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 a device DLL Library "Device.DLL", I want to do a mask library of it "Mask.DLL". I only have the device DLL, not .lib.
My code:
// Load library
hLibHandle = LoadLibrary(L"Device.dll");
// GetProcAddress for my function
myDeviceFunc = (lpmyDeviceFunc)GetProcAddress(hLibHandle, "myDeviceFuncName");
// Calling function
myDeviceFunc();
This works very well in a Console Application, but no inside my Win32 DLL. When I run my MyDeviceFuncMask() from my Mask.DLL I get "Application has stopped working".
MyDeviceFuncMask() just do this:
EXPORT_DEFINE int MyDeviceFuncMask() {
// Load library
hLibHandle = LoadLibrary(L"Device.dll");
// GetProcAddress for my function
myDeviceFunc = (lpmyDeviceFunc)GetProcAddress(hLibHandle, "myDeviceFuncName");
// Calling function
int result = myDeviceFunc();
return result;
}
I've exported anothers functions and the DLL works well, for example:
EXPORT_DEFINE int TestFunc() {
return CONST_SUCCESS;
}
It's highly likely that your LoadLibrary call is failing, but there's not enough information here to diagnose it. So here's a list of reasons why LoadLibrary can fail:
It can't find the library. Read the documentation about naming, search order, etc.
The library is for the wrong architecture. For example, a 32-bit process cannot load a 64-bit DLL.
You're trying to load the library from DllMain, which will fail because the loader is holding the loader lock during DllMain to prevent the possibility that DLLs get loaded before the DLLs they depend on.
The DLL's DllMain returns FALSE from the DLL_PROCESS_ATTACH callback.
The DLL tries to do something in its DllMain that it shouldn't be doing (like calling LoadLibrary).
A transitive dependency of the DLL you're trying to load failed to load (for any of the previous reasons). For example, if you try to load foo.dll, and foo.dll is linked against bar.dll, then the loader will first try to load bar.dll, and perhaps that's what's failing.
In addition to outright failure, it's also possible to load the wrong DLL accidentally if the name conflicts with another DLL that's already loaded into the process. If you try to load foo.dll, but another foo.dll is already loaded into the process, you'll just get a fresh handle to the already loaded one. I believe you can load two DLLs with the same name only if you load it with an absolute file path.
If you do end up with a handle to the wrong DLL, that will likely result in the failure of a subsequent GetProcAddress. You can diagnose this quickly in the debugger by putting a breakpoint on your LoadLibrary call and then searching the OutputWindow to see whether another DLL of the same name has already been loaded. (But, really, you should be checking the return values of LoadLibrary and GetProcAddress anyway.)
I've made this a community wiki so others can add reasons why LoadLibrary can fail, and we can direct people here when they post questions about LoadLibrary failures.
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 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.
If I do a LoadLibrary("msvcrt.dll") do I need to initialize the CRT somehow? Section 2 in the following document seems to say that I do, but I just get an undefined symbol error for _CRT_INIT when I try to call _CRT_INIT:
http://support.microsoft.com/kb/94248
Edit: I should have said that this is for a program that dynamically loads all the dlls that it uses, hence the call to LoadLibrary("msvcrt.dll").
Call DllMain() in it. If it relies on the C runtime, it will call CRT_INIT.
But a far better question is if a program is using something in msvcrt, there's no need to explicitly load the dll and initialize it, so why are you doing this?
If you're working in C++, have you declared _CRT_INIT as extern "C"?
Have you tried using the DUMPBIN utility ( http://support.microsoft.com/kb/177429 -- if you haven't your PATH up yourself, you'll have to use the Visual Studio Command Prompt I think) with the /EXPORTS switch to see which functions are available from the CRT DLL, just to double check?
If you get stuck, VS2005 and earlier (and presumably later...) come supplied with the source code for the runtime library. For VS2005, this is in VC/crt/src, relative to the VS install folder. It looks like _CRT_INIT is the right name -- see crtdll.c and dllcrt0.c, and it's a C function.
You must not call _CRT_INIT() but call CRT_INIT() (if you really must)
The link you referenced refers to using CRT_INIT() only when "Using the CRT Libraries When Building a DLL", and even then it is only one of two alternatives; the first probably being preferable in most cases.