+1  A: 

I've never looked into this, but it's easy enough to guess:

  1. The clipboard is a shared resource
  2. Only one app (per desktop) can "own" the clipboard at any given point in time
  3. Your app owns it (after calling OpenClipboard())
  4. VS wants it (probably because, among other things, it's an editor)
  5. While your app is stopped at a breakpoint, no amount of waiting will ever find the clipboard not owned by your app.
  6. Hilarity ensues!
Shog9
>> VS wants it ...editor) <<In this case I am definitely not doing any copy/paste while I try to single-step. At a guess, the single-step-operations might be executed from the wrong thread-context somehow.
pngaz
VS might need to poll the clipboard in order to update the Paste toolbar button (and the Edit / Paste menu item) in real-time.
Roger Lipscombe
@Roger: that sounds like a very likely possibility. The cost of combining an editor and a debugger...
Shog9
+1  A: 

Don't waste time suspecting it's a .NET thing. At times, the relation between Visual Studio.NET and the .NET runtime is like ActiveX and ActiveDirectory - it tells you which marketeer was involved, Visual Studio.NET in fact has a number of debuggers. Native, script, or managed - only the latter is really .NET-related. You will be using the Native debugger.

If you want to investigate, I suggest hooking OpenClipboard using Microsoft Detours, then running your app in the debugger. You'd be able to see who is competing for the clipboard.

MSalters
I have edited the problem-description to include the phrase "after getting a successful return-code from OpenClipboard()". Like the cited Google-query-articles point out, the clipboard being successfully opened-for-read on the thread, that's what points the finger at the stepping mechanism.
pngaz