[Bug 45369] New: Under certain (unknown) conditions, winedbg.exe continually spawns explorer.exe sub-processes until it is killed
https://bugs.winehq.org/show_bug.cgi?id=45369
Bug ID: 45369 Summary: Under certain (unknown) conditions, winedbg.exe continually spawns explorer.exe sub-processes until it is killed Product: Wine-staging Version: 3.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: roman@hargrave.info CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Created attachment 61679 --> https://bugs.winehq.org/attachment.cgi?id=61679 A portion of wine console output collected after the event
I'd like to open with a note that I am not submitting this on wine-devel, as I the only application that has been able to cause these crashes will not run well enough to reliably reproduce the error without DXVK, and in turn wine-staging (as far as I am aware, DXVK continues to require a patch in the staging patchset that has not been mainlined - correct me if i am wrong).
The application which has been causing problems is Grand Theft Auto V, though specifically Rock Star Social Club (I can't be terribly certain - but the issue tends to crop up when social club is brought in to the question).
Glancing at the crash info in the terminal (winedbg is actually not even visible yet as it is too preoccupied with explorer), this is the result of an exception thrown within libcef.dll, which judging by the name and the platform which it is used by, is chromium embedded framework - a common offender.
Knowing this, i'll just avoid the social club in-game if at all possible, but what's concerning is the outcome. Something about the manner in which it has gone about crashing causes some _very_ eratic behaviour in winedbg. For some reason, `explorer.exe /desktop` is invoked as a child process of winedbg and then fails to start. Another instance of explorer with the same parameters is then started by the child, as well as some concurrent instances (I think - when you have so many process running that your PIDs roll over it start to get hard to track who started who) - effectively an explorer fork bomb, though it dies off fast enough if you get to winedbg and kill it or its parent.
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #1 from roman@hargrave.info roman@hargrave.info --- Created attachment 61680 --> https://bugs.winehq.org/attachment.cgi?id=61680 A screenshot of process hacker running in the prefix which displays the deeply nested explorer beneath winedbg.
https://bugs.winehq.org/show_bug.cgi?id=45369
roman@hargrave.info roman@hargrave.info changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- This would make sense if explorer.exe crashes; it'll try to start the winedbg crash dialogbut the latter will involve creating a window and thus starting another instance of explorer.exe. In that case creating the registry key HKCU\Software\Wine\WineDbg and setting the value ShowCrashDialog to 0 should work around the problem.
It would be good to fix this, of course. Could you please attach a log with +seh,+win,+explorer,+module?
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #3 from roman@hargrave.info roman@hargrave.info --- That's interesting.
I'll grab some logs and post them.
https://bugs.winehq.org/show_bug.cgi?id=45369
roman@hargrave.info roman@hargrave.info changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #61679|0 |1 is obsolete| |
--- Comment #4 from roman@hargrave.info roman@hargrave.info --- Created attachment 61684 --> https://bugs.winehq.org/attachment.cgi?id=61684 Log captured during normal usage up to the winedbg starting and then crashing
https://bugs.winehq.org/show_bug.cgi?id=45369
roman@hargrave.info roman@hargrave.info changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Under certain (unknown) |Under certain (unknown) |conditions, winedbg.exe |conditions winedbg.exe |continually spawns |crashes and attempts to |explorer.exe sub-processes |debug itself ad nauseum, |until it is killed |during or after usage of | |RockStar Social Club and/or | |GTA V
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #5 from roman@hargrave.info roman@hargrave.info --- Given the helpful nature of the `win` channel messages, I think I'll disable them next time I run the game and get a log without the clutter.
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #6 from roman@hargrave.info roman@hargrave.info --- Actually, hold on. That log has messages from channels that should be off. Hold off on using it for now.
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #7 from roman@hargrave.info roman@hargrave.info --- OK, so due to the complexity of steam and steam games, I'm going to have to lower a couple of the channel verbosity levels. The sheer overhead from logging is going to make it take extraordinarily long to actually get the chance to launch the only application (GTA V) which is known to bring about the issue, and then it will only crash at some arbitrary point during gameplay (due to a DXVK stub) which will be heavily affected by the log levels.
If you can let me know what you can work with as far as channel levels, lmk, but I'm going to run it with info-level instead of trace-level
https://bugs.winehq.org/show_bug.cgi?id=45369
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #8 from Zebediah Figura z.figura12@gmail.com --- I wouldn't expect just those channels to introduce a lot of overhead. Are you sure you don't have something like +relay on?
I don't need dxvk logs, so there's no need to use anything other than the default log level there.
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #9 from roman@hargrave.info roman@hargrave.info --- DXVK logging cannot be turned off.
I'm not using any other channels - specifically, it was run with -all,+seh,+win,+explorer,+module. Specifically, `win` introduced so much logging traffic that the steam updater was downloading an update at about 10KB/s
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #10 from roman@hargrave.info roman@hargrave.info --- * I should add that it's due to their logging level being set to trace when a channel is manually specified without an explicit level
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #11 from Zebediah Figura z.figura12@gmail.com --- Well, I wouldn't grab logs while Steam is updating itself if possible.
Still, if it's that infeasible, I guess just +seh,+module,+explorer might be enough to rootcause the problem.
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #12 from roman@hargrave.info roman@hargrave.info --- (In reply to Zebediah Figura from comment #11)
Well, I wouldn't grab logs while Steam is updating itself if possible.
Still, if it's that infeasible, I guess just +seh,+module,+explorer might be enough to rootcause the problem.
The updater runs and may or may not unpack files every startup. Regardless, the fact that it was doing what it was to the updater means that I would have to clock about three hours of gameplay (measured at full speed) at roughly ten seconds per frame, which would be totally not feasible. Still, nonetheless, I have attached a log with -all,+seh:trace,+win:warn,+explorer:info,+module:warn (or something, the ensuing process leak actually killed my disk IO in less than three seconds due to the kernel attempting to swap 16Gb of resident programs at high priority, I don't have the exact invocation since my shell actually failed to write a history file as a result)
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #13 from roman@hargrave.info roman@hargrave.info --- Created attachment 61689 --> https://bugs.winehq.org/attachment.cgi?id=61689 (More) detailed log
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #14 from Zebediah Figura z.figura12@gmail.com --- Unfortunately this isn't really helpful as it is, partly due to the lack of any useful channels and partly because apparently kernel32 wipes the WINEDEBUG variable when launching the debugger anyway.
However, it does seem my initial guess was incorrect—the new explorer.exe instances seems to be launched by explorer itself and not by winedbg. But without any useful traces I can't determine why that happens.
https://bugs.winehq.org/show_bug.cgi?id=45369
roman@hargrave.info roman@hargrave.info changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Under certain (unknown) |Under certain (unknown) |conditions winedbg.exe |conditions, the |crashes and attempts to |explorer.exe process |debug itself ad nauseum, |belonging to winedbg.exe |during or after usage of |will continue to spawn more |RockStar Social Club and/or |explorer instances |GTA V |indefinitely
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #15 from roman@hargrave.info roman@hargrave.info --- I have a final log I will post, but it is 2GB (removed win and left everything at trace). So i'm going to have to put it on my website since, when gzipped, it is still larger than the file size limit for the wine bugzilla.
http://hargrave.info/files/gtav-winedbg-explorerbomb.log.gz
For the time being I am going to disable winedbg.
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #16 from Zebediah Figura z.figura12@gmail.com --- As of a1d12ad5c68de7f3cbe0e34baa83dd8eedaab64f it should hopefully be possible to get more useful traces out of this.
Can you please try a log with +winedbg,+dbghelp,+explorer,+seh,+pid?
https://bugs.winehq.org/show_bug.cgi?id=45369
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEEDINFO
https://bugs.winehq.org/show_bug.cgi?id=45369
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|1 |0 Status|NEEDINFO |UNCONFIRMED
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #17 from Zebediah Figura z.figura12@gmail.com --- (In reply to Zebediah Figura from comment #16)
As of a1d12ad5c68de7f3cbe0e34baa83dd8eedaab64f it should hopefully be possible to get more useful traces out of this.
Can you please try a log with +winedbg,+dbghelp,+explorer,+seh,+pid?
Pinging this report again. This isn't particularly important, but if the bug can still be reproduced, it would be nice to track down the ultimate cause.
https://bugs.winehq.org/show_bug.cgi?id=45369
--- Comment #18 from roman@hargrave.info roman@hargrave.info --- (In reply to Zebediah Figura from comment #17)
(In reply to Zebediah Figura from comment #16)
As of a1d12ad5c68de7f3cbe0e34baa83dd8eedaab64f it should hopefully be possible to get more useful traces out of this.
Can you please try a log with +winedbg,+dbghelp,+explorer,+seh,+pid?
Pinging this report again. This isn't particularly important, but if the bug can still be reproduced, it would be nice to track down the ultimate cause.
I have not experienced this issue since. I think it's safe to close.
Sorry for the extreme delay.
https://bugs.winehq.org/show_bug.cgi?id=45369
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED
--- Comment #19 from Zebediah Figura z.figura12@gmail.com --- Thanks, resolving then.
https://bugs.winehq.org/show_bug.cgi?id=45369
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #20 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla