Jump to content

EvgenyK

Members
  • Content Count

    42
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

0 Neutral

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    VATSIM
  • Virtual Airlines
    No
  1. This is not always true. It is very easy to call correct code and cause it to crash, just because it expects correct data, but gets incorrect. Offen this is result stability/performance tradeoff.Also, don't get me wrong - dump is not silver bullet or magic wand, but what I'm trying to say that it is really powerfull tool for investigation of issues. In many cases it can provide you immediate answer to questions like "is that our code called module which crashed the FSX?". In cases where you can't get this answer immediately but have number of dumps for same issue very likely you will find something common in stack, memory addresses, or in loaded modules list. It is like asking customer questions you don't even thought to ask which he can't answer anyway, but you still getting those answers.Also, I don't suggest you to dig too much into dumps, because learning details can be really complex, but rather do all quick things you can do, like getting all stack, heap, modules, and other information. All you need to know to start is how to run analyzing scripts in windbg.exe.
  2. Ryan,Just a side comment: I've never seen PMDG asking people to share CTD dumps with you. Why wouldn't think about it? It is extremely powerfull tool in case you can't reach machine with a debugger. You will be able to see stack, heap, and other memory and process related things. You can also ask people to create dumps manually, in case issue is not causing CTD, this can be done by simple right click on the process in task manager, so it won't be hard for the customers.The only question is how to share dumps, because usually those are really huge (equal to process size in memory), so even zipping those will produce ernomously sized files.
×
×
  • Create New...