I'm debugging a module for which I have only the .exe and a .pdb without private symbols.
During the debug session I need to inspect an internal struct. Obviously this struct does not appear in the PDB since it's private - but fortunately I have an .h file where this struct is defined. Therefore I can build some dummy module that uses this struct and obtain a PDB file that contains this struct.
Now I have an unloaded module with the struct symbols, and I would like to load its symbols in order to cast some memory to that struct. (without unloading the original .exe I'm debugging, of course)
The problem: it seems that WinDbg only allows loading symbols for loaded modules...
My question is: Is there a simple way I could load my symbols from the unloaded module?
I've tried .reload /i /f MyDll.dll but I always get ...MyDll.dll - unmatched.
Setting the sympath did not help.
Any ideas?
A better way is .reload /unl MyDll.dll
Unloaded module list contains timestamp (for image/pdb matching) and image base address. Using /unl tells WinDBG to use that information.
You can force windbg to load symbols at a specific address e.g.
0:000> .reload /f /i MyDll.dll=77777777
c:\sym\MyDll.pdb - unmatched
0:000> lm
start end module name
00000000`55555555 00000000`55555555 notepad (no symbols)
00000000`77530000 00000000`7762a000 USER32 (deferred)
00000000`77777777 00000000`77777777 MyDll_77777777 (private pdb symbols) c:\sym\MyDll.pdb
The unmatched warning here is because windbg cannot tell that the symbols match the correct version of the module since it can find no timestamp or checksum.
Related
When I use the UI of IDA to load a binary file with debug info, a window which prints "DWARF info found" will come out and I can choose "Import file names/line numbers" to present the correponding source lines of certain addresses.
However, I find when I using command line to run ida like "idat64 -A -S'script' binary_name", idat64 would not load the DWARF without specific setting.
I tried to find possible setting to load the DWARF infos but failed. Could someone help me solve this problem?
I want to use
ida_nalt.get_source_linnum
and
ida_lines.get_sourcefile
to export the address-to-line mapping informations.
However, without loading the DWARF info, running the scripts will only print invalid results.
Let's say I had a file File.jl that had a module MyModule containing the functions foo and bar in it. In the same directory as the module-file, I had a script Script.jl, and I wanted to use the functions in MyModule in the script.
How would one go about doing this?
In order to find Modules that are not in the standard LOAD_PATH and be able to import them, you need to update your LOAD_PATH variable for the current folder explicitly
push!( LOAD_PATH, "./" )
then you will be able to import a module appropriately.
Note that, if the file is called File.jl and defines the module MyModule, what you should be importing is import MyModule, not import File. It is generally recommended you use the same name for the file as for the defined module in this kind of scenario, to avoid confusion.
Also note, As #crstnbr noted above, you can also simply 'dump' the file's contents into the current session by simply 'including' it; note however that this simply creates the module on the spot, so any precompilation directives etc will not be honoured.
Somewhat related questions / answers (disclaimer: by me) you might find useful:
https://stackoverflow.com/a/50627721/4183191
https://stackoverflow.com/a/49405645/4183191
You include the file with the module definition and call the functions in your script file:
include(joinpath(#__DIR__,"File.jl"))
MyModule.foo()
MyModule.bar()
# or just foor() and bar() if MyModule exports those functions
The #__DIR__ expands to the directory of the script file, see
help?> #__DIR__
#__DIR__ -> AbstractString
Expand to a string with the absolute path to the directory of the file containing the macrocall. Return the current working directory if run from a REPL or if evaluated by julia -e <expr>.
I need to strictly bind every core file generated by system to certain bin version of crashed application. I can specify core-name pattern in sysctl.conf:kernel.core_pattern, but there is no way to put bin version here.
How can I put the version of crashed program into core file (revision number) or any other way to determine version of crashed bin?
I'm using qmake VERSION variable in .pro file, which contains revision number from SVN. Its available by QCoreApplication::applicationVersion(), in my every bin by flag --version.
Assuming your app can get far enough to print out its version number without a core dump, you can write a small program (python would probably be easiest) that is invoked by a core dump. The program would read stdin, dump it to a file, then rename the file based on the version number.
From man 5 core:
Piping core dumps to a program
Since kernel 2.6.19, Linux supports an alternate syntax for the
/proc/sys/kernel/core_pattern file. If the first character of this
file is a pipe symbol (|), then the remainder of the line is inter‐
preted as a program to be executed. Instead of being written to a disk
file, the core dump is given as standard input to the program. Note
the following points:
* The program must be specified using an absolute pathname (or a path‐
name relative to the root directory, /), and must immediately follow
the '|' character.
* The process created to run the program runs as user and group root.
* Command-line arguments can be supplied to the program (since Linux
2.6.24), delimited by white space (up to a total line length of 128
bytes).
* The command-line arguments can include any of the % specifiers
listed above. For example, to pass the PID of the process that is
being dumped, specify %p in an argument.
If you call your script /usr/local/bin/dumper, then
echo "| /usr/local/bin/dumper %E" > /proc/sys/kernel/core_pattern
The dumper should copy stdin to a file, then try to run the program named on its command line to extract a version number and use that to rename the file.
Something like this might work (I haven't tried it, so use at extreme risk:)
#!/usr/bin/python
import sys,os,subprocess
from subprocess import check_output
CORE_FNAME="/tmp/core"
with open(CORE_FNAME,"f") as f:
while buf=sys.stdin.read(10000):
f.write(buf)
pname=sys.argv[1].replace('!','/')
out=subprocess.check_output([pname, "--version"])
version=out.split('\n')[0].split()[-1]
os.rename(CORE_FNAME, CORE_FNAME+version)
The really big risk of doing this is recursive core dumps that may crash your system. Be sure to use ulimit to only allow core dumps from processes that can print out their own versions without core dumping.
It would be a good idea to change the script to re-run the program to get the version info only if it is the program you are expecting.
As we learned recently, Microsoft has stripped type information from symbols in some versions of ntdll.
Imagine I have the source code of a library and I would like to publish public symbols, but remove some type definitions from that PDB, how would I technically achieve this, especially without breaking the PDB identity information (timestamp and checksum)?
I could not find a compiler switch in the online documentation that would allow me to pass a list of types to be excluded.
Note that I don't want to switch from private symbols to public symbols but reduce public symbols.
WinDbg comes with a tool named PDBCopy. The -f command line switch allows filtering public symbols:
C:\Program Files\Windows Kits\10\Debuggers\x64>pdbcopy /?
PDBCopy v12.00.30523
usage: PDBCopy <source_pdb> <destination_pdb> [-p] [-s] [-f] [-F] [-a] [-A] [-?]
[-p] remove private debug information
[-s] create new signature
[-f:{#file|symbol}] filter specific public symbols out of stripped pdb
[-F:{#file|symbol}] leave only specific public symbols in stripped pdb
[-a] leave all annotation symbols in stripped pdb
[-a:{#file|symbol}] filter specific annotation symbols out of stripped pdb
[-A:{#file|symbol}] leave only specific annotation symbols in stripped pdb
[-?] display this message
This exists at least since WinDbg 6.8. The -a switches have been added in WinDbg 6.12.
I have a memory dump (unmanaged process) .
How can I extract (using windbg) one of the dlls loaded into the process ? I mean actually saving the dll file into the disk
You can use the sos.dll inside windbg directory.
First, load the sos.dll in windbg:
.load clr10\sos.dll
Then use !sam OR !SaveAllModule to extract the modules on specific disk location:
!sam c:\notepad
To extract a DLL without using SOS, use the .writemem extension as follows:
discover the module start and end addresses using lmvm dllname
example output for ieframe:
start end module name
61370000 61fb8000 ieframe
calculate the length = end-start: ? 61fb8000 - 61370000
output: Evaluate expression: 12877823 = 00c48000
then save the DLL as follows:
.writemem C:\tmp\mydll.dll 61370000 L?00c48000
This is unlikely to give you the exact DLL as it was loaded from disk, fixing this up is non-trivial.
(Partly based on this article)
Yes, it's true. calc.exe will also pull up its multi user language interface information and attach it in memory, as will a lot of Windows programs like mspaint, photoviewer, etc.