search

rdmenezes / crashrpt

Automatically exported from code.google.com/p/crashrpt
0 stars 0 forks source link

need documentation on using VS to view .dmp files #45

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. do a clean build of release, send to tester.
2. tester causes crash, sends crash report back
3. double click .dmp file, it opens new instance VS??
4. what do i do now?  

What is the expected output?
--> it will load exe and act like it just crashed, but in my debugger

What do you see instead?
--> a new sln with "crashdump.dmp" in it, click it and nothing happens

What version of the product are you using?
--> latest

On what operating system?
--> win 7 64

Please provide any additional information below.
--> let me know what you need

Original issue reported on code.google.com by anbaricf...@gmail.com on 23 Jul 2010 at 8:44

GoogleCodeExporter commented 9 years ago 
note: i'm not using VS.NET, i'm just using visual studio C++

Original comment by anbaricf...@gmail.com on 23 Jul 2010 at 8:45

GoogleCodeExporter commented 9 years ago 
Please refer to this page 
http://crashrpt.sourceforge.net/docs/html/using_minidump.html.

Does this fix your problem?

Original comment by zexspect...@gmail.com on 24 Jul 2010 at 4:00

GoogleCodeExporter commented 9 years ago 
okay i tried following those instructions but i do not see a call stack.

Original comment by anbaricf...@gmail.com on 25 Jul 2010 at 4:43

Attachments:

GoogleCodeExporter commented 9 years ago 
Try the following:

1. Specify symbol path directories for the Visaul Studio. Open menu 
Tools->Options->Debugging->Symbols and enter the path to the directory where 
your PDB files and binaries are located. Then reopen the minidump (close the 
solution, open it again and press F5). 

2. Open the Modules window and check the symbol loading status for modules of 
your program. The status should be 'Symbols loaded.'. Loading paths should 
point to the  directory where you saved the PDB files and binaries. 

If symbols for some modules of your program are loaded, and you have the error, 
than there were no debugging symbols generated for the module where crash had 
occurred. 

If there are still no symbols loaded for any module, than the debugger can't 
locate the matching PDB files and/or binaries. Try to recompile the program and 
enable PDB file generation.

Does this fix your problem?

Original comment by zexspect...@gmail.com on 26 Jul 2010 at 12:40

GoogleCodeExporter commented 9 years ago 
Hmm.. after looking on your screenshot the second time, I see that you actually 
have stack consisting of one frame: 

kJams Pro.exe!MT_CrashPlease::operator()() Line 1158

It seems that you have correct PDB file at least for one module. Can you attach 
a screenshot of your Modules window?

Original comment by zexspect...@gmail.com on 26 Jul 2010 at 1:13

GoogleCodeExporter commented 9 years ago 
here is the modules window.  showing that both my app (kjams) and it's one 
dependent library (CFLite) are both loaded.  

note i'm using incredibuild which creates several pdb's.  see 2nd screen shot

Original comment by anbaricf...@gmail.com on 26 Jul 2010 at 8:01

Attachments:

GoogleCodeExporter commented 9 years ago 
It seems that everything is loaded ok. You have matching PDB files loaded for 
kJams Pro.exe and CFLite.dll. As these modules are major for your application, 
you are able to recover detailed stack traces for these modules.

In this particular case, the stack trace consists of a single frame. This may 
be because of optimizations enabled or because of something else that affects 
the stack trace accuracy. For my application, this happens sometimes, too. For 
example, if I generate report manually on hot key press, the stack is not as 
accurate as I expect. 

I think IncrediBuild shouldn't affect the stack trace. I read their FAQ 
http://www.xoreax.com/support_faq.htm and it seems that this tool generates the 
correct debugging information. 

I would advice you to do the following:

1. Try to read the minidump with the crprober.exe tool that presents in 
crashrpt archive. You can find the info here 
http://crashrpt.sourceforge.net/docs/html/crprober_tool.html. For my app, it 
sometimes generates better stack traces than Visual Studio. Test how 
crprober.exe opens minidumps of your application.

2. Continue testing your application with crash reporting enabled, or release 
it to public. When many crash reports are received from testers or from users, 
you will be able to determine how many stack traces are valid and how many are 
not. Compare how those reports are read by Visual Studio and crprober.exe.

Original comment by zexspect...@gmail.com on 27 Jul 2010 at 1:39

GoogleCodeExporter commented 9 years ago 
The documentation on how to open crash minidump was improved in v.1.2.7.

Original comment by zexspect...@gmail.com on 10 Oct 2010 at 2:34

GoogleCodeExporter commented 9 years ago 
Issue 64 has been merged into this issue.

Original comment by zexspect...@gmail.com on 15 Oct 2010 at 12:43