I receive from an application a message like this:
"The instruction at 0xA.... referenced memory at 0xB..... The memory could not be "written". Click on OK to terminate the program"
the address 0xA looks valid: 0x10001053. Exe is mapped in memory by default at 0x40000000 and dlls at 0x10000000 so it's in the first loaded dll at offset 1053h.
Does someone knows a method to transform this address into source line ?
You should be able to locate it with the help of a map file. You may need to tweak some of your compiler/linker options to get the map file generated with sufficient detail.
If you are using the MS compiler then you need /MAP linker option.
If you have an interactive debugger, open the disassembler window and look for the code label that precedes the assembler line. That should correspond to a function in the source code (or to a function that has inlined the code that caused the problem).
Another trick is to use the call stack window, that way you could see all calls from the main function down to the function that caused the crash.
Related
I'm trying to debug a crash in an exe where my own code is in a dll the exe is loading. I have an assembly only callstack in the exe, and managed to trace back to my own code and find addresses of my own objects that I wish to debug.
However I don't seem to be able to cast the memory addresses to my own types in the watch window: I just get 'identifier "(my type)" is undefined'.
I am guessing this just isn't possible when I'm not in a stack of my own code, but it seems like the debugger could know the types if I could give it more information somehow.
I have tried a few of my own types but all give identifier undefined.
I also looked into exported symbols for my types to see if there was something there I could use (based on a suggestion in another SO post), however I think the pdb itself contains the type information I need to point the debugger at.
Of course my pdb is loaded for my own dll, but the watch window seems to not want to look at it when not related stack frames.
Try to specify your dll's module name, like (yourDll.dll!mytype*)0x12345678
See also https://learn.microsoft.com/en-us/visualstudio/debugger/context-operator-cpp?view=vs-2019
I have a freescale mpc565 powerpc, I have a copy of the raw firmware I have read from the device and I have decompiled it within Ida pro.
Is it now possible to debug the assembly using trace32 and a bdm without the original elf file and none of the symbol information?
I would like to step through the assembly and view the ram contents.
I could possibly use the trace32 api to write something that will achieve this however I don't know hurdles I will need to jump due to not having the original source of symbol tables.
Any help much appreciated.
Stepping through the assembly and debugging the assembler code (so setting breakpoints etc) is no problem.
But: without the symbol information/original elf file, you are limited to only assembly. Meaning: If you for example try "Break.Set main" (so set a breakpoint onto the entry of the main function), this will not work, because the debugger does not know what address the "main" function has.
The debugger will report "symbol not found" in this example (because it does not know anything about the "main" function).
Additionally the debugger will not be able to display the source code matching to a bunch of assembler instructions.
I hope this helps.
I am writing a C++ Qt application, and I try to profile it so I can see the slow functions in it.
I use Very sleepy CS in order to achieve that. But when in debug mode I get the function names and nice callstack information, I only get hexadecimal address and no callstack in release mode, but performance profiling should be done in release mode because debug mode does a lot of stuff (it's already 8/10 times faster just by switching mode ^^).
I've try to generate a .map file but, it seems that the offset present in the file only contains information about the address IN the .exe file (these informations are similar to those in a ELF file, but are outside the executable).
So I would like to know, is there a way to get the symbols name by their address at runtime (like if I get the start adress of the programm, the offsets will make sense, as it can be done with ELF file, get the stack start in /proc/pid/map file and offset with the symbols offset information)?
Or is it possible to generate a .pdb file without debug mode?
I've developed a program by a customer who's experiencing when he do a certain operation. This isn't happening always on the same place and on the same data and, moreover, it is not happening nor in my local developing machine nor in my test Virtual Machine (which is free of all developing equipment).
Given these conditions, I've decided to compile with MAP (enabled in Configuring Properties-> Linker->Debugger with option /MAP) to see which function is causing crash.
If I've correctly understood, when the program crash I've to check down the offset error and then, search in my MAP under the column RVA+BASE:
Address Publics by Value Rva+Base Lib:Object
0001:00037af0 ?PersonalizzaPlancia#CDlgGestioneDatiProgetto#MosaicoDialogs##IAEXXZ 00438af0 f DlgGestioneDatiProgetto.obj
0001:00038000 ?SalvaTemporanei#CDlgGestioneDatiProgetto#MosaicoDialogs##IAEXXZ 00439000 f DlgGestioneDatiProgetto.obj
Actually, my crash happens at offset: 00038C90 So I should think that it's somewhere in the method:
MosaicoDialogs::CDlgGestioneDatiProgetto::PersonalizzaPlancia
but this is not absolutely possible, so assuming that the computer can't be wrong, I'm the one who's doing it bad.
Can someone explain me how to read MAP in correct way?
don't bother - instead, build the project with symbols enabled and strip them into a pdb file.
Modify the program a little, to write a minidump when it crashes using a unhandled exception handler
Give the newly compiled program to the customer, and when it crashes call MiniDumpWriteDump.
Ask the customer to send this .dmp file to you, and you then simply load it up in Visual Studio (or WinDbg) and it will match up the symbols to the program, and will also match up the code. You should be able to see the exact line of code and some of the variables involved. (if using VS, when you load the .dmp file, top right corner will be an option to "start debugging" click that as it will 'start debugging' at the point of the crash)
Try it first locally - put a div by zero error somewhere in your program and see if you can debug the dump after its been run. Note that you must keep the exact same symbol file for each build of your program - they match exactly. You cannot expect a symbol file for one build to match another build, even if nothing changed.
There are tutorials for this kind of thing, such as this one from CodeProject that looks like it describes what you need.
Reading of MAP files to find out crash location is explained nicely in this code project article.
http://www.codeproject.com/Articles/3472/Finding-crash-information-using-the-MAP-file
Hope helps.
For postmortem debugging, there's an alternative that would not required the use of a map file. Rather, it would require you to create a simple registry script to enable some WER (Windows Error Reporting) flags to trap the crash dump file. First, build your application with debug symbols. Then, follow the instructions for Collecting User-Mode Dumps. Basically, you create a sub key under the "LocalDumps" key. This sub key must be the name of your application, for example, "myapplication.exe". Then, create the "DumpCount", "DumpType", and "DumpFolder" keys/values. Have the user run the registry script. This will enable trapping the dump locally. Then, have the user force the crash to collect the dump file. The user can then send the dump file to you to debug using the symbols you created earlier. Lastly, you'll need to create a registry script that removes the keys/values you added to the registry.
I'm new in debugging with symbols (when no access to the testing machine is possible).
I already provided the client with Debug build with .pdb file but for some reason the dump file I get contains no entries specific to my .dll (although the customer insists the problem occurs there, in particular, the app hangs). The debug build was made with VC++ 2008 x86 (I also tried older VC++ 6.0 with no difference).
The stack trace customer provides looks like
ChildEBP RetAddr
01ece854 773f8e44 ntdll!NtWaitForSingleObject+0x15
01ece8b8 773f8d28 ntdll!RtlpWaitOnCriticalSection+0x13e
01ece8e0 02a92003 ntdll!RtlEnterCriticalSection+0x150
WARNING: Stack unwind information not available. Following frames may be wrong.
01ece8f0 02a8b4fa MyDllName!DllRegisterServer+0xbd2dc
01ece920 02a8b49e MyDllName!DllRegisterServer+0xb67d3
01ece930 02a8746c MyDllName!DllRegisterServer+0xb6777
01ece93c 029dc5ca MyDllName!DllRegisterServer+0xb2745
01ece99c 02a819e4 MyDllName!DllRegisterServer+0x78a3
01ecea80 02a09776 MyDllName!DllRegisterServer+0xaccbd
01eceb00 02a32506 MyDllName!DllRegisterServer+0x34a4f
01eceb58 029f44bf MyDllName!DllRegisterServer+0x5d7df
01ececdc 029f5e20 MyDllName!DllRegisterServer+0x1f798
01eceda0 029f76da MyDllName!DllRegisterServer+0x210f9
01ecedf4 291fe0ce MyDllName!DllRegisterServer+0x229b3
01ecee98 29365243 ClientAppName!Class.Method2+0x262
01eceeb8 293378d9 ClientAppName!Class.Method1+0x37
But I'm not sure what all of this exactly means. Does DllRegisterServer+0x229b3 mean "function which has address +229b3 to the address of DllRegisterServer in map file"?
In map file, I have something like
0002:0006d720 _DllRegisterServer#0 10137720 f DllName.obj
But when I sum 229b3 and 6d720, I don't have any match in the map file for the resulting value.
And why the stack trace shows DllRegisterServer as an address base? It's not the first address in the map file. There are many function before it, should they have negative offset then (seems meaningless)?
I guess I understand reading debugging things wrong, but can't figure out what exactly is wrong..
If I could find out the function names, this would let me move further.
Things get even more complicated as I don't think my .DLL has no critical sections but the customer insists it's my dll which causes entering a critical section and never getting out. For now, I don't yet know how to prove him wrong (or maybe find out that it's indeed my lib which somehow, indirectly, does this, maybe, Windows sockets or DNS resolve name to an IP address somewhere behind the scenes are using critical sections).
This recent blog post by Raymond Chen is exactly the answer you're looking for: Restoring symbols to a stack trace originally generated without symbols.
For some reason, the debugger (or whatever is producing that stack trace) is failing to find the debug symbols for your module, so it's doing the best it can with only the DLL's export table. To paraphrase Raymond:
Ugh. A stack trace taken without working symbols. (There's no way
that DllRegisterServer is a deeply recursive 750 KB function. Just by
casual inspection, you know that the symbols are wrong.)
To see how to fix this, you just have to understand what the debugger
does when it has no symbols to work from: It uses the symbols from the
exported function table. For every address it wants to resolve, it
looks for the nearest exported function whose address is less than or
equal to the target value.
Assuming you have the correct, matching symbols file (.pdb) for the version of the DLL that generated the stack trace, you can trick the debugger into loading the DLL as if it were a process dump, and then you can load the symbols for it:
C:> ntsd -z MyDllName.dll
NTSD is the Microsoft NT Symbolic Debugger, which is installed by default on all modern Windows versions. You can also use WinDbg, but I'm not sure if there's a way to use Visual Studio with this technique.
Once you've got the DLL loaded into the debugger with symbols, you can then let the debugger do the heavy lifting to decode the stack trace. See the blog post for more detailed examples of that.
I'd guess that your DLL is badly behaved and you're deadlocking on the loader lock.
See "Another reason not to do anything scary in your DllMain: Inadvertent deadlock" here