http://bugs.winehq.org/show_bug.cgi?id=60379 Bug ID: 60379 Summary: FileStream(handle, isAsync=true) on a FILE_FLAG_OVERLAPPED handle throws IOException "Win32 IO returned 997" Product: Framework Mono Version: main Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mono Assignee: wine-bugs@list.winehq.org Reporter: wwiinehq@eismann.cc CC: madewokherd@gmail.com Target Milestone: --- Distribution: --- Created attachment 82168 --> http://bugs.winehq.org/attachment.cgi?id=82168 Code to reproduce with the USB hardware it occurred with and code to reproduce with a simple pipe. **Component:** Wine Mono (System.IO.FileStream) **Versions:** wine-devel 11.18 (also seen with 11.17), wine-mono 11.3.0 and 10.4.1; the device-independent reproduction below also fails on wine 11.0 **Host:** Ubuntu 24.04 based, Linux 6.8, WineHQ packages, x86 (32-bit) .NET app in a 64-bit prefix ## Summary A .NET Framework application opens a USB HID device with `CreateFile(..., FILE_FLAG_OVERLAPPED)` and wraps the handle in `new FileStream(handle, FileAccess.ReadWrite, 4096, isAsync: true)`. It then calls `Write` followed by `BeginRead`/`EndRead` while a previous `BeginRead` is still pending (the device answers some requests only after a few hundred ms). On Windows this works. Under Wine Mono, `EndRead` throws System.IO.IOException: Win32 IO returned 997. 997 is `ERROR_IO_PENDING`. It looks as if the read is issued as a plain synchronous `ReadFile` (without an `OVERLAPPED` structure) on an overlapped handle, and Wine correctly reports "pending" when no data is available yet. Mono treats that as a failure. ## Reproduction (no hardware needed) `ReproPipe.cs` (about 70 lines, no third-party code) is attached. It replaces the HID device with a named pipe: a server thread in the same process reads each 65-byte request and answers after a delay (250 ms for the third request, 10 ms for the others). The client end is opened with `CreateFile`, optionally with `FILE_FLAG_OVERLAPPED`, and wrapped in `new FileStream(handle, FileAccess.ReadWrite, 4096, true)`. It then does what the application does: `Write`, `BeginRead` immediately, wait 80 ms, next packet. Every `EndRead` failure is printed. Build with the csc shipped in Wine Mono, as x86: wine 'C:\windows\Microsoft.NET\Framework\v4.0.30319\csc.exe' -platform:x86 -out:repro-pipe.exe ReproPipe.cs Run: wine repro-pipe.exe overlapped Mode: FILE_FLAG_OVERLAPPED EndRead: IOException: Win32 IO returned 997. Path: Z:\...\[Unknown] EndRead: IOException: Win32 IO returned 997. Path: Z:\...\[Unknown] OK: 2 Failed: 2 wine repro-pipe.exe plain Mode: without OVERLAPPED OK: 4 Failed: 0 Both results were the same in 4 of 4 runs. Because no HID device is involved, this rules out hid.dll and winebus as the cause. ## Effect on the real application (tempbase 2 by TempMate) The application swallows the exception, marks the device as closed and stops sending the remaining packets of its 31-packet connection sequence. Afterwards it permanently shows "Device disconnected". Patching the single `FILE_FLAG_OVERLAPPED` constant in the application to 0 makes all 31 packets go through, and the application then works. ## Reproduction with the original device `Repro.cs` is the same test against the real device and is attached as well. Build it the same way and run it with a TempMate USB logger (VID 04d8 / PID 0015) attached: wine repro.exe overlapped # throws IOException 997 (reproduced 2 of 2 runs) wine repro.exe plain # same code without FILE_FLAG_OVERLAPPED: no error The program sends four 64-byte output reports 80 ms apart, each followed by `BeginRead`, and reports every `EndRead` failure. The problem needs a read that is still pending when data has not arrived yet. A single `Write` + `BeginRead` + `EndRead` with a long pause in between did not fail in my tests. ## Expected `FileStream` with `isAsync=true` on an overlapped handle should complete pending reads asynchronously (as .NET Framework does) instead of surfacing `ERROR_IO_PENDING`. ## Notes - Both wine-mono 10.4.1 and 11.3.0 behave the same. - The kernel/hidraw and Wine's winebus layer are fine: the same device is read correctly with `cat /dev/hidraw*` and via Wine's hid.dll; HID reports arrive in the Wine debug log (`WINEDEBUG=+hid`). - The failure is not specific to HID: the named-pipe reproduction shows the same error on an ordinary overlapped pipe handle. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.