2

我有一个多线程 Windows 程序，它通过“原始”Win API 调用执行串行端口异步 I/O。它在除 Windows 7/64 之外的任何 Windows 版本上都可以正常工作。

问题是程序可以很好地找到并设置 COM 端口，但它无法发送或接收任何数据。无论我在 Win XP 或 7 中编译二进制文件，我都无法在 Win 7/64 上发送/接收。兼容模式，以管理员身份运行等无济于事。

我设法将问题缩小到 FileIOCompletionRoutine 回调。每次调用时，dwErrorCode 始终为 0，dwNumberOfBytesTransfered 始终为 0。函数内部的 GetOverlappedResult() 始终返回 TRUE（一切正常）。似乎正确设置了 lp​​NumberOfBytesTransferred。但是 lpOverlapped 参数已损坏，它是一个指向垃圾值的垃圾指针。

我可以通过在调试器中检查正确的 OVERLAPPED 结构分配的地址或通过设置临时值来看到它已损坏。指向它的全局变量。

我的问题是：为什么会发生这种情况，为什么它只发生在 Windows 7/64 上？调用约定是否存在一些我不知道的问题？还是以某种方式对重叠结构进行了不同的处理？

在下面发布代码的相关部分：

class ThreadedComport : public Comport
{
  private:

    typedef struct
    {
      OVERLAPPED       overlapped;
      ThreadedComport* caller;                   /* add user data to struct */
    } OVERLAPPED_overlap;

    OVERLAPPED_overlap _send_overlapped;
    OVERLAPPED_overlap _rec_overlapped;

  ...

static void WINAPI  _send_callback     (DWORD dwErrorCode,
                                        DWORD dwNumberOfBytesTransfered,
                                        LPOVERLAPPED lpOverlapped);
static void WINAPI  _receive_callback  (DWORD dwErrorCode,
                                        DWORD dwNumberOfBytesTransfered,
                                        LPOVERLAPPED lpOverlapped);

  ...
};

打开/关闭在没有实现多线程和异步 I/O 的基类中完成：

void Comport::open (void)
{
  char          port[20];
  DCB           dcbCommPort;
  COMMTIMEOUTS  ctmo_new      = {0};

  if(_is_open)
  {
    close();
  }

  sprintf(port, "\\\\.\\COM%d", TEXT(_port_number));

  _hcom = CreateFile(port,
                     GENERIC_READ | GENERIC_WRITE,
                     0,
                     0,
                     OPEN_EXISTING,
                     0,
                     0);

  if(_hcom == INVALID_HANDLE_VALUE)
  {
   // error handling
  }

  GetCommTimeouts(_hcom, &_ctmo_old);
  ctmo_new.ReadTotalTimeoutConstant    = 10;
  ctmo_new.ReadTotalTimeoutMultiplier  = 0;
  ctmo_new.WriteTotalTimeoutMultiplier = 0;
  ctmo_new.WriteTotalTimeoutConstant   = 0;

  if(SetCommTimeouts(_hcom, &ctmo_new) == FALSE)
  {
    // error handling
  }

  dcbCommPort.DCBlength = sizeof(DCB);
  if(GetCommState(_hcom, &(DCB)dcbCommPort) == FALSE)
  {
    // error handling
  }

  // setup DCB, this seems to work fine

  dcbCommPort.DCBlength = sizeof(DCB);
  dcbCommPort.BaudRate = baudrate_int;

  if(_parity == PAR_NONE)
  {
    dcbCommPort.fParity = 0;                     /* disable parity */
  }
  else
  {
    dcbCommPort.fParity = 1;                     /* enable parity */
  }
  dcbCommPort.Parity  = (uint8)_parity;
  dcbCommPort.ByteSize = _databits;
  dcbCommPort.StopBits = _stopbits;

  SetCommState(_hcom, &(DCB)dcbCommPort);
}


void Comport::close (void)
{
  if(_hcom != NULL)
  {
    SetCommTimeouts(_hcom, &_ctmo_old);
    CloseHandle(_hcom);
    _hcom = NULL;
  }
  _is_open = false;
}

整个多线程和事件处理机制比较复杂，相关部分有：

发送

result = WriteFileEx (_hcom,              // handle to output file
                      (void*)_write_data, // pointer to input buffer
                      send_buf_size,      // number of bytes to write
                      (LPOVERLAPPED)&_send_overlapped, // pointer to async. i/o data
                      (LPOVERLAPPED_COMPLETION_ROUTINE )&_send_callback);

收到

  result = ReadFileEx (_hcom,                  // handle to output file
                       (void*)_read_data,      // pointer to input buffer
                       _MAX_MESSAGE_LENGTH,    // number of bytes to read
                       (OVERLAPPED*)&_rec_overlapped, // pointer to async. i/o data
                       (LPOVERLAPPED_COMPLETION_ROUTINE )&_receive_callback);

回调函数

void WINAPI ThreadedComport::_send_callback (DWORD dwErrorCode,
                                             DWORD dwNumberOfBytesTransfered,
                                             LPOVERLAPPED lpOverlapped)
{
  ThreadedComport* _this = ((OVERLAPPED_overlap*)lpOverlapped)->caller;

  if(dwErrorCode == 0)                           // no errors
  {
    if(dwNumberOfBytesTransfered > 0)
    {
      _this->_data_sent = dwNumberOfBytesTransfered;
    }
  }

  SetEvent(lpOverlapped->hEvent);
}


void WINAPI ThreadedComport::_receive_callback (DWORD dwErrorCode,
                                                DWORD dwNumberOfBytesTransfered,
                                                LPOVERLAPPED lpOverlapped)
{
  if(dwErrorCode == 0)                           // no errors
  {
    if(dwNumberOfBytesTransfered > 0)
    {
      ThreadedComport* _this = ((OVERLAPPED_overlap*)lpOverlapped)->caller;
      _this->_bytes_read = dwNumberOfBytesTransfered;
    }
  }

  SetEvent(lpOverlapped->hEvent);
}

编辑

更新：我花了大部分时间研究 OVERLAPPED 变量在执行回调之前超出范围的理论。我已经验证这永远不会发生，我什至尝试将 OVERLAPPED 结构声明为静态，同样的问题仍然存在。如果 OVERLAPPED 结构超出范围，我希望回调指向之前分配结构的内存位置，但它没有，它指向其他地方，在一个完全不熟悉的内存位置。为什么会这样，我不知道。

也许 Windows 7/64 制作了 OVERLAPPED 结构的内部硬拷贝？我可以看到这将如何导致这种行为，因为我依赖于在结构末尾潜入的附加参数（这对我来说似乎是一个 hack，但显然我从官方 MSDN 示例中得到了那个“hack”）。

我也尝试过更改调用约定，但这根本不起作用，如果我更改它，程序就会崩溃。（标准调用约定会导致它崩溃，无论标准是什么，cdecl？__fastcall 也会导致崩溃。）有效的调用约定是 __stdcall、WINAPI 和 CALLBACK。我认为这些都是 __stdcall 的相同名称，我在某处读到 Win 64 无论如何都会忽略该调用约定。

执行回调似乎是因为 Win 7/64 中的一些“虚假干扰”生成带有损坏或不相关参数的错误回调调用。

多线程竞争条件是另一种理论，但在我运行重现错误的场景中，只有一个线程，我可以确认调用 ReadFileEx 的线程与执行回调的线程相同。

4

1 回答 1

2

我发现了问题，结果很简单。

在 CreateFile() 中，我没有指定 FILE_FLAG_OVERLAPPED。由于未知的原因，这在 32 位 Windows 上是不必要的。但是，如果您在 64 位 Windows 上忘记了它，它显然仍会使用 FileIOCompletionRoutine 生成回调，但它们的参数已损坏。

I haven't found any documentation of this change of behavior anywhere; perhaps it was just an internal bug fix in Windows, since the older documentation also specifies that you must have FILE_FLAG_OVERLAPPED set.

As for my specific case, the bug appeared because I had a base class that assumed synchronous I/O, which has then been inherited by a class using asynchronous I/O.

于 2012-09-27T09:29:11.843 回答