B.2 Reporting bugs

If you think you have found a bug in PuTTY, your first steps should be:

• Check the Wishlist page on the PuTTY website, and see if we already know about the problem. If we do, it is almost certainly not necessary to mail us about it, unless you think you have extra information that might be helpful to us in fixing it. (Of course, if we actually need specific extra information about a particular bug, the Wishlist page will say so.)
• Check the Change Log on the PuTTY website, and see if we have already fixed the bug in the development snapshots.
• Check the FAQ on the PuTTY website (also provided as appendix A in the manual), and see if it answers your question. The FAQ lists the most common things which people think are bugs, but which aren't bugs.
• Download the latest development snapshot and see if the problem still happens with that. This really is worth doing. As a general rule we aren't very interested in bugs that appear in the release version but not in the development version, because that usually means they are bugs we have already fixed. On the other hand, if you can find a bug in the development version that doesn't appear in the release, that's likely to be a new bug we've introduced since the release and we're definitely interested in it.

If none of those options solved your problem, and you still need to report a bug to us, it is useful if you include some general information:

• Tell us what version of PuTTY you are running. To find this out, use the ‘About PuTTY’ option from the System menu. Please do not just tell us ‘I'm running the latest version’; e-mail can be delayed and it may not be obvious which version was the latest at the time you sent the message.
• PuTTY is a multi-platform application; tell us what version of what OS you are running PuTTY on. (If you're running on Unix, or Windows for Alpha, tell us, or we'll assume you're running on Windows for Intel as this is overwhelmingly the case.)
• Tell us what protocol you are connecting with: SSH, Telnet, Rlogin or Raw mode.
• Tell us what kind of server you are connecting to; what OS, and if possible what SSH server (if you're using SSH). You can get some of this information from the PuTTY Event Log (see section 3.1.3.1 in the manual).
• Send us the contents of the PuTTY Event Log, unless you have a specific reason not to (for example, if it contains confidential information that you think we should be able to solve your problem without needing to know).
• Try to give us as much information as you can to help us see the problem for ourselves. If possible, give us a step-by-step sequence of precise instructions for reproducing the fault.
• Don't just tell us that PuTTY ‘does the wrong thing’; tell us exactly and precisely what it did, and also tell us exactly and precisely what you think it should have done instead. Some people tell us PuTTY does the wrong thing, and it turns out that it was doing the right thing and their expectations were wrong. Help to avoid this problem by telling us exactly what you think it should have done, and exactly what it did do.
• If you think you can, you're welcome to try to fix the problem yourself. A patch to the code which fixes a bug is an excellent addition to a bug report. However, a patch is never a substitute for a good bug report; if your patch is wrong or inappropriate, and you haven't supplied us with full information about the actual bug, then we won't be able to find a better solution.
• https://www.chiark.greenend.org.uk/~sgtatham/bugs.html is an article on how to report bugs effectively in general. If your bug report is particularly unclear, we may ask you to go away, read this article, and then report the bug again.

It is reasonable to report bugs in PuTTY's documentation, if you think the documentation is unclear or unhelpful. But we do need to be given exact details of what you think the documentation has failed to tell you, or how you think it could be made clearer. If your problem is simply that you don't understand the documentation, we suggest posting to a newsgroup (see section B.1.2) and seeing if someone will explain what you need to know. Then, if you think the documentation could usefully have told you that, send us a bug report and explain how you think we should change it.