The first offers die-hard functionality, but usually loading the crash dump in Visual Studio will provide us with enough information. Now where do we start? Exploring the contents of a dump file can be done with various tools, such as WinDbg (part of the Windows SDK) or using Visual Studio. Another option would be using SysInternals ProcDump – procdump processname -ma -e -x output_file.dmp will capture a dump when the application gives up. Note: not sure how to capture a crash dump? Check automatically capturing crash dumps to have Windows create a crash dump whenever a given application crashes. A minidump contains enough information to perform basic debugging operations, such as looking at stack traces, loaded modules and so on. File size is just over 40MB, so it’s definitely not a full crash dump. The difference is in the amount of data contained in the dump: a full crash dump has all sorts of details, including the data that was in memory at the time of the crash. dmp file, which means it could be a full crash dump or a minidump. They automatically captured a crash dump of the IIS worker process and attached it to the issue – this should help in diagnosing the root cause of that crash. One more coffee refill, and then let’s dive in! Nothing better than a good cup of coffee in the morning! Opening up the issue tracker, “the folks from IT” logged an issue about an application server crashing over night. Namespaces have been altered to protect the innocent. Here’s a story on how I once used dotPeek to provide debugger symbols and (decompiled) source code for a crashed application for which we had nothing but the application assemblies available.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |