I'm trying to set a break point on kernel32!LoadLibraryW or LoadLibraryA.
I'm constantly getting:
Couldn't resolve error at 'kernel32!LoadLibraryW'
My symbol path is set to: srv*https://msdl.microsoft.com/download/symbols
Any ideas on how to fix that?
Set your breakpoint in kernelbase.dll instead.
I believe WinDbg uses the symbol name and not the exported function name when resolving the address. This causes issues for some of the functions that are forwarded to ntdll.dll and kernelbase.dll.
Sometimes you can append "Stub" to the function name when setting a breakpoint and sometimes you just have to know that the function is actually implemented in a lower-level .dll and set the breakpoint on the function in that .dll. You can also find it with tab-completion and a name like *!functionname*.
Related
gdb in msys, doesn't show the name of the function call. Next to the address of the function call I have normaly the name of the function like . Why it's not the case with this exe and how can I fix it? gdb console
Why it's not the case with this exe
Because GDB doesn't know what function address 0x4023d0 corresponds to.
how can I fix it?
Depending on what code resides at address 0x4023d0, and why GDB doesn't have a name associated with it, this may or may not be fixable. But there is not enough info for me to even begin guessing what code might be there.
I am not sure if I am phrasing the question correctly, but basically I want to know how the call instruction is generated when calling an imported function from another library.
For example
GetModuleFileName(...)
is compiled to
call 0x4D0000
where 0x4D0000 is the address of the imported function which is dynamic.
How does windows set those calls and would it be possible to circumvent it and set a custom address instead.
The address used in the call statement isn't dynamic. It's a relative address that's fixed at link time like a call to any other function. That's because the call is actually to a stub, and the stub performs an indirect jump to the real function. The indirect jump uses a memory operand that refers to location in the import table. When the executable (or DLL) is loaded by Windows it updates the import table with addresses of all the functions the executable or DLL uses in any DLLs it's linked to.
So if an executable a call instruction like this:
call _GetModuleFileNameA#12
Then somewhere else in the same executable is astub like this:
_GetModuleFileNameA#12:
jmp [__imp__GetModuleFileNameA#12]
And somewhere in the import table there is a definition like this:
__imp__GetModuleFileNameA#12:
DD ?
Windows sets the value of __imp_GetModuleFileName#12 in the import table when the executable (or DLL) is loaded. There's not much you can do change this, though it's not too hard to change the value after the executable (or DLL) has been loaded. Note that the import table might be located in a read-only section, meaning you may need to change the virtual memory protections in order to do this.
I remember seeing somewhere that you can specify which dll to get the address of symbols so that one can use that variable in the watch window. I can't for the life of me remember where I saw this. The best that I can come up with is Format Specifiers in C++.
The reason I want this is so that I can see the visibility status of a window and MSVS keeps saying that identifier "IsWindowVisible" is undefined.
I was trying to use something like the following in the watch window:
::IsWindowVisible(m_hWnd),user32.dll
Using:
this->IsWindowVisible()
results in Function CWnd::IsWindowVisible has no address, possibly due to compiler optimizations. which is why I'm trying to use the win32 call. Ideas?
http://msdn.microsoft.com/en-nz/library/y2t7ahxk.aspx
Haven't tried it, but it seems to me that IsWindowVisible(m_hWnd) should work, or maybe IsWindowVisible(this->m_hWnd).
How to know if the exported symbol from a dll is actually variable or a function ?
One way may be to look whether the destination address of the symbol resides in the .code section or not.
Another method could be to check the memory protection attributes of the selected section.
But all these methods seem to be unreliable.
What is the best way ?
i am building a C project with Xcode and when ever i build it it gives me this error:
ld: duplicate symbol _detectLinux in /Users/markszymanski/Desktop/Programming/C/iTermOS/build/iTermOS.build/Debug/iTermOS.build/Objects-normal/i386/linuxDetect.o and /Users/markszymanski/Desktop/Programming/C/iTermOS/build/iTermOS.build/Debug/iTermOS.build/Objects-normal/i386/iTermOS.o
Thanks!
This means you have defined the same symbol with global scope in (at least) two different source files -- either a function or a global variable called _detectLinux, and apparently in the files linuxDetect.c and iTermOS.c.
How to fix it depends on how you intend to use this symbol:
If you meant to define it in one file and use it in the other file, declare it extern in the other file.
If you only intend to use the symbol in the file that it is declared in, you can declare it static.
If the symbol is defined in both files, you can rename the symbol in one (or both) files.
If _detectLinux is a function, one common way to get this problem is to define it in a header file but forget to mark it inline. This would cause it to generate the function code in each file that includes the header (presumably _detectLinux.c and iTermsOS.c).
Alternately perhaps you copy-pasted the entire body of the function between the two source files instead of simply declaring the function in iTermsOS.c where I expect it's being called.
Well, that's not much information to go on. As the error says, the symbol _detectLinux is included in both linuxDetect.o and iTermsOS.o and when you try to link them together, there is a conflict since the linker does not know which of the two symbols to use. This might happen if you, for example, have a global variable with that name in a .h file which is used to build both files instead of declaring it in one place and declaring it as "extern" in the .h file.
What you need to do is look at where the symbol _detectLinux is originally declared, then trace through the dependencies for both linuxDetect.o and iTermOS.o to see why it is being included publicly in both.