PuTTY Bug Reporting

Home | Licence | FAQ | Docs | Download | Keys
Mirrors | Updates | Feedback | Changes | Wishlist

Bug reports and feature requests should go to the address putty@projects.tartarus.org.

I get a lot of mail about PuTTY, and I don't have much time to answer it. To make my life easier, I would like people to do these things:

• Check the list of known bugs and see if I already know about the problem. If I do, don't bother telling me, unless you have extra information that might help me fix it.
• Check the change log and see if I have already fixed the problem in the latest version (or even since the latest version). Also, download the latest development snapshot and see if the problem still happens with that.
• Tell me what version of PuTTY you are running. Use the "About PuTTY" option from the System menu. Please do not tell me "I'm running the latest version", because e-mail can get delayed and I may not know precisely which version you mean. Tell me the actual version number, or the date you downloaded the source snapshot if you're building from source.
• Tell me what version of what OS you are running PuTTY on.
• Tell me whether you are connecting using Telnet or SSH (or raw mode).
• Try to give me as much information as you can to help me see the problem for myself. People send me reports like "When I use PuTTY, the font is not right". Now when I use PuTTY, the font is right. So they must be doing something differently from me, like using a different font, a different OS, selecting the font at the wrong time, or something, and I need to know what. Give me lots of details. Details are good.
• Read your comments back to yourself and ask if they make sense. Try not to use pronouns like "it" without making it very clear what they refer to ("I typed this and it hangs"? What hangs? PuTTY, or the other end of the connection?). Be repetitive: I'd much rather get a report that says "the screen displayed by the Foo application" ten times and is clear, than one that says "it" nine of those times and is ambiguous.
• Try not to assume I know what you wanted to happen. "I Ctrl-C out of more to my shell and what is on the screen is not right" doesn't help me, because I don't know what was on the screen, or what the user expected to see. If you think something is not right, tell me exactly what it is, and exactly what you think it should be.
• If you think you can, try fixing the problem yourself. One good way to help describe a bug is to send me a change to my code and say "When I put this in, it starts working again". Always tell me which version of PuTTY you made the change to (and again, don't just tell me "the latest version" - tell me on what date it was the latest).
• Try reading my essay on How to Report Bugs Effectively. If your bug report is particularly unclear, I may ask you to go away, read this essay, and then report the bug again.

If you request an extra feature in PuTTY, do bear in mind that I have a real job and an active social life and I do have better things to do with my time than write code for PuTTY. Try to do some of the work for me.

• Check the feature wish list and see if I already have your feature on the list. If I do, you don't need to request it again.
• If you can program, try writing the feature yourself and send me the patch or the modified source code - but do remember to tell me which version of PuTTY you started with, or I will not be able to merge your changes in easily.
• If you can't program, at least try to do the design. Specify exactly what you want to see, and think about difficult cases (because if you do, I don't have to). You'd like PuTTY to put its icon in the System tray rather than the Taskbar? Then tell me how you expect a user to tell the difference between two PuTTYs, if there is more than one at a time. You'd like printer support? Then tell me whether you'd like to see the "which printer?" dialog at startup time, or the first time you try to print, or every time you try to print, or what.

I have very little patience for people who demand that I spend several days making them happy; I have a lot of time for people who spend several of their days making themselves happy and then share the result. The free software movement is entirely built on the idea that if you want it done, you do it rather than complaining at other people.