PuTTY semi-bug needs-removeable-media

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

summary: Starting a session fails with "There is no disk in the drive"
class: semi-bug: This might or might not be a bug, depending on your precise definition of what a bug is.
priority: high: This should be fixed in the next release.
present-in: 0.61 0.62 0.63 0.65 0.66
fixed-in: bf00bcd2a4fee0855567b62cff83a0006c7c3232 2016-08-30 (0.68)

We've had several reports of trouble where PuTTY will not start (a session, it sounds like, rather than at all) unless there is a disc in a drive with removeable media: "There is no disk in the drive. Please insert a disk into drive D:" (In all reports that have specified, it has been D: rather than another drive, but of course that's the most common removeable drive letter.) There's no obvious reason for this, such as a path set in the configuration or shortcut that refers to the removeable drive.

We've not run into this ourselves, or been able to reproduce it.

This is vaguely reminiscent of `pageant-dirhandle', but probably not the same thing.

The earliest version this has been reported with is 0.61. It appears that it was the addition of support for Windows 7 jump lists. that triggered this. (All reports that have specified an OS have been with Windows 7.)

A correspondent says

It appears to be hung / frozen at this function call.

Winjump.c/update_jumplist_from_registry/if (!SUCCEEDED(pCDL->lpVtbl->BeginList

The Windows documentation about ICustomDestinationList mentions calling the SetAppID function beforehand, and I figured out that you need to call SetCurrentProcessExplicitAppUserModelID before using SetAppID.

So, I added this to WinMain in window.c

       SetCurrentProcessExplicitAppUserModelID(L"PuTTY");

And tried again. Voila! No error. I did not have to add a SetAppID before BeginList.

The call stack when it hangs seems to indicate that it's trying to invent an App ID from things like filenames.

This seems like a harmless and useful change to make, so we've done so (using a different string for UserModelID).

Reports:


If you want to comment on this web site, see the Feedback page.
Audit trail for this semi-bug.
(last revision of this bug record was at 2016-08-29 20:17:13 +0100)