[Bug 59672] New: winhttp: DOAXVV fails with error 9003 at title screen
http://bugs.winehq.org/show_bug.cgi?id=59672 Bug ID: 59672 Summary: winhttp: DOAXVV fails with error 9003 at title screen Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winhttp Assignee: wine-bugs@list.winehq.org Reporter: axis6404@proton.me Distribution: --- Description: Since the commit 355cdaf9c964078bea018e654d253d23536f2e51, DEAD OR ALIVE Xtreme Venus Vacation (DOAXVV) fails to proceed past the title screen with Error Code 9003. Environment: -OS: Debian 13 (trixie) -Desktop: KDE Plasma (X11) -Regression: Yes (identified by git bisect) Steps to reproduce: 1.Launch DOAXVV. 2.Wait for the title screen. 3."Error Code: 9003" appears and the game stops. Additional Info: The issue is resolved by reverting the aforementioned winhttp commit. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 axis6404@proton.me changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian Keywords| |regression Regression SHA1| |355cdaf9c964078bea018e654d2 | |53d23536f2e51 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #1 from Hans Leidekker <hans@meelstraat.net> --- Please attach a WINEDEBUG=+winhttp log. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #2 from axis6404@proton.me --- Sent the log via email. Please do not upload it here. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #3 from Hans Leidekker <hans@meelstraat.net> --- Created attachment 80778 --> http://bugs.winehq.org/attachment.cgi?id=80778 patch Can you try this patch? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #4 from axis6404@proton.me --- Created attachment 80779 --> http://bugs.winehq.org/attachment.cgi?id=80779 err2 screenshot I tested the patch. Unfortunately, the situation has worsened, and I am now getting a different error in the launcher. The launcher fails even before reaching the title screen. Error message: "Failed to connect to the server. Retry? *Please check your network environment. WebApiManager STATUS: 2 ERROR_NO: 200" -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #5 from Hans Leidekker <hans@meelstraat.net> --- (In reply to axis6404 from comment #4)
Created attachment 80779 [details] err2 screenshot
I tested the patch. Unfortunately, the situation has worsened, and I am now getting a different error in the launcher. The launcher fails even before reaching the title screen.
Error message: "Failed to connect to the server. Retry? *Please check your network environment. WebApiManager STATUS: 2 ERROR_NO: 200"
Can you send me another log with the patch applied? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #6 from axis6404@proton.me --- I sent the log on the 23rd—could you confirm if you received it? Also, I applied your patch to commit 355cdaf9 (where the issue started) rather than the latest master. Was that the correct approach for this log? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #7 from Hans Leidekker <hans@meelstraat.net> --- (In reply to axis6404 from comment #6)
I sent the log on the 23rd—could you confirm if you received it? Also, I applied your patch to commit 355cdaf9 (where the issue started) rather than the latest master. Was that the correct approach for this log?
Yes, I received it. It doesn't reveal what the issue might be unfortunately. I also wrote a test in an attempt to replicate the behavior but it passes with that patch. That commit is the last one in the winhttp module, so that's correct. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #8 from axis6404@proton.me --- The issue is 100% reproducible in DOAXVV. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #9 from Hans Leidekker <hans@meelstraat.net> --- (In reply to axis6404 from comment #8)
The issue is 100% reproducible in DOAXVV.
Yeah, I wish I could run it here. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #10 from axis6404@proton.me --- I noticed a recurring discrepancy in the logs, such as around line 1414 of doaxvv9003-20260418.txt. Both winhttp:read_data and the "dwStatusInformationLength" in WINHTTP_CALLBACK_STATUS_READ_COMPLETE(0x80000) are occasionally 8193, even though only 8192 bytes were reported as available. 06e8:trace:winhttp:WinHttpQueryDataAvailable ... ... 06e8:trace:winhttp:query_data_available 8192 bytes available ... 06e8:trace:winhttp:WinHttpReadData ..., ..., 8193 (sample code: https://learn.microsoft.com/windows/win32/api/winhttp/nf-winhttp-winhttpquer...), ... ... 06e8:trace:winhttp:read_data 8193 bytes read <--- here!!!!!!!!!!!! 06e8:trace:winhttp:send_callback ..., 0x80000, ..., 8193, ... <--- here!!!!!!!!!!!! I suspect 8192 is the correct value. Could you check if this 1-byte overflow is causing the issue? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #11 from Hans Leidekker <hans@meelstraat.net> --- (In reply to axis6404 from comment #10)
I noticed a recurring discrepancy in the logs, such as around line 1414 of doaxvv9003-20260418.txt.
Both winhttp:read_data and the "dwStatusInformationLength" in WINHTTP_CALLBACK_STATUS_READ_COMPLETE(0x80000) are occasionally 8193, even though only 8192 bytes were reported as available.
06e8:trace:winhttp:WinHttpQueryDataAvailable ... ... 06e8:trace:winhttp:query_data_available 8192 bytes available ... 06e8:trace:winhttp:WinHttpReadData ..., ..., 8193 (sample code: https://learn.microsoft.com/windows/win32/api/winhttp/nf-winhttp- winhttpquerydataavailable), ... ... 06e8:trace:winhttp:read_data 8193 bytes read <--- here!!!!!!!!!!!! 06e8:trace:winhttp:send_callback ..., 0x80000, ..., 8193, ... <--- here!!!!!!!!!!!!
I suspect 8192 is the correct value. Could you check if this 1-byte overflow is causing the issue?
I had checked that in a standalone test which showed that Windows behaves the same. Note that this app consistently asks to read the number of bytes available + 1. It gets that as long as there is more data to read. So only the last read call returns 1 byte less than asked for. The patch that caused this regression is a fix for a different regression. There the app checks the Content-Length header and expects to be able to read that many bytes; it divides that number by its buffer size and expects to need that many read calls to read all data. This broke when we only read up to the amount of data that was buffered. The loop I added restores the old behavior and reads as much data as possible in each read call. There's a difference between these apps: this one uses a chunked transfer and the other one (Warframe) uses a regular transfer. My tests also showed that Windows satisfies read calls up to the chunk size (so different from regular transfers) and that's what the patch attached here does. Unfortunately that doesn't fix this app so there must be more to it. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #12 from axis6404@proton.me --- I tested with your patch applied and added a data dump in read_data(dlls/winhttp/request.c). The response for the first POST (around line 1567 of doaxvv-20260423-5.txt) is corrupted. The first few hundred bytes of the JSON are missing, and while the end of the JSON is present, it is followed by garbage data. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #13 from axis6404@proton.me --- The data is retrieved through 2 or 3 separate WinHttpReadData calls. Without patch: {"key1":"Random key(base64)", "key2":"Random key2(base64)"} With patch: Random key?(base64)", "key2":"Random key2(base64)"}[garbage data(base64)] -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #14 from Hans Leidekker <hans@meelstraat.net> --- (In reply to axis6404 from comment #13)
The data is retrieved through 2 or 3 separate WinHttpReadData calls.
Without patch: {"key1":"Random key(base64)", "key2":"Random key2(base64)"} With patch: Random key?(base64)", "key2":"Random key2(base64)"}[garbage data(base64)]
Thanks, that was helpful. It means that the patch I attached is incomplete because the first chunk may already have been buffered after reading the response headers. The fix is to return early if there's data in the buffer. I'll attach an improved patch. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 Hans Leidekker <hans@meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #80778|0 |1 is obsolete| | --- Comment #15 from Hans Leidekker <hans@meelstraat.net> --- Created attachment 80854 --> http://bugs.winehq.org/attachment.cgi?id=80854 patch -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #16 from axis6404@proton.me --- Thank you so much for your help! I tested DOAXVV for 30 minutes with the patch and it worked perfectly without any issues. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 Hans Leidekker <hans@meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |fd4f05012d0f8e9ada07e57bf12 | |78bd879096a1f Status|UNCONFIRMED |RESOLVED --- Comment #17 from Hans Leidekker <hans@meelstraat.net> --- Fixed with fd4f05012d0f8e9ada07e57bf1278bd879096a1f. Thanks for your help. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59672 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #18 from Alexandre Julliard <julliard@winehq.org> --- Closing bugs fixed in 11.9. -- 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.
participants (1)
-
WineHQ Bugzilla