Never mind.   It's an astonishingly subtle bug in Vista involving the
OpenPrinter function.  For the next victim who encounters this bug, here's
how you fix it:

Vista apparently caches printer handles, and does a less than stellar job
of it.  The solution is the OpenPrinter2 function (new to Vista) and the
PRINTER_OPTION_NO_CACHE option (also new).  For example, this fixes the
problem:

      PRINTER_OPTIONSW  po;
      po.cbSize = sizeof(po);
      po.dwFlags = PRINTER_OPTION_NO_CACHE;
      OpenPrinter2(L"\\\\myServer\\,XvcPort myPort", &hServer, 0, &po);

Note that OpenPrinter2 is found only on Vista, so you'll have to
dynamically load it at runtime if you need to support XP, etc.

I presume what's happening is that on Vista, OpenPrinter is making the
mistake of thinking it can use a cached handle to the printer itself
instead of opening a new handle to the port monitor.  But the semantics of
including the "XvcPort" string in the call to OpenPrinter demands a call
to XvcOpenPort.  Vista is not doing that, which of course causes XcvData
to fail mysteriously.  That requirement is clearly spelled out in the
documentation, so this is definitely a bug.