I am trying to figure out how to get the function of a module + offset of a thread. Similiar to how Process Explorer does in it's thread display. Example....
ntdll!TplsTimerSet+0x07c0
I can pull the start address with no problem, and I can also resolved the start address to the module. I can get the start address to show "ntdll.dll" plus the offset (startaddress - baseaddress), but not the function. So mine looks like this..
ntdll+3BC0C
I would like to locate which function of the ntdll dll the offset resides in. In this case the function is Tplstimerset. I know that I will have to calculate the diffence of the offset and the address of the function, but that should be easy. This code can be in C++ of Delphi/Pascal. Thanks in advanced.
In Process Explorer -> Options -> Configure Symbols, you can see symbols files are used in order to resolve functions.
These symbols are from Microsoft and both windbg and Visual Studio are using them when debugging.
If you started windbg and have loaded one executable file, type "x ntdll!*" to show all named functions of ntdll, the asterisk means it matches all.
I assume you need to get the addresses of named functions programmatically, you may need the .pdb file specification.
Related
We have an application software running on Suse linux. What I want is that whenever there is a crash/fault in the software, a backtrace is generated with call stack information for the current thread(which faults).
We are currently using "backtrace()" and "backtrace_symbols_fd()" to try to get the trace but there is not much useful information. It does not give function names, line no. and filename.
Therefore, I starting looking for alternate options to use and found "libunwind". Wrote a small function to get backtrace and it does print function name with other register values(ip,sp). But still I can not get the filename and linenumbers. Is there a way I can programmatically do that ? What happens if I strip my binary file? Can I still get the filename/lineno info ?
Tried a lot different things, but what should be a simple thing never works for me. VSP file downloaded, but doesn't show my function names, only hex codes. It does give an error:
Error 1 DA0002: It appears that the file was collected without properly setting the environment variables with VSPerfCLREnv.cmd. Symbols for managed binaries may not resolve. C:\work\AbleAzure\Downloaded Profiling Logs\AbleAzureWeb24201441226PM\AbleWebRCore_0_(f1da3c).vsp 0 0
I checked the folder C:\work\AbleAzure\Downloaded Profiling Logs\AbleAzureWeb24201441226PM, it has all the PDB files in it.
I have no idea about the error "the file was collected without properly setting the environment variables", is it the Azure side or local? I don't see any place to set variable for Azure side.
Screenshot:
When you make the call to VSPerfReport to visualize your report, you need to specify the symbol locations:
https://msdn.microsoft.com/en-us/library/dd255404.aspx
They must match the versions etc.
The Map file looks like:
0002:000442e4 00000118H .idata$2 DATA
0002:000443fc 00000014H .idata$3 DATA
0002:00044410 00000b7cH .idata$4 DATA
0002:00044f8c 0000512eH .idata$6 DATA
0002:0004a0ba 00000000H .edata DATA
The Crash info looks like:
Application Error : The instruction at "0x00458ae1" referenced memory at "0x00000074". The memory could not be "read".
I'm trying to get a stack dump on the next crash, but it seems to me this is a case where we trounced the stack, then did a return, which made us end up executing data.
I'm not entirely certain though because I read some articles like this: Under the Hood Article seems to indicate this is an area of imported method names
The data that an import library provides for an imported API is kept
in several sections whose names all begin with .idata (for instance,
.idata$4, .idata$5, and .idata$6). The .idata$5 section contains a
single DWORD that, when the executable loads, contains the address of
the imported function. The .idata$6 section (if present) contains the
name of the imported function. When loading the executable into
memory, the Win32 loader uses this string to call GetProcAddress on
the imported function effectively.
Without a stack backtrace I'm kind of stuck. Am I looking at this crash the wrong way?
Forget MAP files, better use PDB files. For this enable linker option /DEBUG - yes, even for Release builds. /DEBUG is linker option, _DEBUG is compiler option. Only _DEBUG controls the code, and any conditional compilation that source/headers have put against this.
Debug builds have optimizations disabled, _DEBUG macro enabled.
Release builds have optimizations enabled, _DEBUG macro disabled.
/DEBUG would just put debugging-information into the EXE/DLL, and wont affect anything else.
Coming back to problem, when crash occurs. Do NOT close the application when WER (Windows Error Reporting) says it crashed. Instead keep it there, goto Task Manager, goto Process tab, select that crashed/crashing process, and hit "Create Dump File". Dump file (full-dump) will be created in some local folder (the path will be shown by task-manager). You can now close the crashing application (the WER window).
Now copy this .DMP file into some safe location, preferably the folder having your original Release folder. Open it in Visual Studio or WinDbg. On VS, just hit F11/F10, and you will be shown call stack. If multiple threads are running (in your crashed application), launch "Threads" view, and see the only suspended thread, double click it and you'll find the crash location.
You must have correct PDBs along with all binaries, and absolutely same code to see Code, otherwise call stack wont be good.
To get more information about PDB and stuff, you can read this article.
i have a problem using inno setup. I'm installing an update with inno, and with the update.exe the user get a txtfile with a licencenumber. On his Unit this licencenumber readable by a dll function.
Before the installingprocess i have to compare these numbers. Only if this numbers are identical the user is trying to installing the update on the right machine with the right licence.
If i would put this check into an seperate exe, it would be easy to crack it by change the exe with one just doing nothing (no errorcode). So i want to split the checking into the seperated exe (where i check some other things like installed version number etc.) and the update.exe
In update exe, i want to read the txtfile inside the updatepackage - this is easy.
In check.exe i want to call the internal dll and get the licencenumber of the machine. I have to return this number as an int. C# allows me to do that.
But how can i get this number in innosetup?
I tried to take the errorcode for this (0=error - not right version etc, XXXXXXXXX = licencenumber of machine). But the errorcode is just 2 chars in inno. I get only 2 chars...
Saving the number in another file would'nt be a solution cause the user can crack it this way... Is it possible to get the number into inno without giving the user the chance to manilpulate??
If you move the code into a DLL (either COM or a plain stdcall DLL) then it can be used by Inno and pass extra data between them including full strings, etc.
I came across echofunc.vim today (from a link in SO). Since I'm rubbish at remembering the order of function parameters, it looked like a very useful tool for me.
But the documentation is a bit lean on installation! And I've not been able to find any supplementary resources on the internet.
I'm trying to get it running on a RHEL box. I've copied the script into ~/.vim/plugin/echofunc.vim however no prompt when I type in a function name followed by '('. I've tried adding
let g:EchoFuncLangsUsed = ["php","java","cpp"]
to my .vimrc - still no prompting.
I'm guessing it needs to read from a dictionary somewhere - although there is a file in /usr/share/vim/vim70/ftplugin/php.vim, this is the RH default and does not include an explicit function list.
I'm not too bothered about getting hints on the functions/methods I've defined - just trying to get hints for the built-in functions. I can see there is a dictionary file available here which appears to provide the resources required for echofunc.vim, I can't see how I set this up.
TIA,
It expects a tags file, the last line of the description describes exactly how to generate it:
ctags -R --fields=+lS .
It works here with PHP but not with JS. Your mileage may vary.
I didn't know about this plugin, thanks for the info.
You should try phpcomplete.vim, it shows a prototype of the current function in a scratchpad. It is PHP only, though.