 |
|
 |
It would help if there was something in the article header indicating this is only relevant to C++.
|
|
|
|
 |
|
 |
I use some libs to speed up compilation.
I have to set .cod output also during thees builds of course, but then all information are reported into .MAP ?
Thanxs for your valuable information.
Davide
|
|
|
|
 |
|
 |
Hello,
When I released the build to my customer, I did not set any .MAP or .COD options. Now the customer is reporting a crash with offset number 74725c7b
When I rebuilt the project with .MAP and .COD options, the MAP file shows only upto 3 segments 001, 002 & 003. And the offset which the customer report does not exist.
What should I do. Is this because the customer build was made without .MAP and .COD options.
What should I do?
Regards,
Gautam Jain
|
|
|
|
 |
|
 |
Even though your customer build was without .MAP and .COD options it should still be the same (provided you didn't make any code/config changes of course). It's just extra info the linker spits out. If the offset doesn't make sense, there must be a difference.
Regards,
azerty666
|
|
|
|
 |
|
 |
Cheers!!! Indeed it was useful information, thanks a lot
cheers
Balkrishna
|
|
|
|
 |
|
 |
Hye,
This is just a discussion and does not have any relationship with the article...
I want to know any tool or the way from which I can get the name and parameters, return types (in short signatures) of all exported functions of a particular DLL...
I know DEPENDS.exe that comes with VS but it does not give parameter information.. Only gives function names (that also if the dll has proper .def file...
If anybody knows, please let me know...
Jigar Mehta
(jigarmehta@gatescorp.com)
Software Developer
Gates Information Systems
|
|
|
|
 |
|
 |
Hi,
When I run the you demo exe and click the "Generate Error" button, I go the access violation error with the fault address 0x00401CC1. I don't see any offset address. Can anybody tell me how to find the offset address?
Note: I normally used to start the application in the Visual Studio and open up the "Disassembly" to locate the fault address.
|
|
|
|
 |
|
 |
Program loads at address 0x00400000, leading 1 is the segment address and CC1 is offset address. However, demo exe generates error at address 148f, Do you re-compile it? In debug mode?
In Release mode you can not open-up Disassembly, you should compile in Debug mode; by this method explained in the article, this is not necessary.
By the way, yes, there is no need for .cod files. Building with /MAPINFO:EXPORTS /MAPINFO:LINES option under Link tab, makes compiler add line numbers into .map files also. I am trying to update the article as soon as possible. Thanks to Shaun Wilde
People, love each other!
|
|
|
|
 |
|
 |
Say, that messagebox says your program crashed in kernel32.dll at address pointed by CS:EIP (on 16 bit Windows) or just an offset.
Can you tell if the crash happened in some of exported functions? Or maybe you even know that the crash happened in one internal (not exported) one?
|
|
|
|
 |
|
 |
See also CrashFinder[^] by John Robbins (mentioned elsewhere). It loads up any dependent DLLs in addition to yours. If you have the latest Windows debugging tools[^], CrashFinder can use the symbol server facility to get debugging information for your running version of the system DLLs.
This program requires you to build debugging information for your release build. Contrary to popular belief, if you select a program database for your debugging information, debugging symbols are not included in your executable. All that's included in the executable is the original path to the debugging information, which is likely to be about 200 bytes.
One minor caveat is that setting the debug switch for the linker causes it to include all functions in all the objects and libraries mentioned on the command line. To revert to the normal linker release build behaviour, add the /OPT:REF switch.
The system DLLs all have their base addresses specified when they're built, so you can be reasonably sure that they haven't been relocated.
See John Robbins' book Debugging Applications for Windows and .NET[^] for more advanced debugging tips.
|
|
|
|
 |
|
 |
hi,
I have one solution that gives us some more clues to trace out the error root. But i m also searching the exact the error.
I like the appraoch to built application with static build which gives us more idea about the error.
1) So now add one more button in this application with
code given below to generate an error
GetDlgItem(NULL)->ShowWindow(SW_SHOW);
2)Build the application with the same settings given in artical ,but
with MFC shared library and MFC static library linking
3)Check the error report
4)In shared version it will show the error in mfc42.dll. So it's
difficult for us to know that where the error is in the application which is our motif.
5)In static build case, It will give us the error in the application itself and we will get the offset number that will be found in the .map file which indiactes that error is on the showwindow exported function.
what do u think?
|
|
|
|
 |
|
 |
hi coolvcguy!
That's a cool idea, but it seems, hm, artifical since VC users already have both pdb and map files for MFC (and for CRT) so no need to statically "inline" these libs to the program just for crash catching.
The question was about system dlls (such as kernel32.dll): how to find a crash function just having the address and e.g. dumpbin tool.
|
|
|
|
 |
|
 |
I first learnt of this technique from the book:
"Debugging Windows Programs: Strategies, Tools, and Techniques for Visual C++ Programmers" by Everett N. McKay and Mike Woodring
Addison Wesley, ISBN 0-201-70238-X
It includes many other tips and it certainly helped me when I was trying to debug someone else's code.
I thought it might be useful to someone else too.
|
|
|
|
 |
|
 |
Microsoft has a program called Crash Finder I think. Its part of thier debugging tools. It can automatically tell you which line of source the error occurs on if you supply a debug info file I think. I can't remember exactly, because my programs haven't crashed in a while
|
|
|
|
 |
|
 |
CrashFinder was part of the tools created by John Robbins (aka BugSlayer). You can find the BugSlayer articles at the microsoft site and links to all the code. I think John Robbins now works for Wintellect (before that it was numega) and has also written a number of books on the subject.
You can also save youself the effort of the cod files and tell the MAP file to add the line number information to your map file use /MAPINFO:EXPORTS /MAPINFO:LINES. you can then look up the line number in the map file and then look at that line on your source code (if you have labelled it properly and it hasn't changed since - great argument for source control here even if you are a developer working alone)
Also look into Structured Exception Handling and the use of .PDB files.
Technically speaking the dictionary would define Visual Basic users as programmers. But here again, a very generalized, liberal definition is being employed and it's wrong - just plain wrong - Tom Archer 5/12/02
www.many-monkeys.com
|
|
|
|
 |
|
 |
Hi,
I used CrashFinder, and it proved to be a useful tool.
However, it failed sometimes in case of release binaries.
Thank You for this article!
|
|
|
|
 |
|
 |
Well done
I'll have to look at that someday. Perhaps even write a tool for doing it automatically...
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
 |