[Bug 39738] New: Collecting backtrace of crashing process not possible.

List overview All Threads

newer

older

[Bug 39739] New: Cobra 11 -...

[Bug 39734] New: ProtectDisc...

wine-bugs＠winehq.org

4 Dec 2015 4 Dec '15

2:15 p.m.

https://bugs.winehq.org/show_bug.cgi?id=39738

Bug ID: 39738 Summary: Collecting backtrace of crashing process not possible. Product: Wine Version: 1.8-rc2 Hardware: x86-64 URL: http://www.4players.de/4players.php/download_info/Down loads/Download/50183/Alarm_fuer_Cobra_11_Burning_Wheel s/Deutsche_Demo.html OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: bernhardu@vr-web.de Distribution: Debian

Created attachment 52997 --> https://bugs.winehq.org/attachment.cgi?id=52997 On crash stop all other threads before executing winedbg.

This is about a crash in "Cobra 11 - Burning Wheels" demo.

It seems this demo includes parts of the copy protection of the full game. (see https://bugs.winehq.org/show_bug.cgi?id=39734 ) Therefore it is not possible to start it with winedbg from begin. Also one gets the crash dialog, but clicking on details shows just "Loading detailed information, please wait...".

With the crash dialog disabled it shows: wine: Unhandled page fault on read access to 0x1adb2920 at address 0x52f7b2 (thread 0009), starting debugger... Process of pid=0008 has terminated No process loaded, cannot execute 'echo Modules:' Cannot get info on module while no process is loaded No process loaded, cannot execute 'echo Threads:' (remaining threads) winedbg: Internal crash at 0x7ed8af1d

Attaching plain gdb makes the process not end itself and the process gets stopped on the crash. But setting breakpoints is not possible without "disturbing" the process.

The attached patch assumes that just one thread crashes which starts then winedbg. Meanwhile another thread gets notified about the crash and terminates the process before winedbg gets a chance to attach. Therefore this patch tries to suspend all other threads before starting winedbg. That way the crash dialog could show a backtrace reliably.

-- 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.

Show replies by date

wine-bugs＠winehq.org

4 Dec 4 Dec

4:25 p.m.

New subject: [Bug 39738] Protect DiSC v9.x DRM scheme prevents collection of crash information by configured JIT debugger (Cobra 11 - Burning Wheels)

https://bugs.winehq.org/show_bug.cgi?id=39738

Anastasius Focht focht@gmx.net changed:

--- Comment #1 from Anastasius Focht focht@gmx.net --- Hello Bernhard,

confirming.

A bunch of anti-debug watcher threads, part of the Protect DiSC v9.x DRM scheme is the problem here. They are continuously looking for "well known" processes (using window classes) and also check the PEB/debugger present flag in local process.

One of the watcher threads detects the process attach by the configured JIT debugger and terminates the process.

--- snip --- ... 0030:Starting thread proc 0x23b5efe (arg=0x23f64f6) 0030:Call KERNEL32.Sleep(000007d1) ret=023f6cde ... 0031:Starting thread proc 0x23b5efe (arg=0x23f6f42) 0031:Call KERNEL32.Sleep(000007d1) ret=023f7682 ... 0047:Starting thread proc 0x23b5efe (arg=0x24102db) 0047:Call KERNEL32.WaitForSingleObject(000000d4,ffffffff) ret=024103e5 ... 0031:Call KERNEL32.IsDebuggerPresent() ret=023f771b 0031:Ret KERNEL32.IsDebuggerPresent() retval=00000000 ret=023f771b ... 0031:Call user32.FindWindowA(023b7f95 "OLLYDBG",00000000) ret=023f78ea 0031:Ret user32.FindWindowA() retval=00000000 ret=023f78ea ... 0031:Call user32.FindWindowA(023b7f95 "GBDYLLO",00000000) ret=023f7af6 0031:Ret user32.FindWindowA() retval=00000000 ret=023f7af6 ... 0031:Call user32.FindWindowA(023b7f95 "pediy06",00000000) ret=023f7cbd 0031:Ret user32.FindWindowA() retval=00000000 ret=023f7cbd ... 0031:Call user32.FindWindowA(023b7f95 "OLLYDBG",00000000) ret=023f78ea 0031:Ret user32.FindWindowA() retval=00000000 ret=023f78ea ... 0031:Call user32.FindWindowA(023b7f95 "GBDYLLO",00000000) ret=023f7af6 0031:Ret user32.FindWindowA() retval=00000000 ret=023f7af6 ... 0031:Call user32.FindWindowA(023b7f95 "pediy06",00000000) ret=023f7cbd 0031:Ret user32.FindWindowA() retval=00000000 ret=023f7cbd ... 0031:Call KERNEL32.Sleep(000007d1) ret=023f7682 ... 0031:Call KERNEL32.Sleep(000007d1) ret=023f7682 ... 002f:trace:seh:raise_exception code=80000003 flags=0 addr=0x2064e46 ip=02064e47 tid=002f 002f:trace:seh:raise_exception eax=00000004 ebx=6ce5dee6 ecx=00cc1257 edx=00000000 esi=00cc1257 edi=00feabf0 002f:trace:seh:raise_exception ebp=4243484b esp=0146c738 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00200206 002f:trace:seh:call_stack_handlers calling handler at 0x2064e1a code=80000003 flags=0 002f:Call KERNEL32.GetTickCount() ret=020644b5 002f:Ret KERNEL32.GetTickCount() retval=008af18f ret=020644b5 002f:Call KERNEL32.GetTickCount() ret=02064507 002f:Ret KERNEL32.GetTickCount() retval=008af18f ret=02064507 002f:Call KERNEL32.CreateFileA(02122f54 "\\.\SICE",c0000000,00000003,00000000,00000003,00000080,00000000) ret=0207c9aa 002f:Ret KERNEL32.CreateFileA() retval=ffffffff ret=0207c9aa 002f:Call KERNEL32.CreateFileA(0146c6e8 "\\.\SIWVID",c0000000,00000003,00000000,00000003,00000080,00000000) ret=0207c9aa 002f:Ret KERNEL32.CreateFileA() retval=ffffffff ret=0207c9aa 002f:Call KERNEL32.CreateFileA(0146c6e8 "\\.\NTICE",c0000000,00000003,00000000,00000003,00000080,00000000) ret=0207c9aa 002f:Ret KERNEL32.CreateFileA() retval=ffffffff ret=0207c9aa ... 002f:Call advapi32.RegOpenKeyExA(80000002,08091f08 "Software\NuMega\SoftIce",00000000,00020019,0146c6bc) ret=0207db61 002f:Ret advapi32.RegOpenKeyExA() retval=00000002 ret=0207db61 ... 002f:trace:seh:raise_exception code=c0000005 flags=0 addr=0x52f7b2 ip=0052f7b2 tid=002f 002f:trace:seh:raise_exception info[0]=00000000 002f:trace:seh:raise_exception info[1]=1a6a0920 002f:trace:seh:raise_exception eax=0f76cea8 ebx=1cc0c020 ecx=000722b9 edx=0002b71e esi=1c2ef076 edi=1a545030 002f:trace:seh:raise_exception ebp=0146f7d0 esp=0146f700 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210212 002f:trace:seh:call_stack_handlers calling handler at 0x5e970e code=c0000005 flags=0 002f:Call KERNEL32.GetLastError() ret=005d233a 002f:Ret KERNEL32.GetLastError() retval=00000000 ret=005d233a 002f:trace:seh:call_stack_handlers handler at 0x5e970e returned 1 002f:trace:seh:call_stack_handlers calling handler at 0x5d0f20 code=c0000005 flags=0 002f:Call KERNEL32.GetLastError() ret=005d233a 002f:Ret KERNEL32.GetLastError() retval=00000000 ret=005d233a 002f:trace:seh:call_stack_handlers handler at 0x5d0f20 returned 1 002f:trace:seh:call_stack_handlers calling handler at 0x7bcaad0d code=c0000005 flags=0 002f:Call KERNEL32.UnhandledExceptionFilter(0146f204) ret=7bcaad48 wine: Unhandled page fault on read access to 0x1a6a0920 at address 0x52f7b2 (thread 002f), starting debugger... 002f:trace:seh:start_debugger Starting debugger "winedbg --auto 46 464" ... 0031:Call KERNEL32.IsDebuggerPresent() ret=023f771b 0031:Ret KERNEL32.IsDebuggerPresent() retval=00000001 ret=023f771b 0032:Call KERNEL32.Sleep(000007d1) ret=023f878e 0030:Ret KERNEL32.Sleep() retval=00000000 ret=023f6cde 0035:Ret KERNEL32.Sleep() retval=00000000 ret=023fade2 0030:Call KERNEL32.Sleep(000007d1) ret=023f6cde 0035:Call KERNEL32.Sleep(000007d1) ret=023fade2 0034:Ret KERNEL32.Sleep() retval=00000000 ret=023fa3b7 0037:Ret KERNEL32.Sleep() retval=00000000 ret=023fc3a3 0034:Call KERNEL32.Sleep(000007d1) ret=023fa3b7 0037:Call KERNEL32.Sleep(000007d1) ret=023fc3a3 0036:Ret KERNEL32.Sleep() retval=00000000 ret=023fb903 000b:Ret KERNEL32.Sleep() retval=00000000 ret=02445b64 0036:Call KERNEL32.Sleep(000007d1) ret=023fb903 004d:Ret KERNEL32.Sleep() retval=00000000 ret=00cf1dae 000b:Call user32.FindWindowA(024458ce "Regmonclass",00000000) ret=02445c00 004d:Call KERNEL32.TerminateProcess(00000128,00000000) ret=00cf2be6 ... 0031:Call KERNEL32.ExitThread(00000000) ret=023ba69d ... 0031:Call PE DLL (proc=0x7cf2257c,module=0x7cec0000 L"msvcrt.dll",reason=THREAD_DETACH,res=(nil)) 002f:Ret KERNEL32.UnhandledExceptionFilter() retval=00000000 ret=7bcaad48 ... Process of pid=002e has terminated No process loaded, cannot execute 'echo Modules:' Cannot get info on module while no process is loaded No process loaded, cannot execute 'echo Threads:' --- snip ---

Although it helps in this case, your patch will break Windows compatibility.

Windows doesn't suspend all other threads of the process during handling of 'UnhandledExceptionFilter' in the context of the faulting thread.

Secondary failures must be still allowed to occur on a different thread, causing the exception filter to be entered by an additional thread at the same time as an event from the first crash is already processed.

My guess would be if the crash is simulated/replicated on Windows it will react in the same way. Some debuggers support methods of non-invasive debugging, not causing 'BeingDebugged' set in target PEB so it might behave differently - depending on the type of configured JIT.

I've reworded the summary since this is a special case where a specific anti-debugger protection scheme actually causes the problem.

$ sha1sum BurningWheelsDemo.exe du6dc03653b97a0336a5c57fc4b04af61e3ebcee5e BurningWheelsDemo.exe

$ du -sh BurningWheelsDemo.exe 286M BurningWheelsDemo.exe

$ wine --version wine-1.8-rc3

Regards

-- 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.

wine-bugs＠winehq.org

13 Jan 13 Jan

11:32 p.m.

New subject: [Bug 39738] Protect DiSC v9.x DRM scheme prevents collection of crash information by configured JIT debugger (Cobra 11 - Burning Wheels)

https://bugs.winehq.org/show_bug.cgi?id=39738

Bernhard Übelacker bernhardu@vr-web.de changed:

--- Comment #2 from Bernhard Übelacker bernhardu@vr-web.de --- (In reply to Anastasius Focht from comment #1) Hello Anastasius, thanks for for your analysis.

...

Although it helps in this case, your patch will break Windows compatibility.

Windows doesn't suspend all other threads of the process during handling of 'UnhandledExceptionFilter' in the context of the faulting thread.

Secondary failures must be still allowed to occur on a different thread, causing the exception filter to be entered by an additional thread at the same time as an event from the first crash is already processed.

My guess would be if the crash is simulated/replicated on Windows it will react in the same way.

So when native does it that way then I think the right thing would be to close this bug as "resolved invalid"?

Kind regards, Bernhard

-- 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.

wine-bugs＠winehq.org

11:37 p.m.

New subject: [Bug 39738] Protect DiSC v9.x DRM scheme prevents collection of crash information by configured JIT debugger (Cobra 11 - Burning Wheels)

https://bugs.winehq.org/show_bug.cgi?id=39738

Austin English austinenglish@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED

--- Comment #3 from Austin English austinenglish@gmail.com --- (In reply to Bernhard Übelacker from comment #2)

...

So when native does it that way then I think the right thing would be to close this bug as "resolved invalid"?

Yeah, INVALID or WONTFIX.

-- 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.

WineHQ Bugzilla

1 Jul 1 Jul

6:31 a.m.

New subject: [Bug 39738] Protect DiSC v9.x DRM scheme prevents collection of crash information by configured JIT debugger (Cobra 11 - Burning Wheels)

https://bugs.winehq.org/show_bug.cgi?id=39738

Anastasius Focht focht@gmx.net changed:

-- 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.

1371

Age (days ago)

3407

Last active (days ago)

wine-bugs@winehq.org

4 comments

2 participants

tags (0)

participants (2)

wine-bugs＠winehq.org
WineHQ Bugzilla