The Old New Thing

Interesting about applications having to manage the call stack. I'm happy to see that the MVC model was pushed onto Vista. Makes me wonder about many things in the driver world (since I've been out of it for ~6 years), where drivers similarly had to call the next one below them (filter drivers, interrupt handling etc). One  are in particular, power management, was usually broken by not passing on correctly (or handling correctly) the power IRPs.

Though chaining in drivers is probably more necessary than in clipboard notifications.

Wow, thanks Raymond! I see the light!

After I've followed the links you've given, especially after reading

http://blogs.msdn.com/ts/archive/2006/11/20/why-does-my-shared-clipboard-not-work-part-2.aspx

... I finally know why Copy-Paste in (the application that I will not name but it's the second most popular web browser, the first being the default one from Microsoft) doesn't work.

Now I know that they obviously "OpenClipboad" for whatever reason on some occasion ("to read what's there"), and obviously keep it in already opened state at the very moment I do my "Ctrl-C". Losers. The developers of the mentioned application happily ignore the issue for years now and that's why I stopped using it.

Yeah, I've hit a seemingly-related issue a few times, where something related to RDP sessions is locking the clipboard.  I'd start an RDP session to each of two different machines (because I do that every day), then start up various other programs.

At some point, local copy and paste breaks (that is, copying from a local process does not paste that data into any other local process), but disconnecting both RDP sessions and reconnecting fixes it.  (I'm not sure if both need to be disconnected, though; I've never tested disconnecting just one.)

That doesn't sound exactly the same as this problem, as the programs that don't work with copy and paste were started after the RDP sessions -- but restarting the RDP sessions does fix the issue.  Any kind of issue with the notifier chain that gets fixed with an RDP-session-restart should have only affected programs that added themselves to the chain before the RDP session.  (That is, programs after the RDP session in the chain.)  This also doesn't have anything to do with rdpclip; it's strictly a local-machine issue.

But hey, whatever.  (I should note, I don't expect any kind of support here; I'm just recording a sort of "I'm having that problem too; this is one way to get it working again".)  This post does at least explain one possible reason why it would break; thanks!

Obviously I'm guessing at which browser is suspected of holding the clipboard open, but one well-known alternative to IE uses OLE to copy and only opens the clipboard directly for long enough to make an internal copy to paste with.

If nothing else I now know it's safe to try killing rdpclip.exe next time I have remote clipboard issues. I know of some badly-behaved VB-based shareware that effectively kills the clipboard in a remote session to test with.

I think it would be nice to be able to find out what window/thread/process has the clipboard open so that I can terminate just the broken program. Maybe this is a job for Mark Russinovich.

I don't think I've come across a program that locks up the clipboard this way.  Usually when I can't copy or paste, it's because some bozo turned on Information Restrictions Management on an email message that I've minimized.

Mark Russinovich's name is spelled without a "t", but yes, this does seem like a job for Sysinternals.

I stopped using the second-bestselling web browser when I discovered the third-bestselling web browser.  Then I got a Tablet PC and went back to IE because #3 doesn't interact well with TIP.

Browser choice may have to change as people continue to code web sites that hit known IE bugs, but if so then I'm going to switch to #3 instead of #2, just to foil the FOSSers' dastardly plots.  (Example: Wikipedia images hit the "Operation aborted" bug in IE, either out of malice or accident.)

GetClipboardOwner() + GetWindowThreadProcessId()

?

The IE7 Pro extension gives IE much of what you'd want from #2.  Inline find, crash recovery, mouse gestures, super drag-and-drop, etc.

"The IE7 Pro extension gives IE much of what you'd want from #2.  Inline find, crash recovery, mouse gestures, super drag-and-drop, etc."

And the IETab extension gives #2 much of what you'd want from IE. Swings and roundabouts.

No, GetClipboardOwner tells you who put data on the clipboard (or promised to).

I seem to remember that the same problem for hook functions was fixed for Win32 (probably from being previously mentioned on this blog).

Damn, how many years I've been struggling with Firefox when Remote Desktop was open. I've even posted a bug report for FF. And I reckon they've even fixed it since.

It would be interesting to know why FF was more prone to this problem than other apps though, and how to workaround it.

And to let the critical voice out: Common sense would dictate that no faulty user apps should be able stop such a critical OS feature.

PS: Mark Russinovich is now at MS.

Holy crap! I knew I couldn't possibly be mis-typing CTRL+C that often. I thought I was going nuts for quite a while now when pasting wasn't working. = /

The clipboard isn't shared per Desktop, it is shared per WindowStation.  That distinction very rarely matters in practice, but isn't picking nits pretty much required here?

I wrote a clipboard tool once, it cached a clipboard history as well as letting you edit, import, and export most of the major clipboard data formats.  It's quite a fun little tool.  I had to deal with the "clipboard chain" so I could subscribe to clipboard events basically.  I recall that I had to be careful to revert the chain when I was done or else the entire chain could pretty much break.  I don't think the app ever crashed so I never got to see what happened (since it's .NET I should probably go back and write an unhandled exception handler to fix the chain).

"... I finally know why Copy-Paste in (the application that I will not name but it's the second most popular web browser, the first being the default one from Microsoft) doesn't work."

Works for me.  Unfortunately it can be difficult to track down the source of problems, but a good starting point is to see if it happens in safe mode or when using a fresh profile (start the browser with the -p switch to enter the profile manager).  Then if it does chances are it's a poorly written add-on.

I see lots of people wail on that browser without any hint that they made even minimal effort to track down the source.  All you need do is try safe-mode to see if it still happens.  If not then, if you're willing, you can narrow the problem down by disabling extensions and restarting normally until it goes away.  I had a couple problems I was ready to attribute to browser bugs but I tracked them to misbehaving extensions instead (one was a drive-by install by a download manager installer).

On the one hand your irritation is often justified, but on the other hand nobody should feel compelled to memorize and list the entire debugging steps they went through before giving up on it.  It's not safe to assume nothing was tried just because somebody doesn't mention trying things.

On a safe mode, fresh profile, firefox does this to me with, I would estimate, about 2-5% frequency (I only remember this happening from the address bar) -- this has been happening from FF 1.5 stable at latest and still happens in the latest FF 3 beta.  Whenever I use firefox I now just hit Ctrl+C twice in a row (well, truth be told, I hit the C key over and over like an overcaffeinated 7-year-old) and then I'm almost guaranteed to pick up the link.

This might be an artifact of the sort of sites I visit or some weird interaction with another running process, but it's not an artifact of extensions or my profile.

Funny that people have clipboard issues with Firefox - I abuse it tons (lots of open windows and lots of tabs in each window), and never come across it. And I use copy-paste a lot (when you execute the same sequence of commands over and over again... and a batchfile won't work (remote session, GUI, serial, ssh, telnet...), you copy and paste to fix). Or when you need to document output.

Strange, really. And my serial terminals do copy-on-select, too...

Gah. Forgot to mention - a program that locks the clipboard might be a fun prank to play on someone - have it remote controlled and it'll die when no one's around, but work when he shows anyone.

Also, I'm still on firefox 2...

Between the readers of this blog there are certainly many better developers than those working on #2.  Here's how Real developers would handle the issue of #2 mentioned earlier:

First, they would recognize that there is a problem (as the responses here can readily prove). And that it's not in the other extensions. More probably spelling checker, something from "don't be evil" company, or anything coming from Javascript or whatever.

Then, admitting the existence of the problem, the right way would be:

0) Not killing the bug reports, taking responsibility.

- Investigating from how many points the Clipboard can be opened.

- Making sure that the state of "being opened" in all recognized cases doesn't last any microsecond longer than really, really needed.

- Hooking directly on OpenClipboard and CloseClipboard discovering which of these sources does it too often, too long, simply wrong or whatever.

- If needed, redesigning the app so that all calls of given Win32 APIs go through some wrapper functions.

- This would allow doing something more than

if (!OpenCliboard()) WeDontCareThatUserWantedToCopySomething

- Having everything going through common points would allow enhancing them so that users with problems would be able to send the logs made at the time of failure.

Instead the problem just gets oh so very ignored. "I've spent only a few seconds in the application but I can't reproduce. And it's so boring fixing real problems when I can spend the time developing totally unneeded new features. Bug doesn't exist."

  <DllImport("user32.dll")> _

Public Function GetOpenClipboardWindow() As IntPtr

   End Function

 <DllImport("user32.dll", SetLastError:=True)> _

   Public Function GetWindowThreadProcessId(ByVal hWnd As IntPtr, ByRef lpdwProcessId As Integer) As Integer

   End Function

Public Function GetClipboardLocker() As String

       Dim hwnd As IntPtr = GetOpenClipboardWindow()

       If hwnd <> IntPtr.Zero Then

           Dim processId As Integer

           GetWindowThreadProcessId(hwnd, processId)

           Dim p As Process = Process.GetProcessById(processId)

           GetClipboardLocker = p.Modules(0).FileName

       Else

           GetClipboardLocker = String.Empty

       End If

   End Function

The real problem here is not the badly behaved applications. Any design of a shared resource must take these into account.

The real issue is why the clipboard has open/close semantics in the first place. Surely it only needs get/set semantics?

@Neil - thanks; as in Jay Parzych's code, I _meant_ GetOpenClipboardWindow... ;) (which may not work all the time, either)

molotov is correct: GetOpenClipboardWindow does not always work. For one thing, if the clipboard is open with NULL as the owning window handle, you're not going to be able to determine the owner. For another thing, it's quite possible that you can use any hwnd to open the clipboard, thus making the results unreliable.

Since Windows knows the actual thread/process that opened the clipboard (so it can close it when the process is killed), it should be possible to retrieve it somehow.

"The real problem here is not the badly behaved applications. Any design of a shared resource must take these into account."

Badly behaved applications are much easier with the Windows clipboard than with other shared resources, because the listener queue has to be maintained by applications themselves!

ANY buggy application in the viewer chain may break the chain or even create infinite loops!

Did you follow Raymond's links?

http://blogs.msdn.com/ts/archive/2006/11/16/why-does-my-shared-clipboard-not-work-part-1.aspx

"The real issue is why the clipboard has open/close semantics in the first place. Surely it only needs get/set semantics?"

This is to allow multiple representations (formats) of the same data and yet ensure atomicity of clipboard operations. Unfortunately, there're race conditions.

To make it really work(TM), opening the clipboard while it's already open by another application, should block the calling thread (like a mutex).

That's what I would've said before reading this thread... But now that I'm aware of this issue, I fear that, the "I cannot copy" bug would be mutated in a "Any application becomes totally unresponsive when I copy".

Eventually it could be possible to provide get/set semantics with a function taking an array of structures. Each structure would contain the required info for one format. I don't see any major issue to this approach except that we don't get a time machine.

En pleine rédaction passionné et passionnante, j'ai du subir un bug mais vraiment pénible &gt;&gt;&gt;