I need to automatically analyse dump files from a process. If I have the process running, I can just check where a specifc dll is and work from there. But how can I get this working if I only have the dump? Read the whole file and... ? I am somehow out of ideas currently... I think what I need would be a way to map the dump as process(?). Maybe somebody here has an idea.
(if important, dmp is created from task manager, but that shouldn't matter I think).
Greetings
Related
As the question states. I am certain that it is possible, but I can't find information on the subject.
I'm doing this as an experiment right now, the idea is basically to do the following scenario:
boot up linux (just because I don't like windows)
do some random stuff
dump stack and heap memory to 1 or 2 files
do some other random stuff
load dump(s) back into memory
The effect I am trying to achieve is basically hibernate a system state, but keep the system running, then wake the previous state. Not sure where I would be able to use this, but it sounds like geeky fun.
EDIT: I thought searching for sysctl hibernate sources would help, but I can't even seem to find those.
Update:
So far I have found the following information:
https://www.kernel.org/doc/html/latest/power/swsusp.html
https://help.ubuntu.com/community/PowerManagement/Hibernate
https://alioth-archive.debian.org/git/collab-maint/hibernate.git.tar.xz
Continuing the search...
I think this is where I need to dig:
https://github.com/torvalds/linux/search?q=swsusp
Also, as #Useless stated in the comments, here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/power/hibernate.c?h=v5.14-rc6
EDIT: I thought searching for sysctl hibernate sources would help, but I can't even seem to find those
It'll need to be done in the kernel, since there's a load of kernel & driver state, and it needs access to all running processes.
You can start from power/hibernate.c.
If you just skip the call to swsusp_arch_suspend() increate_image(), you should be most of the way to creating the image and then immediately resuming.
You just need to figure out how to:
keep the hibernation state around that presumably now gets destroyed on resumption
run the restore/thaw half of the code later, when you're not already suspended
Is there any api's which load a crash dump, symbols from the symbol store and then allow programmatic access to the information?
I want to create a tool to auto process crash dumps and produce a report based on them.
Use a command file for Windbg which sets up your configs and then runs !analyze. Set windbg to output to a file (as described here: windbg: Command output to text file)
Then you can enjoy trying to sort, categorize, etc. the output from that. !analyzewill do a decent job of analyzing most crashes. If it can't, I doubt you'd be doing a better job with your own code, unless you have a lot of experience in analyzing crash logs by program (I haven't ever tried, although I have a decent idea of what to look for, I wouldn't necessarily want to write code to actually do it - I have written code to write logs when the system has crashed, so I know what you usually need).
The Windows dbghelp API loads symbols and line number information to support making stack back traces. Do not know API for reading crash dump files.
Debug diagnostic tool has a com interface that can load a dump, process it using symbols and give you the information back.
http://www.microsoft.com/en-au/download/details.aspx?id=26798
Tutorial: http://codenasarre.wordpress.com/2011/06/14/how-to-control-a-debugger-engine/
Is there a way to read the the import table of another process?
The function ImageNtHeader won't help me here, because it applies only to my process and not to the other process.
I know I can read the entire file and parse its PE header, but I'm afraid it will take a lot of time if the file is large.
Is there a way to do it using the process's memory directly and not reading from the file?
Any other easy and nice way to do it will be great as well :)
just use psapi or toolhlp32 to find the memory addresses of the processes modules you are interested in. once you have that you can use ReadProcessMemory get the required info. else just pretend to be a debugger and attach to the target process so you have full access to it's memory, then you can use the windows PE macros.
The title pretty much says it all..
What I'm trying to do is write a tool that will monitor a dll file containing a plugin and when I overwrite it, by recompiling, it should automatically reload it.
I know I can make a copy, load the copy and monitor the original, but I thought there might be a better way..
If I understood it right the dll is completely loaded into memory so there shouldn't be a problem in deleting the file..
No, that's not how Windows works. Loading a DLL merely creates a memory mapped file, nothing is actually read from the file beyond the relocations (if necessary). Not until your code calls an exported function. Which causes a page fault because the code wasn't loaded yet. Now the code gets read from the file into RAM. If space is needed for other processes then the pages simply gets unmapped. Getting reloaded again on the next page fault.
The MMF puts a hard lock on the file. You can only rename it, not overwrite or delete it. That would crash the program. Release the lock with FreeLibrary().
Haven't tried it, I'm not on my Windows machine right now, but I think that Windows locks the file against writing when loading a DLL. You should check that first, can you actually overwrite the DLL (e.g. by compiling a new version) or does the compiler complain with "permission denied".
Otherwise I suppose you could use the file change notification API to achieve your goal.
I'm dealing with some hundreds of thousands of lines of code, and I'm stumped where this process is accessing a particular file. I've given up searching the code, I just cannot find out.
So, here I am -- asking a question I'm almost certain there is no simple solution for.
I've tried FileMon, ProcMon from SysInternals, and while I can see the file got accessed, it doesn't show the call stack or any useful piece of information.
I wish I could break into the debugger when that happens; I thought maybe I could write some extension for FileMon that would signal to me when an access happens, and then I could throw a Debug.Break into my process.
Any insight or ideas appreciated.
Set a breakpoint on CreateFile(). Write one in main() so you can easily trace into it an find the API entrypoint. Switch to disassembly view before single-stepping.
Is the file created by the program or is it pre-existing? What would happen if you renamed the file on disk, maybe that could help you get a stack trace? If it's generated by the program does the file name adhere to a specific pattern, maybe you could look for the format string that populates this pattern, e.g. "c:\%d-%d-%d.txt", and then look for the lines that use this string.