[Bug 30849] New: Diablo 3 Game Disconnect: ERROR 316704 "YOU HAVE BEEN REMOVED FROM THE GAME"
http://bugs.winehq.org/show_bug.cgi?id=30849
Bug #: 30849 Summary: Diablo 3 Game Disconnect: ERROR 316704 "YOU HAVE BEEN REMOVED FROM THE GAME" Product: Wine Version: 1.5.5 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: billbroach@gmail.com Classification: Unclassified
As of Jun 04, 2012 Diablo 3 will disconnect after about 5+ mins with error: "You have been removed from the game" after which you will not be able to create a game nor exit cleanly.
Error: "YOU HAVE BEEN REMOVED FROM THE GAME" ERROR 316704
Suspected change has occurred with the game in which wine does now not support properly.
other symptoms: * /who in chat will instantly lock and crash wine. * friends show as "offline" when they are really online. * friends will not be able to join your game with timing out or crashing your client. * high ping 300+ms
Several confirmation of the above symptoms can be seen here:
http://us.battle.net/d3/en/forum/topic/5271607015?page=1
it seems to be affecting several wine versions and several distributions.
http://bugs.winehq.org/show_bug.cgi?id=30849
Michael DeVore medv4380@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |medv4380@yahoo.com
--- Comment #1 from Michael DeVore medv4380@yahoo.com 2012-06-05 14:59:12 CDT --- I've had the same symptoms. Just prior to being dropped the game speed will drop to around 14fps for about 30 seconds then the game will drop.
http://bugs.winehq.org/show_bug.cgi?id=30849
dralan@dralan.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dralan@dralan.org
--- Comment #2 from dralan@dralan.org 2012-06-05 15:00:17 CDT --- I am also having the exact same problem. It seems to disconnect me in under 5 minutes every time. I was not having any issues until June 4, did not make any changes to my system or network, and now I cannot stay connected for more than 5 minutes. When this error happens, I cannot close the game or log out. The only way to get out is to kill the PID of the client.
http://bugs.winehq.org/show_bug.cgi?id=30849
klemensbaum@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |klemensbaum@gmail.com
--- Comment #3 from klemensbaum@gmail.com 2012-06-05 15:08:46 CDT --- Confirming this issue.
http://bugs.winehq.org/show_bug.cgi?id=30849
voltara@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |voltara@gmail.com
--- Comment #4 from voltara@gmail.com 2012-06-05 15:13:07 CDT --- Based on examining a tcpdump of the battle.net connections:
Diablo3 opens a connection when you log in. I'll call this the "account" connection. When the "account" connection is idle, the server sends keepalive messages every 20 seconds, and the client responds immediately to each keepalive.
Upon joining a game, Diablo3 opens a second connection. I'll call this the "game" connection, where the game-related communication happens. The "account" connection is kept open as well. Immediately upon joining the game, Diablo3 (under wine) stops responding to the server's keepalive packets. Leaving the game does not remedy this.
After 150 seconds of failing to respond to the keepalive, the server closes the "account" connection, and also closes the "game" connection (if one exists.) If in a game, the message is "You have been removed from the game." If not in a game, no message is displayed.
After its "account" connection is closed, the Diablo3 game client becomes unresponsive to commands. Attempting to exit the game hangs it. If I was to make a guess, I think it's trying to send a "log out" message over the (already closed) "account" connection, and hanging while waiting for a response.
http://bugs.winehq.org/show_bug.cgi?id=30849
Floppie floppie@quadra-tec.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |floppie@quadra-tec.net
--- Comment #5 from Floppie floppie@quadra-tec.net 2012-06-05 15:17:41 CDT --- Confirming the issue and adding more information...
This seems to only occur on American servers. There are 0 reports of this happening on European servers; indeed, people who are experiencing the issue are switching to European servers in order to be able to play.
The /who issue is unrelated. Blizzard has it listed as a known current issue.
http://bugs.winehq.org/show_bug.cgi?id=30849
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal
--- Comment #6 from Rosanne DiMesio dimesio@earthlink.net 2012-06-05 16:21:14 CDT --- Not critical. http://bugs.winehq.org/page.cgi?id=fields.html#importance
http://bugs.winehq.org/show_bug.cgi?id=30849
willismonroe@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |willismonroe@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #7 from Austin English austinenglish@gmail.com 2012-06-05 17:49:29 CDT --- Terminal output?
http://bugs.winehq.org/show_bug.cgi?id=30849
Hizeh johnkov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johnkov@gmail.com
--- Comment #8 from Hizeh johnkov@gmail.com 2012-06-05 18:40:43 CDT --- Also confirming this issue. Started around June 4th
http://bugs.winehq.org/show_bug.cgi?id=30849
James Eder jimportal@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jimportal@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30849
kabish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kabish@gmail.com
--- Comment #9 from kabish@gmail.com 2012-06-05 19:40:31 CDT --- Confirmed...
Started June 4th I'm guessing sometime after 2pm PST.
http://bugs.winehq.org/show_bug.cgi?id=30849
Todd Mokros tmokros@tmokros.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tmokros@tmokros.net
http://bugs.winehq.org/show_bug.cgi?id=30849
Jack Waterworth jwaterworth@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jwaterworth@gmail.com
--- Comment #10 from Jack Waterworth jwaterworth@gmail.com 2012-06-05 20:12:00 CDT --- another me too post. everything loads up fine, I resume game, and after a period of time. BAM removed from the game. nothing seems to work afterwards and exiting the game causes the client to become unresponsive. got the game installed and running yesterday evening, so it has never worked in the past for me.
Fedora 17 wine-1.5.3-1.fc17.x86_64
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #11 from Murph MattFinn@gmail.com 2012-06-05 20:48:17 CDT --- Created attachment 40402 --> http://bugs.winehq.org/attachment.cgi?id=40402 Output from game open to "Removed from game".
Here's the console output from me starting the game until I got "removed from game".
I stripped out 3,000 copies of "fixme:d3d:resource_check_usage Unhandled usage flags 0x8." for convenience. This is wine 1.5.5 with the AcceptEx patches on a gentoo 64 bit system with a nvidia graphics card. Like many other commenters, it was working fine until this started occuring (> 150 hours gametime).
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #12 from Ryan ryans.email@gmail.com 2012-06-05 20:57:28 CDT --- Created attachment 40403 --> http://bugs.winehq.org/attachment.cgi?id=40403 "tcpdump -l" dump of eventual failure
"tcpdump -l > dat2" while launching 'Diablo III.exe', logging in, and eventual boot from game.
The game started slowing down in the seconds before 'Tue Jun 5 15:16:57 CDT 2012 ' as I marked it.
The "you have been removed from the game" happened pretty much exactly at 15:19:04.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #13 from Jack Waterworth jwaterworth@gmail.com 2012-06-05 21:00:59 CDT --- I'm trying to confirm i'm hitting the same issue by looking at a tcpdump, but I don't seem to see the 20 second keep alive packet that is being sent at all. Perhaps I am following the wrong stream.
In my output, I see a ping every ~10 seconds, followed by a couple of extra packets at the end followed by a FIN issued from the bnet server. or perhaps i'm reading the output wrong all together.
in any case, each time i log into the game, i last around 180 seconds before i'm removed.
http://bugs.winehq.org/show_bug.cgi?id=30849
G P gpcabe@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gpcabe@gmail.com
--- Comment #14 from G P gpcabe@gmail.com 2012-06-05 21:06:58 CDT --- I wonder if it has anything to do with
err:secur32:SECUR32_initSchannelSP TLS library not found, SSL connections will fail
where they are using ssl to connect back for warden purposes. Not sure though. I am not really very familiar with wine code base.
Someone mentioned something about Warden possibly being the cause of the problem in a thread on battle.net forums.
http://bugs.winehq.org/show_bug.cgi?id=30849
wine@emerkle.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@emerkle.net
--- Comment #15 from wine@emerkle.net 2012-06-05 21:31:11 CDT --- Another confirmation of the issue. Running Arch Linux, 64-bit. Wine 1.5.5 (no custom patches). Game has worked fine until June 4, 2012.
http://bugs.winehq.org/show_bug.cgi?id=30849
Dennis Straffin dbstraffin@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dbstraffin@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30849
Bob Igo bob@igo.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob@igo.name
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #16 from Bob Igo bob@igo.name 2012-06-05 22:11:36 CDT --- I have experienced that the game plays normally until lag/framerate issues occur. After that point, chat messages cease to work (definitely outgoing, possibly incoming), and the aforementioned error message is inevitable, as is the buggy post-error behavior of the game client. I can also confirm that it started happening June 4th.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #17 from voltara@gmail.com 2012-06-05 22:18:41 CDT --- Created attachment 40404 --> http://bugs.winehq.org/attachment.cgi?id=40404 Graph of wineserver and Diablo III cpu usage over time
I was able to reproduce the issue without even entering a game. All I did was start up Diablo III and log into battle.net, and waited until the server disconnected me.
Here's an annotated excerpt of the battle.net connection. Time is measured from the first SYN sent by the client. I omitted the login handshake chatter for clarity (the chatter around 7.5 seconds into the stream.) I also omitted acknowledgement packets.
At 64 seconds into the stream, the server sends a packet which has the following effects: a) "wineserver.exe" and "Diablo III.exe" collectively max out CPU usage (according to strace, wineserver is in an endless loop, repeatedly making the same sequence of system calls.) b) The game client does NOT send a response.
Annotated packet capture (tshark):
# t=24: server packet + client response 195 24.060708 12.130.244.193 -> 192.168.1.121 TCP 1119 > 37620 [PSH, ACK] Seq=12608 Ack=5525 Win=26944 Len=186 197 24.065767 192.168.1.121 -> 12.130.244.193 TCP 37620 > 1119 [PSH, ACK] Seq=5525 Ack=12794 Win=58400 Len=218
# t=44: server packet + client response 200 44.183155 12.130.244.193 -> 192.168.1.121 TCP 1119 > 37620 [PSH, ACK] Seq=12794 Ack=5743 Win=28628 Len=186 201 44.188558 192.168.1.121 -> 12.130.244.193 TCP 37620 > 1119 [PSH, ACK] Seq=5743 Ack=12980 Win=61320 Len=266
# t=64: server packet + NO RESPONSE 203 64.309408 12.130.244.193 -> 192.168.1.121 TCP 1119 > 37620 [PSH, ACK] Seq=12980 Ack=6009 Win=30312 Len=186
# t=164: server packet + NO RESPONSE 205 164.301667 12.130.244.193 -> 192.168.1.121 TCP 1119 > 37620 [PSH, ACK] Seq=13166 Ack=6009 Win=30312 Len=74
# t=194: disconnect 207 194.320058 12.130.244.193 -> 192.168.1.121 TCP 1119 > 37620 [FIN, ACK] Seq=13240 Ack=6009 Win=30312 Len=0 208 194.320251 192.168.1.121 -> 12.130.244.193 TCP 37620 > 1119 [FIN, ACK] Seq=6009 Ack=13241 Win=62780 Len=0
What wineserver is doing repeatedly (strace):
17551 1338948483.817603 epoll_wait(10, {{EPOLLIN, {u32=250, u64=250}}}, 128, 2) = 1 <0.000004> 17551 1338948483.817621 gettimeofday({1338948483, 817625}, NULL) = 0 <0.000005> 17551 1338948483.817638 read(22, "X\0\0\0\0\0\0\0\10\0\0\0\377\377\377\377\266\354\261\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 <0.000005> 17551 1338948483.817660 ptrace(PTRACE_ATTACH, 17948, 0, 0) = 0 <0.000006> 17551 1338948483.817679 --- SIGCHLD (Child exited) @ 0 (0) --- 17551 1338948483.817687 write(16, "\0", 1) = 1 <0.000005> 17551 1338948483.817704 sigreturn() = 0 <0.000005> 17551 1338948483.817720 alarm(3) = 0 <0.000005> 17551 1338948483.817736 wait4(17948, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSTOP}], WSTOPPED|__WALL, NULL) = 17948 <0.000005> 17551 1338948483.817753 alarm(0) = 3 <0.000004> 17551 1338948483.817770 ptrace(PTRACE_PEEKDATA, 17948, 0xb1ecb4, [0x8bf377055e8ce8b]) = 0 <0.000005> 17551 1338948483.817788 ptrace(PTRACE_PEEKDATA, 17948, 0xb1ecb8, [0x8bf377039ffffe2]) = 0 <0.000005> 17551 1338948483.817806 ptrace(PTRACE_PEEKDATA, 17948, 0xb1ecbc, [0x8bf3770840fb05d]) = 0 <0.000005> 17551 1338948483.817824 ptrace(PTRACE_DETACH, 17948, 0x1, SIG_0) = 0 <0.000006> 17551 1338948483.817843 writev(27, [{"\0\0\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64}, {"\350U\342\377\3779]\260", 8}], 2) = 72 <0.000006>
# Next iteration, just like the previous one: 17551 1338948483.817872 epoll_wait(10, {{EPOLLIN, {u32=250, u64=250}}, {EPOLLIN, {u32=4, u64=4}}}, 128, 1) = 2 <0.000005> 17551 1338948483.817893 gettimeofday({1338948483, 817897}, NULL) = 0 <0.000004> 17551 1338948483.817909 read(22, "X\0\0\0\0\0\0\0\10\0\0\0\377\377\377\377\266\354\261\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 <0.000005> ... # etc
http://bugs.winehq.org/show_bug.cgi?id=30849
Daniel Lynn daniel.eric.lynn@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.eric.lynn@gmail.com
--- Comment #18 from Daniel Lynn daniel.eric.lynn@gmail.com 2012-06-05 22:40:08 CDT --- It should be noted about the original post describing the bug: the crash resulting from typing /who may not be related. It is a known bug:
"Typing /who in General Chat and pressing Enter can crash the client if General Chat is above 50 players."
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #19 from DancingBear billbroach@gmail.com 2012-06-05 22:45:15 CDT --- (In reply to comment #0)
As of Jun 04, 2012 Diablo 3 will disconnect after about 5+ mins with error: "You have been removed from the game" after which you will not be able to create a game nor exit cleanly.
Error: "YOU HAVE BEEN REMOVED FROM THE GAME" ERROR 316704
Suspected change has occurred with the game in which wine does now not support properly.
other symptoms:
- /who in chat will instantly lock and crash wine.
- friends show as "offline" when they are really online.
- friends will not be able to join your game with timing out or crashing your
client.
- high ping 300+ms
Several confirmation of the above symptoms can be seen here:
http://us.battle.net/d3/en/forum/topic/5271607015?page=1
it seems to be affecting several wine versions and several distributions.
/who is unrelated to this bug.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #20 from Michael DeVore medv4380@yahoo.com 2012-06-05 23:03:31 CDT --- I can replicate the issue without fully logging in.
I launched Diablo as I normally do put in user/pass then I went to the next room to grab my phone to get an authiticator code. Locks up at retrieving characters and 100% cpu usage.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #21 from Paul brenix@gmail.com 2012-06-06 00:26:19 CDT --- Created attachment 40406 --> http://bugs.winehq.org/attachment.cgi?id=40406 Running winedbg on Diablo3
http://bugs.winehq.org/show_bug.cgi?id=30849
Paul brenix@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brenix@gmail.com
--- Comment #22 from Paul brenix@gmail.com 2012-06-06 00:26:26 CDT --- When I play, everything appears to work (login, AH, etc). After about 5 mins of being in the game, the graphics become laggy and then I receive the "You have been removed....." error. The AH becomes greyed out.
I ran Diablo 3 using winedbg and as soon as 5 minutes or so hit, I noticed the console/term output started spitting out these errors..
err:ole:CoGetClassObject class {bcde0395-e52f-467c-8e3d-c4579291692e} not registered err:ole:CoGetClassObject no class object {bcde0395-e52f-467c-8e3d-c4579291692e} could be created for context 0x1
Please see attached @ line 82 is right when it hit...
I'm not sure if this will help but maybe some one can decipher this?
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #23 from G P gpcabe@gmail.com 2012-06-06 02:09:28 CDT --- Created attachment 40408 --> http://bugs.winehq.org/attachment.cgi?id=40408 Trace of ntdll
This is the log of the last minute or so before the removal upto afterwards when I kill the process with a kill -9 with tracing of only ntdll here. I will also add a file called D3Debug.txt output by the game to reference timeframe. 0 time in this file = 6/5/2012 23:55:37 in local time with reference to the other file
WINEDEBUG=trace+ntdll,+rundll,+timestamp WINEPREFIX=~/.wine-diablo strace wine /home/gagpcool/.wine-diablo/drive_c/Program\ Files/Diablo\ III/Diablo\ III.exe &> out
--- Comment #24 from G P gpcabe@gmail.com 2012-06-06 02:14:47 CDT --- Created attachment 40409 --> http://bugs.winehq.org/attachment.cgi?id=40409 Output by the game noting the disconnect in it
Timestamp to match against the previous wine log is around 298 or so which is absolute time in this file of about 6/6/2012 00:00:34 or so
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #25 from G P gpcabe@gmail.com 2012-06-06 02:20:32 CDT --- I can try more tracing on but all clearly kills the whole thing so need some subset. And since there isn't a real failure of one of the wine calls warn and such may not be useful, probably need trace. So need to figure out what is best to trace.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #26 from kabish@gmail.com 2012-06-06 03:02:35 CDT --- Dual booted Mint 32bit along side my 64bit.
Booted up into the 32bit version and used the same install of Diablo as my 64bit version of Mint. I have been in game for over an hour without any disconnects. I am having a little performance issue, but I can deal with that if it means I don't get disconnected every 5 minutes.
Up until I switched to the 32bit OS I was getting disconnected time after time after time. So far I've been connected solid with the general chat spamming me all along.
http://bugs.winehq.org/show_bug.cgi?id=30849
Quentin Pâris qparis@playonlinux.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |qparis@playonlinux.com
http://bugs.winehq.org/show_bug.cgi?id=30849
Rick Chen stuffcorpse@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stuffcorpse@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30849
Leif leif.walsh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leif.walsh@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #27 from Bob Igo bob@igo.name 2012-06-06 08:43:00 CDT --- I'm seeing this bug in 64-bit Ubuntu as well. Is anyone seeing it happen in 32-bit Linux?
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #28 from Erich Hoover ehoover@mines.edu 2012-06-06 11:45:09 CDT --- (In reply to comment #27)
I'm seeing this bug in 64-bit Ubuntu as well. Is anyone seeing it happen in 32-bit Linux?
According to several of the forum posts they are able to successfully play on 32-bit Linux. I'd be interested to see if compiling Wine on a 32-bit system and then running it on a 64-bit system makes any difference.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #29 from Quentin Pâris qparis@playonlinux.com 2012-06-06 11:46:29 CDT --- According to PlayOnLinux users, errors exist.
We only support 32bits version of patched Diablo's wine, so the bug might exist on 64bits machine with 32bits builds
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #30 from Erich Hoover ehoover@mines.edu 2012-06-06 11:56:26 CDT --- (In reply to comment #29)
According to PlayOnLinux users, errors exist.
We only support 32bits version of patched Diablo's wine, so the bug might exist on 64bits machine with 32bits builds
Are the builds performed on a 32-bit machine or are they made in 32-bit compatibility mode on a 64-bit machine? I'm thinking it might be a compiler problem (we've run into a few of those recently).
http://bugs.winehq.org/show_bug.cgi?id=30849
ritual@vsritual.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ritual@vsritual.com
--- Comment #31 from ritual@vsritual.com 2012-06-06 13:20:12 CDT ---
(In reply to comment #8)
Also confirming this issue. Started around June 4th
This issue has been happening to me since June 4th as well.
BackTrack 5 R2 (Ubuntu 11.04 on kernel 3.2.6-x86_64) NVIDIA GeForce 320M
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #32 from Quentin Pâris qparis@playonlinux.com 2012-06-06 13:38:02 CDT --- According to PlayOnLinux users, errors exist.
We only support 32bits version of patched Diablo's wine, so the bug might exist on 64bits machine with 32bits builds(In reply to comment #30)
(In reply to comment #29)
According to PlayOnLinux users, errors exist.
We only support 32bits version of patched Diablo's wine, so the bug might exist on 64bits machine with 32bits builds
Are the builds performed on a 32-bit machine or are they made in 32-bit compatibility mode on a 64-bit machine? I'm thinking it might be a compiler problem (we've run into a few of those recently).
You're right, there are built in a 64bits machine with -m32 option. But I'm not sure it has an impact
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #33 from voltara@gmail.com 2012-06-06 14:39:10 CDT --- The issue cleared up for me after this morning's maintenance. Tcpdump is telling me that Warden has been disabled for now (maybe the client patches incorporate permanent fixes, and Warden is more of a "quick fix" for blocking modified clients.)
When the battle.net connection is idle, I am getting keepalive packets at 120 second intervals. Based on that new knowledge:
- Warden scans (when Warden is enabled) are initiated at 20-second intervals - The server will send a keepalive packet after 120 seconds of inactivity from the client.
Thus in my original tcpdump, the packets at t=24, t=44, and t=64 were Warden scans, and the packet at t=164 was a keepalive. The server times out if the client doesn't respond to the keepalive with 30 seconds (120 + 30 = 150, which was my original observation.)
On repeated tests (before Warden was disabled), there were varying numbers of successful Warden scans before the failed one. There was probably a single signature in their list which was triggering our issue.
Troubleshooting will likely have to be put on hold until the issue recurs. In the meantime, I am building 1.5.5 on a 32-bit virtual machine, so that I have a build tree ready for deeper troubleshooting next time it happens.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #34 from ritual@vsritual.com 2012-06-06 18:20:43 CDT --- (In reply to comment #33)
The issue cleared up for me after this morning's maintenance. Tcpdump is telling me that Warden has been disabled for now (maybe the client patches incorporate permanent fixes, and Warden is more of a "quick fix" for blocking modified clients.)
When the battle.net connection is idle, I am getting keepalive packets at 120 second intervals. Based on that new knowledge:
- Warden scans (when Warden is enabled) are initiated at 20-second intervals
- The server will send a keepalive packet after 120 seconds of inactivity from
the client.
Thus in my original tcpdump, the packets at t=24, t=44, and t=64 were Warden scans, and the packet at t=164 was a keepalive. The server times out if the client doesn't respond to the keepalive with 30 seconds (120 + 30 = 150, which was my original observation.)
On repeated tests (before Warden was disabled), there were varying numbers of successful Warden scans before the failed one. There was probably a single signature in their list which was triggering our issue.
Troubleshooting will likely have to be put on hold until the issue recurs. In the meantime, I am building 1.5.5 on a 32-bit virtual machine, so that I have a build tree ready for deeper troubleshooting next time it happens.
I'm using POL on BackTrack 5R2 (Ubuntu 10.04 w/3.2.6-x86_64) on D3 1.0.2b. I cannot get past the retrieving hero list screen on the US Server. The CPU appears to spike to 100% when this happens.
The other realms don't appear to be patched yet so I'm unable to connect to those.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #35 from Paul brenix@gmail.com 2012-06-06 18:52:23 CDT --- Same thing here.. Stuck at retrieving hero list now.. Works fine through windows..
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #36 from Erich Hoover ehoover@mines.edu 2012-06-06 19:00:05 CDT --- (In reply to comment #35)
Same thing here.. Stuck at retrieving hero list now.. Works fine through windows..
I was able to play earlier today, but now I get stuck at either the authenticating credentials or the hero list. So, I assume this is probably a server load issue.
http://bugs.winehq.org/show_bug.cgi?id=30849
d460424@rtrtr.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |d460424@rtrtr.com
--- Comment #37 from d460424@rtrtr.com 2012-06-06 19:20:43 CDT --- Confirmed stuck at retrieving hero list (last step of login); windows 7 machine in the same location (on the same router) works as expected, so this is not a server load issue. The entire machine locks up and has to be hard rebooted!
Info: Ubuntu 12.04 64bit, using patched wine from git from approximately one month ago (32bit wine compiled in a 32bit Ubuntu virtual machine). No problems from launch until now running the game.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #38 from vsrz ritual@vsritual.com 2012-06-06 19:25:23 CDT --- (In reply to comment #36)
(In reply to comment #35)
Same thing here.. Stuck at retrieving hero list now.. Works fine through windows..
I was able to play earlier today, but now I get stuck at either the authenticating credentials or the hero list. So, I assume this is probably a server load issue.
Are you playing on a 32-bit kernel? I read above that the people with 32-bit kernels haven't had the issue. Or did I read that wrong?
Thanks Erich.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #39 from Erich Hoover ehoover@mines.edu 2012-06-06 19:26:33 CDT --- (In reply to comment #38)
(In reply to comment #36)
(In reply to comment #35)
Same thing here.. Stuck at retrieving hero list now.. Works fine through windows..
I was able to play earlier today, but now I get stuck at either the authenticating credentials or the hero list. So, I assume this is probably a server load issue.
Are you playing on a 32-bit kernel? I read above that the people with 32-bit kernels haven't had the issue. Or did I read that wrong?
Thanks Erich.
No, I'm using a 64-bit kernel. Right after the maintenance window ended I hopped on and I was able to play for an extended period of time, now I cannot sign on.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #40 from James Eder jimportal@gmail.com 2012-06-06 19:56:05 CDT --- (In reply to comment #39)
No, I'm using a 64-bit kernel. Right after the maintenance window ended I hopped on and I was able to play for an extended period of time, now I cannot sign on.
Same here, I was on for about an hour right after maintenance no problems. I left for a while to do some other stuff and came back to not being able to get past the "Retrieving Hero List" check mark.
I'm using 64-bit kernel (3.4.1) on ArchLinux with recent Wine git and your patches.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #41 from Jason Switzer jswitzer@gmail.com 2012-06-06 21:53:45 CDT --- Created attachment 40420 --> http://bugs.winehq.org/attachment.cgi?id=40420 winedebug output.
After the recent maintenance for patch 1.0.2b, I can confirm that the problem still seems to exist. After authenticating (password and mobile authenticator), it hangs while it retrieves hero list. I assume it has disconnected for the same reason (warden?). I am attaching a winedebug output (from PlayOnLinux). This is from a 64bit Gentoo kernel running 32bit wine.
http://bugs.winehq.org/show_bug.cgi?id=30849
DancingBear billbroach@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Diablo 3 Game Disconnect: |Diablo 3: Hangs on |ERROR 316704 "YOU HAVE BEEN |"Authenticating |REMOVED FROM THE GAME" |Credentials"
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #42 from Michael DeVore medv4380@yahoo.com 2012-06-07 00:11:23 CDT --- Works just find under 32 Bit LinuxMint 13 Does not work under 64 Bit LinuxMint 12
Maybe it has to do with the amount of reported RAM. If it's Warden related it has to loop though the memory addresses scanning active applications. If it does this incorrectly the 64 Bit memory values will crash it since they would be unreachable for 32 Bit.
http://bugs.winehq.org/show_bug.cgi?id=30849
Andrew Resch andrewresch@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrewresch@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #43 from Paul brenix@gmail.com 2012-06-07 01:18:56 CDT --- Try running the following to launch the game (assuming your in the Diablo 3 directory).. It works for getting past Retrieving hero list for me when launching it normally doesnt..This was taken from another user on the blizzard forums..
setarch i386 -3 -L -B -R wine Diablo\ III.exe -launch -locale enUS
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #44 from voltara@gmail.com 2012-06-07 01:40:33 CDT --- (In reply to comment #43)
Try running the following to launch the game (assuming your in the Diablo 3 directory).. It works for getting past Retrieving hero list for me when launching it normally doesnt..This was taken from another user on the blizzard forums..
setarch i386 -3 -L -B -R wine Diablo\ III.exe -launch -locale enUS
It also works if you reduce the setarch flags down to:
setarch i386 -3 wine ...
Running 32-bit wine on a 64-bit system lays the process out using the full 4GB of address space, which evidently Blizzard's "warden" anti-cheat software doesn't like.
Process map without setarch:
32727: C:/Program Files/Diablo III/Diablo III.exe -launch -uid diablo3_enus 0000000000010000 1024K rw--- [ anon ] 0000000000110000 1088K rwx-- [ anon ] 0000000000220000 8K rwx-- [ anon ] 0000000000222000 4K ----- [ anon ] ...etc... 00000000f740d000 80K rw--- /home/xxxxxxxx/.PlayOnLinux/wine/linux-x86/1.5.5-DiabloIII_v2/lib/wine/wldap32.dll.so ...etc... 00000000f777d000 4K r-x-- [ anon ] 00000000ff8f0000 4096K rwx-- [ anon ] 00000000ffcf8000 136K rw--- [ stack ] 00000000ffd20000 2880K ----- [ anon ] total 1997620K
Process map WITH "setarch -3":
31846: C:/Program Files/Diablo III/Diablo III.exe -launch -uid diablo3_enus 0000000000010000 1024K rw--- [ anon ] 0000000000110000 1088K rwx-- [ anon ] 0000000000220000 8K rwx-- [ anon ] 0000000000222000 4K ----- [ anon ] ...etc... 00000000b72bf000 80K rw--- /home/xxxxxxxx/.PlayOnLinux/wine/linux-x86/1.5.5-DiabloIII_v2/lib/wine/wldap32.dll.so ...etc... 00000000b7797000 4K r-x-- [ anon ] 00000000bfb60000 4096K rwx-- [ anon ] 00000000bff6f000 136K rw--- [ stack ] 00000000bffa0000 384K ----- [ anon ] total 1999512K
Somebody smarter than me will need to decide if this is something than can/should be fixed in wine.
http://bugs.winehq.org/show_bug.cgi?id=30849
Jason Switzer jswitzer@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jswitzer@gmail.com
--- Comment #45 from Jason Switzer jswitzer@gmail.com 2012-06-07 03:00:29 CDT --- (In reply to comment #43)
Try running the following to launch the game (assuming your in the Diablo 3 directory).. It works for getting past Retrieving hero list for me when launching it normally doesnt..This was taken from another user on the blizzard forums..
setarch i386 -3 -L -B -R wine Diablo\ III.exe -launch -locale enUS
I tested this and it appears to have fixed the problem. Since I'm using PlayOnLinux, I simply ran
setarch i386 -3 playonlinux
From there I launched wine/Diablo3 as normal and played for about an hour.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #46 from Alexandre Julliard julliard@winehq.org 2012-06-07 03:17:27 CDT --- Created attachment 40423 --> http://bugs.winehq.org/attachment.cgi?id=40423 Don't add to available address space
You can try this patch on 64-bit to confirm that it's an address space issue.
http://bugs.winehq.org/show_bug.cgi?id=30849
Xzarr xzarr@lavabit.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xzarr@lavabit.com
--- Comment #47 from Xzarr xzarr@lavabit.com 2012-06-07 05:58:31 CDT --- Can login just fine using that patch :)
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #48 from Quentin Pâris qparis@playonlinux.com 2012-06-07 07:02:32 CDT --- PlayOnLinux users: This patch has been added to the wine build called "1.5.5-DiabloIII_v3"
If you can try to confirm that the game runs with it
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #49 from Mike Cronce floppie@quadra-tec.net 2012-06-07 07:09:12 CDT --- Yep. Confirming that that workaround allows me to log in and play for 10 minutes or so (need to get ready for work, couldn't stay on for long)
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #50 from Alexandre Julliard julliard@winehq.org 2012-06-07 07:22:59 CDT --- Created attachment 40425 --> http://bugs.winehq.org/attachment.cgi?id=40425 Only limit builtin dlls
What if you try this one instead? Does it still work?
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #51 from Erich Hoover ehoover@mines.edu 2012-06-07 08:42:09 CDT --- (In reply to comment #50)
Created attachment 40425 [details] Only limit builtin dlls
What if you try this one instead? Does it still work?
It does not appear to for me, though attachment 40423 does (tried twice with each).
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #52 from Alexandre Julliard julliard@winehq.org 2012-06-07 09:13:32 CDT --- I'd expect it would also get 4Gb of address space on 64-bit Windows, so there must be something else going on here. Are you using a 32-bit or 64-bit wine prefix?
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #53 from James Eder jimportal@gmail.com 2012-06-07 09:19:28 CDT --- The first patch (attachment 40423) works for me, the second (attachment 40425) does not. I'm using a 64-bit prefix.
http://bugs.winehq.org/show_bug.cgi?id=30849
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch CC| |adys.wh@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #54 from Erich Hoover ehoover@mines.edu 2012-06-07 09:34:03 CDT --- (In reply to comment #52)
I'd expect it would also get 4Gb of address space on 64-bit Windows, so there must be something else going on here. Are you using a 32-bit or 64-bit wine prefix?
I'm using a 32-bit prefix on a 64-bit kernel.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #55 from Erich Hoover ehoover@mines.edu 2012-06-07 11:47:12 CDT --- Created attachment 40429 --> http://bugs.winehq.org/attachment.cgi?id=40429 address space limit tweak
(In reply to comment #52)
I'd expect it would also get 4Gb of address space on 64-bit Windows, so there must be something else going on here. Are you using a 32-bit or 64-bit wine prefix?
The attached is likely completely bogus, but it works and it might give you an idea about what's going on.
http://bugs.winehq.org/show_bug.cgi?id=30849
lyon@pvfree.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lyon@pvfree.net
--- Comment #56 from lyon@pvfree.net 2012-06-07 12:07:01 CDT --- Just for curiosity, was anyone hitting EFAULT with setarch -3?
execve("/usr/local/bin/wine", ["wine", "Diablo III.exe", "-launch", "--locale", "enGB"], [/* 36 vars */]) = -1 EFAULT (Bad address)
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #57 from Alexandre Julliard julliard@winehq.org 2012-06-07 12:14:05 CDT --- (In reply to comment #55)
Created attachment 40429 [details] address space limit tweak
(In reply to comment #52)
I'd expect it would also get 4Gb of address space on 64-bit Windows, so there must be something else going on here. Are you using a 32-bit or 64-bit wine prefix?
The attached is likely completely bogus, but it works and it might give you an idea about what's going on.
This would limit the address space even more than my first patch. The question is why does it require this, when the current behavior is AFAICT identical to that of 64-bit Windows.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #58 from Erich Hoover ehoover@mines.edu 2012-06-07 12:16:18 CDT --- (In reply to comment #57)
... This would limit the address space even more than my first patch. The question is why does it require this, when the current behavior is AFAICT identical to that of 64-bit Windows.
Oh! I think I might have figured it out, it's not actually the internal behavior - it's the reporting of the address space. In virtual_get_system_info it sets the HighestUserAddress to user_space_limit-1. My guess is that because we're reporting back an address over the 32-bit limit (in my case 0xffff0000) that Warden starts attempting to look in addresses that it doesn't have the ability to check. Using the following instead allows it to work: info->HighestUserAddress = (char*)min((char *)user_space_limit, 0xc0000000)-1;
(note: 0x7fff0000 also works, but I'm not sure which is more appropriate - this isn't really my area of expertise)
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #59 from Erich Hoover ehoover@mines.edu 2012-06-07 12:18:19 CDT --- (In reply to comment #58)
... info->HighestUserAddress = (char*)min((char *)user_space_limit, 0xc0000000)-1;
Bah, hasty typing: info->HighestUserAddress = (char*)min((int)user_space_limit, 0xc0000000)-1;
http://bugs.winehq.org/show_bug.cgi?id=30849
Jason Parker north@ntbox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |north@ntbox.com
--- Comment #60 from Jason Parker north@ntbox.com 2012-06-07 12:44:42 CDT --- You've got an off-by-*mumblemumble* on your 2GB example, Erich.
0x80000000 == 2GB (0x00000000 -> 0x7FFFFFFF) 0xC0000000 == 3GB (0x00000000 -> 0xBFFFFFFF)
3GB should be just fine - this is what setarch -3 is doing, which Windows (What versions? Does that matter?) supports.
Also it should be pointed out that 64-bit wine compiles needs to not have this limit.
http://bugs.winehq.org/show_bug.cgi?id=30849
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #40429|0 |1 is obsolete| |
--- Comment #61 from Erich Hoover ehoover@mines.edu 2012-06-07 12:53:17 CDT --- Created attachment 40433 --> http://bugs.winehq.org/attachment.cgi?id=40433 address space reporting tweak
(In reply to comment #60)
You've got an off-by-*mumblemumble* on your 2GB example, Erich. ...
I grabbed that from the i386 value for user_space_limit.
Also it should be pointed out that 64-bit wine compiles needs to not have this limit.
Yup, I've attached a patch that I believe should handle both cases.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #62 from Jason Parker north@ntbox.com 2012-06-07 12:57:55 CDT --- (In reply to comment #61)
I grabbed that from the i386 value for user_space_limit.
Strange. There may be some buffer that would need to be accounted for in the 3GB case then - that, or the existing value was just wrong.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #63 from Alexandre Julliard julliard@winehq.org 2012-06-07 13:06:50 CDT --- We already know that limiting to 3Gb works, but the interesting question is why, since Wow64 on Windows has a 4Gb address space.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #64 from Erich Hoover ehoover@mines.edu 2012-06-07 13:15:20 CDT --- (In reply to comment #63)
We already know that limiting to 3Gb works, but the interesting question is why, since Wow64 on Windows has a 4Gb address space.
Well, I think that it's relevant to know that it's the reporting of the address space that's killing things - not the actual internal use. Also, I thought there was a max 3 GB limit on user address space with 1 GB reserved for the system?
http://bugs.winehq.org/show_bug.cgi?id=30849
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #40433|0 |1 is obsolete| |
--- Comment #65 from Erich Hoover ehoover@mines.edu 2012-06-07 13:31:01 CDT --- Created attachment 40436 --> http://bugs.winehq.org/attachment.cgi?id=40436 address space reporting tweak [v2]
(In reply to comment #64)
... Well, I think that it's relevant to know that it's the reporting of the address space that's killing things - not the actual internal use. Also, I thought there was a max 3 GB limit on user address space with 1 GB reserved for the system?
Using the the "Memory Limits for Windows Releases" table from MSDN I've constructed a revised patch (attached). I think the problem might be a function of: "true" 32, WoW64, and IMAGE_FILE_LARGE_ADDRESS_AWARE.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #66 from Jason Parker north@ntbox.com 2012-06-07 13:39:52 CDT --- (In reply to comment #65)
Created attachment 40436 [details] address space reporting tweak [v2]
(In reply to comment #64)
... Well, I think that it's relevant to know that it's the reporting of the address space that's killing things - not the actual internal use. Also, I thought there was a max 3 GB limit on user address space with 1 GB reserved for the system?
Using the the "Memory Limits for Windows Releases" table from MSDN I've constructed a revised patch (attached). I think the problem might be a function of: "true" 32, WoW64, and IMAGE_FILE_LARGE_ADDRESS_AWARE.
That makes sense to me. Though I think your 0xb... should be 0x8...?
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #67 from Erich Hoover ehoover@mines.edu 2012-06-07 13:41:41 CDT --- (In reply to comment #66)
... That makes sense to me. Though I think your 0xb... should be 0x8...?
Yeah, it should - apparently I'm off my game today.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #68 from Józef Kucia joseph.kucia@gmail.com 2012-06-07 14:06:30 CDT --- Created attachment 40440 --> http://bugs.winehq.org/attachment.cgi?id=40440 Check lpMaximumApplicationAddress on Wow64
This test passes on the test bot.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #69 from Erich Hoover ehoover@mines.edu 2012-06-07 14:23:58 CDT --- (In reply to comment #68)
Created attachment 40440 [details] Check lpMaximumApplicationAddress on Wow64
This test passes on the test bot.
I don't believe that we enable the IMAGE_FILE_LARGE_ADDRESS_AWARE bit for crosstests.
http://bugs.winehq.org/show_bug.cgi?id=30849
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joseph.kucia@gmail.com
--- Comment #70 from Józef Kucia joseph.kucia@gmail.com 2012-06-07 14:40:10 CDT --- (In reply to comment #69)
(In reply to comment #68)
Created attachment 40440 [details] Check lpMaximumApplicationAddress on Wow64
This test passes on the test bot.
I don't believe that we enable the IMAGE_FILE_LARGE_ADDRESS_AWARE bit for crosstests.
Yes, it's 0xfffeffff for LARGE_ADDRESS_AWARE.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #71 from Jack Waterworth jwaterworth@gmail.com 2012-06-07 15:10:09 CDT --- might be a little late to the party but I can confirm on my machine that 'setarch i386 -3 wine' resolves the retrieving hero list issue.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #72 from Erich Hoover ehoover@mines.edu 2012-06-07 15:34:48 CDT --- (In reply to comment #70)
... Yes, it's 0xfffeffff for LARGE_ADDRESS_AWARE.
So (combined with some tests I've run), we have: true 32-bit w/o LF: 0x7ffeffff true 32-bit w/ LF: 0x7ffeffff WoW64 32-bit w/o LF: 0x7ffeffff WoW64 32-bit w/ LF: 0xfffeffff
Testing the game just on it's own I've found that it will work up to a value of 0xfff00000, 0xfff00001 and it'll stall.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #73 from d460424@rtrtr.com 2012-06-07 16:13:31 CDT --- The setarch workaround does fix the login issue, however, the game seems to freeze after about 30 minutes of play or so. I have observed this is different areas of the game (actually game play, just in menus or auction house, etc). I suspect this is related to the same issues with warden and the memory addresses... other users are reporting similar "random freezes" and crashes.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #74 from DancingBear billbroach@gmail.com 2012-06-07 16:15:10 CDT --- if thats the case please have them troubleshoot here in this thread: us.battle.net/d3/en/forum/topic/5592457019
Thanks
http://bugs.winehq.org/show_bug.cgi?id=30849
DancingBear billbroach@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://us.battle.net/d3/en/ | |forum/topic/5592457019
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #75 from d460424@rtrtr.com 2012-06-07 17:51:50 CDT --- (In reply to comment #74)
if thats the case please have them troubleshoot here in this thread: us.battle.net/d3/en/forum/topic/5592457019
Thanks
Why should users report it on the battle.net forums? This is clearly a wine issue as non-wine users are not reporting it. Yes there is a log-in fix now but there are still issues with patch 1.02b and wine. After 20-30 minutes the game freezes, and on my installation, it takes the whole system down with it.
Other users are reporting this on the main Diablo 3 page on winehq.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #76 from voltara@gmail.com 2012-06-07 18:36:58 CDT --- (In reply to comment #75)
(In reply to comment #74)
if thats the case please have them troubleshoot here in this thread: us.battle.net/d3/en/forum/topic/5592457019
Thanks
Why should users report it on the battle.net forums? This is clearly a wine issue as non-wine users are not reporting it. Yes there is a log-in fix now but there are still issues with patch 1.02b and wine. After 20-30 minutes the game freezes, and on my installation, it takes the whole system down with it.
Other users are reporting this on the main Diablo 3 page on winehq.
The new symptoms you're reporting sound nothing like what led us to creating this ticket (which has already been traced down to a specific cause, with specific workarounds.)
DancingBear is directing you to the battle.net forum, because the truth is we don't actually know for sure that what you're experiencing is a wine issue. It could any of a number of things -- video driver, hardware, cooling, kernel, network, etc.
http://bugs.winehq.org/show_bug.cgi?id=30849
Anton Romanov theli.ua@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |theli.ua@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30849
Chris_9 jukeller@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jukeller@gmx.de
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #77 from Erich Hoover ehoover@mines.edu 2012-06-08 16:45:55 CDT --- Maybe this is a silly suggestion, but is it possible that we should be subtracting the image base address from the address we're returning?
http://bugs.winehq.org/show_bug.cgi?id=30849
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #40436|0 |1 is obsolete| |
--- Comment #78 from Erich Hoover ehoover@mines.edu 2012-06-10 16:41:28 CDT --- Created attachment 40477 --> http://bugs.winehq.org/attachment.cgi?id=40477 address space reporting tweak [v3]
(In reply to comment #77)
Maybe this is a silly suggestion, but is it possible that we should be subtracting the image base address from the address we're returning?
I've attached an interesting tweak that causes D3 to work (raising LowestUserAddress).
http://bugs.winehq.org/show_bug.cgi?id=30849
Alexey Loukianov mooroon2@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mooroon2@mail.ru
http://bugs.winehq.org/show_bug.cgi?id=30849
Nye Liu nyet@nyet.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nyet@nyet.org
--- Comment #79 from Nye Liu nyet@nyet.org 2012-06-13 16:59:14 CDT --- (In reply to comment #56)
Just for curiosity, was anyone hitting EFAULT with setarch -3?
execve("/usr/local/bin/wine", ["wine", "Diablo III.exe", "-launch", "--locale", "enGB"], [/* 36 vars */]) = -1 EFAULT (Bad address)
personality(PER_LINUX32_3GB) is not supported under 32-bit user space
Unfortunately, that workaround is being posted everywhere as the canonical fix.
http://bugs.winehq.org/show_bug.cgi?id=30849
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Monoboy4ik@gmail.com
--- Comment #80 from Jerome Leclanche adys.wh@gmail.com 2012-06-19 11:14:12 CDT --- *** Bug 30894 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=30849
brasilramos@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brasilramos@gmail.com
--- Comment #81 from brasilramos@gmail.com 2012-06-20 08:42:27 CDT --- Hi, I'm using Ubuntu 12.04 64bits with POL and Wine 1.5.5 D3 V3 patch
I experienced the bug 30849
The following command was the only thing that worked for me:
echo 0|sudo tee /proc/sys/kernel/yama/ptrace_scope
I have to open a terminal and type it before starting the game. (I have no idea of what it does, but it works - I'm a Linux noob)
Now I can play for 10 mins or so, then the cursor disappears (I'm still able to click and move, but can't see the cursor)
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #82 from voltara@gmail.com 2012-06-20 09:27:15 CDT --- (In reply to comment #81)
Hi, I'm using Ubuntu 12.04 64bits with POL and Wine 1.5.5 D3 V3 patch
I experienced the bug 30849
The following command was the only thing that worked for me:
echo 0|sudo tee /proc/sys/kernel/yama/ptrace_scopeI have to open a terminal and type it before starting the game. (I have no idea of what it does, but it works - I'm a Linux noob)
Now I can play for 10 mins or so, then the cursor disappears (I'm still able to click and move, but can't see the cursor)
The ptrace_scope setting was merely a permissions problem on your machine (which you corrected), and is not related to the issue described in this ticket.
As for your mouse cursor problem, that's not something I have experienced, but a google search for the keywords 'diablo3 cursor disappears' returns many results, including reports from Windows and Mac users.
http://bugs.winehq.org/show_bug.cgi?id=30849
Nephyrin zey Nephyrin@nephyrin.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Nephyrin@nephyrin.net
http://bugs.winehq.org/show_bug.cgi?id=30849
sworddragon2@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sworddragon2@aol.com
--- Comment #83 from sworddragon2@aol.com 2012-07-05 20:11:52 CDT --- With Wine 1.5.8 ptrace is disable as I know and I can login without a problem (amd64). I don't even need to use "setarch i386 -3". I was over 1 hour on idling and the game hasn't disconnected me. After my ip address changed (24 hour disconnect) I could even quit Diablo after the error messages appeared without that the game is hanging.
Has somebody else still troubles with Wine 1.5.8?
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #84 from voltara@gmail.com 2012-07-07 13:51:05 CDT --- (In reply to comment #83)
With Wine 1.5.8 ptrace is disable as I know and I can login without a problem (amd64). I don't even need to use "setarch i386 -3". I was over 1 hour on idling and the game hasn't disconnected me. After my ip address changed (24 hour disconnect) I could even quit Diablo after the error messages appeared without that the game is hanging.
Has somebody else still troubles with Wine 1.5.8?
It's hard to say at the moment. From what I can tell, Warden is not currently active in the Americas region. The issue will not recur until they activate Warden again - which means we cannot verify until that happens.
http://bugs.winehq.org/show_bug.cgi?id=30849
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #85 from Jerome Leclanche adys.wh@gmail.com 2012-07-12 12:29:45 CDT --- (In reply to comment #84) Warden is active again in EU. Also, confirming.
http://bugs.winehq.org/show_bug.cgi?id=30849
Michael Cronenworth mike@cchtml.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mike@cchtml.com
--- Comment #86 from Michael Cronenworth mike@cchtml.com 2012-07-12 14:02:17 CDT --- Whatever the system is (Warden or not) it is active again on US servers this week. I was unable to login yesterday until I ran Diablo with "setarch -3" on my 64-bit system. Wine 1.5.8.
http://bugs.winehq.org/show_bug.cgi?id=30849
Sven sven.wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sven.wine@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30849
chemacg@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chemacg@gmail.com
--- Comment #87 from chemacg@gmail.com 2012-07-22 13:26:04 CDT --- (In reply to comment #78)
Created attachment 40477 [details] address space reporting tweak [v3]
(In reply to comment #77)
Maybe this is a silly suggestion, but is it possible that we should be subtracting the image base address from the address we're returning?
I've attached an interesting tweak that causes D3 to work (raising LowestUserAddress).
This patch works perfectly and i don't know how but it also solves a low FPS problem i've been suffering.
http://bugs.winehq.org/show_bug.cgi?id=30849
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu
http://bugs.winehq.org/show_bug.cgi?id=30849
Vexorian vexorian@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vexorian@gmail.com
--- Comment #88 from Vexorian vexorian@gmail.com 2012-10-21 10:17:06 CDT --- Hello. I have been having this issue randomly and also many other problems with "silent disconnects" after leaving the interface part of the game open for more than a few seconds. Eventually interface controls become unresponsive - you can click on them, but they do nothing. During game, I don't get achievement and auction house notifications. Then when I want to log out or exit the game, I get a very long wait time in a blank screen. I concluded that one sort of connection gets lost.
This week after patch 1.05 was released everything seemed fixed but then it came back around 24 hours later. After reading the comments in the bug report I think that maybe Warden was not enabled instantly after the patch was released but they enabled it back.
I tried the setarch i386 -3 workaround presented in this thread and suddenly all things are working the way they should.
I am worried that if it is really warden that was crashing, it would explain the diablo 3 bans on WINE users. Although I have been playing for 2 weeks so far without getting banned.
http://bugs.winehq.org/show_bug.cgi?id=30849
William Pettersson william.pettersson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |william.pettersson@gmail.co | |m
http://bugs.winehq.org/show_bug.cgi?id=30849
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |frederic.delanoy@gmail.com
--- Comment #89 from Frédéric Delanoy frederic.delanoy@gmail.com 2013-09-28 11:00:42 CDT --- Does it still happen with latest wine/diablo 3? Please retest.
FWIW "YOU HAVE BEEN REMOVED FROM THE GAME" ERROR 316704 is an error message generally appearing when d3 servers are overloaded, so not a wine issue.
You may suffer from bug 33413, in which case using "setarch i386 -3 wine diablo3.exe" to launch the game should help
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #90 from sworddragon2@aol.com 2013-09-28 15:51:21 CDT --- I have tested this now on my 64 bit system with Wine 1.7.2 without the "setarch i386 -3" workaround: Sometimes I'm able to successfully login but the most time the game will still hang at the login process.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #91 from voltara@gmail.com 2013-10-03 18:38:20 CDT --- Tested with 1.7.3, and the issue still exists. Unless I use the "setarch i386 -3" workaround, the Warden scan gets caught in an infinite loop.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #92 from Jerome Leclanche adys.wh@gmail.com --- Apparently this is no longer needed in Diablo 3 2.x.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #93 from sworddragon2@aol.com --- I could successfully login too after removing "setarch i386 -3".
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #94 from Michael DeVore medv4380@yahoo.com --- You may want to wait until confirming an all clear for the issue. Several times just after a patch it would work flawlessly only to come back after Blizzard enabled scan that is believed to cause the issue. It may just mean that the check that causes the issue isn't currently enabled.
http://bugs.winehq.org/show_bug.cgi?id=30849
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |ABANDONED
--- Comment #95 from Jerome Leclanche adys.wh@gmail.com --- Let's close it - it can be reopened if it happens again.
ABANDONED because the issue wasn't fixed in Wine.
http://bugs.winehq.org/show_bug.cgi?id=30849
Silviu C. silviucc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |silviucc@gmail.com
--- Comment #96 from Silviu C. silviucc@gmail.com --- Warden is active. You might want to test this again... I believe the bug was closed too hastily
http://bugs.winehq.org/show_bug.cgi?id=30849
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|ABANDONED |---
--- Comment #97 from Jerome Leclanche adys.wh@gmail.com --- Yes, it's been broken.. pinged bug 33413 and completely forgot about this.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #98 from Jerome Leclanche adys.wh@gmail.com --- *** Bug 33413 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=30849
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org Regression SHA1| |9181b7e8763e9070f6a1d636aeb | |882db829867d8
--- Comment #99 from Jerome Leclanche adys.wh@gmail.com --- Bug 33413 is a dupe of this one which is technically a regression. CC julliard.
http://bugs.winehq.org/show_bug.cgi?id=30849
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1|9181b7e8763e9070f6a1d636aeb | |882db829867d8 |
--- Comment #100 from Frédéric Delanoy frederic.delanoy@gmail.com --- (In reply to Jerome Leclanche from comment #99)
Bug 33413 is a dupe of this one which is technically a regression. CC julliard.
9181b7e8763e9070f6a1d636aeb882db829867d8 can't possibly cause this bug since it was committed long after this bug was filed...
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #101 from Erich Hoover erich.e.hoover@gmail.com --- Created attachment 47754 --> http://bugs.winehq.org/attachment.cgi?id=47754 Get lowest reserved address for virtual address space
I'm having some trouble getting my D3 up and running again (haven't used it in forever). But based on some poking around I think the problem might be that the user virtual memory is starting out at too high of an address. Could someone give the attached a try?
http://bugs.winehq.org/show_bug.cgi?id=30849
BigCajun wine@emerkle.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|wine@emerkle.net |
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #102 from Jerome Leclanche adys.wh@gmail.com --- (In reply to Erich Hoover from comment #101)
I have to double check I didn't mess something up, but I think your patch caused a crash.
Problem is, there seems to be a regression from the other day.. looking into it.
err:d3d:wined3d_debug_callback 0x17a100: "GL_INVALID_FRAMEBUFFER_OPERATION error generated. Operation is not valid because a bound framebuffer is not framebuffer complete.". err:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glDrawElementsBaseVertex @ ../../../wine-multimedia/dlls/wined3d/drawprim.c / 73 fixme:d3d:context_check_fbo_status FBO status GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8cd6) fixme:d3d:context_check_fbo_status Location WINED3D_LOCATION_TEXTURE_RGB (0x20). fixme:d3d:context_check_fbo_status Color attachment 0: (0x2611ff38) WINED3DFMT_B8G8R8A8_UNORM 1672x987 0 samples. fixme:d3d:context_check_fbo_status Depth attachment: (0x26121048) WINED3DFMT_INTZ 1672x987 0 samples.
http://bugs.winehq.org/show_bug.cgi?id=30849
Erich Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #47754|0 |1 is obsolete| |
--- Comment #103 from Erich Hoover erich.e.hoover@gmail.com --- Created attachment 47756 --> http://bugs.winehq.org/attachment.cgi?id=47756 Try to start the virtual address space at a lower address
(In reply to Jerome Leclanche from comment #102)
(In reply to Erich Hoover from comment #101)
I have to double check I didn't mess something up, but I think your patch caused a crash.
Problem is, there seems to be a regression from the other day.. looking into it. ...
It's probably the patch, it's a very dirty hack that tries to grab a smaller address for the virtual memory start address by using the smallest reserved memory address instead of the largest. Try this dirty hack instead, it should be more predictable ;)
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #104 from Jerome Leclanche adys.wh@gmail.com --- (In reply to Erich Hoover from comment #103) The patch works great.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #105 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to Jerome Leclanche from comment #104)
(In reply to Erich Hoover from comment #103) The patch works great.
In my limited testing it looks like things break down over 0xf0000000. I'll have to take a look into why (don't have time at the moment), but that could explain the issue.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #106 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to Erich Hoover from comment #105)
... In my limited testing it looks like things break down over 0xf0000000. I'll have to take a look into why (don't have time at the moment), but that could explain the issue.
Sorry, that should be _at_ 0xf0000000 (0xefffffff or less doesn't create "odd" behavior in a diagnostic I'm running).
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #107 from Jerome Leclanche adys.wh@gmail.com --- After further testing, Erich, your patch seems to affect Hearthstone. I'm able to log onto HS on vanilla Wine but not patched Wine.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #108 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to Jerome Leclanche from comment #107)
After further testing, Erich, your patch seems to affect Hearthstone. I'm able to log onto HS on vanilla Wine but not patched Wine.
Interesting, is this consistent or random? That patch uses a hard-coded location for the memory (which could not work, depending on the availability at that location). I think the problem has to do with a memory reservation by the preloader but I haven't had time to look into it, I'm preparing for a trip for work and probably won't be able to look at it for a couple weeks.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #109 from Jerome Leclanche adys.wh@gmail.com --- It was constant yesterday (It would crash to the hearthstone "Oops!" screen), but Im not longer able to reproduce it now. Maybe it's warden related again, or maybe it's something different.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #110 from Silviu C. silviucc@gmail.com --- Did your Hearthstone game actually crash or just display an error message like this one:
http://i648.photobucket.com/albums/uu201/ArbiterX/HearthstoneError_zpsc99d86...
It was under maintenance yesterday and the day before, depending on your region.
You mentioned an "oops" screen, so that is why I'm asking.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #111 from Jerome Leclanche adys.wh@gmail.com --- That's the screen. Yes, it's sometimes a maintenance screen, but in this particular case it was not.
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #112 from Silviu C. silviucc@gmail.com --- So with a wine build without the patch, the game would run fine but it would show that screen when running with the patched build of wine?
Do I understand this correctly?
http://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #113 from Jerome Leclanche adys.wh@gmail.com --- Yes, correct. I am not getting the issue now though.
Let's stay on topic.
http://bugs.winehq.org/show_bug.cgi?id=30849
Jase Whipp jason.whipp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jason.whipp@gmail.com
--- Comment #114 from Jase Whipp jason.whipp@gmail.com --- (In reply to Jerome Leclanche from comment #113)
Yes, correct. I am not getting the issue now though.
Let's stay on topic.
I am still seeing this issue, setarch i386 is still required with the latest wine, Diablo 3 and Battle.net on a 64 bit system/OS.
With out setarch, I'll see general hanging, stuck at authenticating credentials or stuck at retrieving hero list.
http://bugs.winehq.org/show_bug.cgi?id=30849
felix moreno info@justdust.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |info@justdust.es
--- Comment #115 from felix moreno info@justdust.es --- Like other said if you setarch i386 and opengl 100% of tries the game runs good, if not, sometines doesn't retreive hero list, others there is nobody playing online etc... somre random bugs...
https://bugs.winehq.org/show_bug.cgi?id=30849
Ker noa blue-t@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |blue-t@web.de
--- Comment #116 from Ker noa blue-t@web.de --- Is there any trace that i could do to get this fixed properly?
https://bugs.winehq.org/show_bug.cgi?id=30849
Bob Igo bob@igo.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|bob@igo.name |
https://bugs.winehq.org/show_bug.cgi?id=30849
David dd31879@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dd31879@yahoo.com
--- Comment #117 from David dd31879@yahoo.com --- (In reply to felix moreno from comment #115)
Like other said if you setarch i386 and opengl 100% of tries the game runs good, if not, sometines doesn't retreive hero list, others there is nobody playing online etc... somre random bugs...
I may be wrong on this but I just tried the new PTR of Diablo III ver. 2.1.2. It seems like it doesnt require the setarch command anymore. The live version still requires it though unfortunately. So perhaps something on the PTR has changed.
https://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #118 from Michael DeVore medv4380@yahoo.com --- (In reply to David from comment #117) All it means is that Warden isn't currently running on the PTR. It usually goes away shortly after a major patch has been issued only to come back once Warden is fully active. Sometimes it's a day. Sometimes it's a week. Sometimes Blizzard even turns Warden off to see how many cheaters will get lazy so they can catch them all at once when then turn it back on. Probably isn't a good thing that this error is a way of detecting Warden's activity.
https://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #119 from felix moreno info@justdust.es --- I confirm it just works with wine 1.9.0, no set arch or anything else, now there are other problems with 2.4 version of the game, but is also a windows problem.
https://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #120 from Michael DeVore medv4380@yahoo.com --- (In reply to felix moreno from comment #119)
I confirm it just works with wine 1.9.0, no set arch or anything else, now there are other problems with 2.4 version of the game, but is also a windows problem.
Blizzard has a habit of turning off the "Warden" that causes the problem when patches are launched. Wait a week or so, and it'll come back. You'll find that it 2.4 doesn't have the problem with 1.7, or 1.8 ether at the moment, but it'll come back as it always has.
https://bugs.winehq.org/show_bug.cgi?id=30849
Maciej Stanczew maciej.stanczew+b@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maciej.stanczew+b@gmail.com
--- Comment #121 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Is anyone still experiencing this problem? I've been running without setarch for well over a year and for me the game doesn't hang anymore.
https://bugs.winehq.org/show_bug.cgi?id=30849
--- Comment #122 from Michael Cronenworth mike@cchtml.com --- I have been running Diablo 3 without the setarch prefix for some time. No hangs. I believe this can be closed.
https://bugs.winehq.org/show_bug.cgi?id=30849
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #123 from joaopa jeremielapuree@yahoo.fr --- Reported fixed by the last comment. Can an administrator close this bug as FIXED?
https://bugs.winehq.org/show_bug.cgi?id=30849
Erich E. Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |ABANDONED Status|REOPENED |RESOLVED
--- Comment #124 from Erich E. Hoover erich.e.hoover@gmail.com --- I am not certain we fixed anything here, so I'll go with abandoned.
https://bugs.winehq.org/show_bug.cgi?id=30849
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #125 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla