crash-dumps

I have a crash dump for a customer's application built with a very old version of our dll (release build, don't have original symbols) that I've been analyzing in WinDbg. In order to get more information, I rebuilt the dll in release mode, with symbols this time, using the same compiler version and I believe the same settings as when the dll was originally built. I added the symbol file to my symbol path, but the WinDbg extension !itoldyouso tells me the module in the dump doesn't match the PDB file. Enabling SYMOPT_LOAD_ANYTHING doesn't help either. !itoldyouso tells me they don't match

I'm looking for a cross-platform crash handler. Google Breakpad looks promising, but it is sorely lacking any documentation, and requires a reasonable amount of fiddling to actually get going. What is a better alternative? All I need is the ability to reliably record crash dumps, stack traces, and CPU information at the time of a crash. Alternatively, what is the experience using Google Breakpad? Has it been great or horrible? Well, it turns out that google-breakpad is pretty nice after all. It's not totally easy to set up, but it's OK for what I need. I wrote a article about dumping the stack

I'm debugging a .NET 4.0 web application using a full crash dump and Windbg. I seem able to get all the versions of everything to match up however when I try to get the managed stack trace of all the thread I get OS Thread Id: 0x7cd4 (13) Child SP IP Call Site GetFrameContext failed: 1 For all of my managed threads. Any ideas what I'm doing wrong and how I can fix it? I was also getting this error, but I noticed that running !DumpStack does give me a trace when !ClrStack does not. According to this link it could just be a thread that has been scheduled but is not running. In other words not

First some background: I have a multi-threaded WinForms application that is doing interop to native dlls. This application crashes sometimes with unhandled exception and we are trying to investigate why does it happen. In order to facilitate it, I am creating a global exception handler and I plan to generate process dumpfile from it. Now coming towards question: as of now this application has handler for Application.ThreadException but it still crashes with unhandled exception. I am thinking of adding a handler for AppDomain.UnhandledException also although I am not sure if its going to help.

I've got a java application that half the time just hangs, and the other half the JVM crashes. Is there a tool I can use to see what's going on that makes it hang and/or crash? I'm using CentOS 5.6 There are two different cases. Application crash: Was that an OOM? NPE? What was the exception? If there was jvm crash you will see hs_err_.log ( http://java.sun.com/j2se/1.5/pdf/jdk50_ts_guide.pdf ) Looking at the file you may see if your own JNI caused a crash or JVM bug. Application Hang: I would start with visualvm or jstat (both are part of JDK). You can see current state of threads and check

I have a dump created from a managed application. I am using SOS/SOSEX extentions to ease my dump analysis. I'd like to list down the call stack of all managed threads as we do ~*kb with native applications. How do we do that? Justin Use the sos !EEStack command: 0:007> .load sos 0:007> !EEStack See SOS.dll (SOS Debugging Extension) This command will dump all managed threads ~*e!dumpstack with sosex, use ~*e!mk (~ - thread, * - all, e - execute this command, !mk - display managed stack. Most of the commands in sosex mirror the native command, but have the m (managed) in front of them. 来源：