Oh Noes, My Code Is Teh Crash!
My Code is Crashing. Help!
A common request for assistance in the General Programming forum involves code which is crashing, often for mysterious reasons. When posting a thread discussing a crash, there are a few important things you should do.
1. Understand what the crash really means
That scary-looking message with all the strange numbers is actually remarkably useful in figuring out what has gone wrong. You should read this article to understand what the numbers mean and why the error message is significant and not just arbitrary or random. In fact, that article has great tips on solving some of the most common crashes, so take a look at it before posting - it may solve your problem for you!
2. Catch the crash in your debugger of choice
Knowing what code crashed is just as important as knowing how it crashed, and both will lead you to the why. If you are not familiar with using a debugger, it is strongly recommended that you brush up on that skill before posting. This will almost certainly be the first thing someone asks you, so be sure the answer is, "Yes, I've caught the crash in a debugger." Answering "yes" to this question will enable you to successfully complete the rest of the recommendations in this FAQ.
3. Include a complete copy of the crash error message
In case the article linked under Point 1 above didn't make it clear, the error message is very important. Include a complete copy of the error in your post: all the numbers, codes, scary-looking gibberish, everything. This information will go a long way towards helping an experienced programmer spot the problem.
4. Provide a call stack and the code of the crash site
Obtaining a call stack for a crash is Debugger Usage 101. You should be prepared to provide this in your thread; in fact, if you can provide it up-front in the initial post, so much the better! Call stacks give important context as to how the program got to where it's at, and what has potentially gone wrong.
Call stacks are mandatory if you are posting about a crash that doesn't appear to be directly in your code.
Even better, provide the line of code (and possibly the lines leading up to it) that actually triggered the crash. If the crash is in your code, provide any context about what you're doing that you think might be useful. More information is always better than less information. If the crash is in someone else's code (e.g. inside a library or API call), provide the code of the crash itself and the code of the first place in the call stack where your own code is running.
For example, if you have a function MyCode() in which you call FooAPI() and it crashes, provide the line of code (if available) from the Foo code that crashed, and the code in MyCode() where you originally started out. This gives important context and might illuminate ways in which you have accidentally misused the API.
5. Always detail what you have already tried and what didn't work
Before posting, it is good etiquette to try and solve a problem yourself. When doing so, please provide a rundown of all the things you tried to do to diagnose and fix your problem. This will help others zero in on the real source of the issue as well as avoid offering you options that you already know won't work. Everyone wins!
Happy Bug Hunting!