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 | Privacy | 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 2017-04-28 16:52:45 +0100)