https://bugs.winehq.org/show_bug.cgi?id=38627
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Béla Gyebrószki from comment #2)
Created attachment 51535 [details] +relay,+seh,+tid partial log (uncompressed 98 MB)
Thanks. There is an access violation exception in Vision90.dll when it handles PROCESS_DETACH event. An exception occurs right after the following calls: wined3d.wined3d_buffer_decref()=0 wined3d.wined3d_mutex_unlock()=0 These calls should go from inside of Wine ddraw*/d3d* dlls, but there is no appropriate relay calls for them in the log, so it's impossible to say what is going on exactly. I'd guess that in order to investigate further one needs to see what's wrong with ddraw*/d3d*, as a wild guess may be one of these dlls invokes a callback on destruction which application doesn't expect at this point, but that's a pure speculation.
(In reply to Béla Gyebrószki from comment #3)
The vast majority of the full +relay log (2.9 GB) consists of the same msvcp90/msvcr90 calls so I could squeeze it into a 30 MB .7z archive: https://drive.google.com/open?id=0B-tTbLKBl-tONjJ5RWo1ZmlCYzQ
What if I create a +relay with native msvcp90/msvcr90 installed? The problem is present with native too, and that would reduce the log size to a humble 200 MB? Or would that make debugging more difficult?
It would be more interesting to force ddraw*/d3d* calls appear in the log, but I can't off the top of my head suggest how to do that, probably playing with RelayExclude/RelayInclude keys in the registry would make the trick. Although reducing the log using native msvc* dlls should still keep interesting parts in the log.