[Bug 50453] New: CDB (Part of Debugging Tools for Windows) fails resume debugging after entry point break (continue debug event: 'DBG_EXCEPTION_HANDLED' is an alias for 'DBG_CONTINUE')
WineHQ Bugzilla
wine-bugs at winehq.org
Mon Jan 4 10:55:10 CST 2021
https://bugs.winehq.org/show_bug.cgi?id=50453
Bug ID: 50453
Summary: CDB (Part of Debugging Tools for Windows) fails resume
debugging after entry point break (continue debug
event: 'DBG_EXCEPTION_HANDLED' is an alias for
'DBG_CONTINUE')
Product: Wine
Version: 6.0-rc5
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: wineserver
Assignee: wine-bugs at winehq.org
Reporter: focht at gmx.net
Distribution: ---
Hello folks,
as it says. Found while trying to debug .NET executable with SOS Debugging
Extension for windbg/cdb.
--- snip ---
...
00d8: queue_exception_event( first=1, code=80000003, flags=00000000,
record=00000000, address=7bc46838, len=24, params={00000000,00000000,00000000}
)
00d8: *sent signal* signal=10
00d8: queue_exception_event() = 0 { handle=003c }
...
0024:Ret KERNEL32.WaitForDebugEvent() retval=00000001 ret=022f28c5
0024:Call KERNEL32.SuspendThread(0000007c) ret=022f1d59
0024:Call ntdll.NtSuspendThread(0000007c,0031e0d4) ret=7b04c5a3
0024: suspend_thread( handle=007c )
0024: suspend_thread() = 0 { count=0 }
0024:Ret ntdll.NtSuspendThread() retval=00000000 ret=7b04c5a3
0024:Ret KERNEL32.SuspendThread() retval=00000000 ret=022f1d59
0024:Call KERNEL32.GetThreadContext(0000007c,007f3aa0) ret=022f2009
0024: get_thread_context( handle=007c, flags=0000003f )
00d8: *signal* signal=19
0024: get_thread_context() = 0 { self=0, handle=0000,
context={cpu=x86,eip=7bc46839,esp=0031ef68,ebp=0031efcc,eflags=00000246,cs=0023,ss=002b,ds=002b,es=002b,fs=0063,gs=006b,eax=ffffffff,ebx=7bc6d2c0,ecx=0031ef7c,edx=0031efc4,esi=0031ef6c,edi=7ffc2000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,fp.ctrl=ffff027f,fp.status=ffff0020,fp.tag=ffffffff,fp.err_off=f7ccf321,fp.err_sel=00000023,fp.data_off=0031e800,fp.data_sel=ffff002b,fp.cr0npx=00000020,fp.reg0=0,fp.reg1=0,fp.reg2=0,fp.reg3=0,fp.reg4=0,fp.reg5=0,fp.reg6=0,fp.reg7=1.16561e+12,extended={0020027f,...,00000000}}
}
...
0024:Call
KERNEL32.ReadProcessMemory(00000078,7bc46838,0031eaaf,00000001,0031e9f8)
ret=022f1432
0024:Call
ntdll.NtReadVirtualMemory(00000078,7bc46838,0031eaaf,00000001,0031e9f8)
ret=7b0294ec
0024: read_process_memory( handle=0078, addr=7bc46838 )
00d8: *signal* signal=19
0024: read_process_memory() = 0 { data={cc} }
0024:Ret ntdll.NtReadVirtualMemory() retval=00000000 ret=7b0294ec
0024:Ret KERNEL32.ReadProcessMemory() retval=00000001 ret=022f1432
...
0024:Call KERNEL32.SetThreadContext(0000007c,007f3aa0) ret=022f2095
0024:Call ntdll.NtSetContextThread(0000007c,007f3aa0) ret=7b04be93
0024: set_thread_context( handle=007c,
context={cpu=x86,eip=7bc46839,esp=0031ef68,ebp=0031efcc,eflags=00000246,cs=0023,ss=002b,ds=002b,es=002b,fs=0063,gs=006b,eax=ffffffff,ebx=7bc6d2c0,ecx=0031ef7c,edx=0031efc4,esi=0031ef6c,edi=7ffc2000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,fp.ctrl=ffff027f,fp.status=ffff0020,fp.tag=ffffffff,fp.err_off=f7ccf321,fp.err_sel=00000023,fp.data_off=0031e800,fp.data_sel=ffff002b,fp.cr0npx=00000020,fp.reg0=0,fp.reg1=0,fp.reg2=0,fp.reg3=0,fp.reg4=0,fp.reg5=0,fp.reg6=0,fp.reg7=1.16561e+12,extended={0020027f,...,00000000}}
)
0024: set_thread_context() = 0 { self=0 }
0024:Ret ntdll.NtSetContextThread() retval=00000000 ret=7b04be93
0024:Ret KERNEL32.SetThreadContext() retval=00000001 ret=022f2095
...
0024:Call KERNEL32.ResumeThread(0000007c) ret=022f1de9
0024:Call ntdll.NtResumeThread(0000007c,0031e614) ret=7b04be53
0024: resume_thread( handle=007c )
0024: resume_thread() = 0 { count=1 }
0024:Ret ntdll.NtResumeThread() retval=00000000 ret=7b04be53
0024:Ret KERNEL32.ResumeThread() retval=00000001 ret=022f1de9
...
0024:Call KERNEL32.ContinueDebugEvent(000000d4,000000d8,00010001) ret=022f2b24
0024: continue_debug_event( pid=00d4, tid=00d8, status=65537 )
0024: continue_debug_event() = INVALID_PARAMETER
0024:Call ntdll.RtlNtStatusToDosError(c000000d) ret=7b00f5ff
0024:Ret ntdll.RtlNtStatusToDosError() retval=00000057 ret=7b00f5ff
0024:Ret KERNEL32.ContinueDebugEvent() retval=00000000 ret=022f2b24
0024:Call KERNEL32.GetLastError() ret=022f2b2e
0024:Ret KERNEL32.GetLastError() retval=00000057 ret=022f2b2e
...
0024:Call KERNEL32.WideCharToMultiByte(00000000,00000000,02338080 L"Win32 error
0n87",ffffffff,00000000,00000000,00000000,00000000) ret=020f669a
...
0024:Call KERNEL32.WideCharToMultiByte(00000000,00000000,020285d8 L"This
usually indicates that the debuggee has been\nkilled out from underneath the
debugger.\nYou can use .tlist to see if the debuggee still
exists.\n",ffffffff,00000000,00000000,00000000,00000000) ret=020f669a
--- snip ---
Microsoft docs:
https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-continuedebugevent
It's not listed there but common knowledge that 'DBG_EXCEPTION_HANDLED' is an
alias for 'DBG_CONTINUE' in 32-bit environment.
Also mentioned here:
https://source.winehq.org/git/wine.git/commitdiff/fe36b7baca253f1e95cc790b84308969bd6ecc60
("ntdll: Made DBG_EXCEPTION_HANDLED a synonym of DBG_CONTINUE for exception
handlers."), in 2005
--- snip ---
$ grep -Hrni DBG_EXCEPTION_HANDLED
include/ntstatus.h:1694:#define DBG_EXCEPTION_HANDLED ((NTSTATUS)
0x00010001)
include/winerror.h:640:#define ERROR_DBG_EXCEPTION_HANDLED
766
include/winnt.h:652:#define DBG_EXCEPTION_HANDLED ((DWORD) 0x00010001)
dlls/ntdll/error.c:196: ERROR_DBG_EXCEPTION_HANDLED,
/* 00010001 (DBG_EXCEPTION_HANDLED) */
dlls/ntdll/tests/error.c:543: cmp2(DBG_EXCEPTION_HANDLED,
ERROR_DBG_EXCEPTION_HANDLED);
dlls/ntdll/unix/thread.c:430: if (status == DBG_CONTINUE || status ==
DBG_EXCEPTION_HANDLED)
dlls/ntdll/unix/signal_arm64.c:669: if (status == DBG_CONTINUE || status ==
DBG_EXCEPTION_HANDLED)
dlls/ntdll/unix/signal_i386.c:1615: if (status == DBG_CONTINUE || status ==
DBG_EXCEPTION_HANDLED)
dlls/ntdll/unix/signal_x86_64.c:1982: if (status == DBG_CONTINUE || status
== DBG_EXCEPTION_HANDLED)
dlls/ntdll/unix/signal_arm.c:571: if (status == DBG_CONTINUE || status ==
DBG_EXCEPTION_HANDLED)
dlls/ntdll/make_errors:67: DBG_EXCEPTION_HANDLED
ERROR_DBG_EXCEPTION_HANDLED
--- snip ---
Wine source:
https://source.winehq.org/git/wine.git/blob/9b12eae9ea445bbdeae196312fb65d20cdf27745:/server/debugger.c#l674
--- snip ---
674 /* Continue a debug event */
675 DECL_HANDLER(continue_debug_event)
676 {
677 struct process *process;
678
679 if (req->status != DBG_EXCEPTION_NOT_HANDLED &&
680 req->status != DBG_CONTINUE &&
681 req->status != DBG_REPLY_LATER)
682 {
683 set_error( STATUS_INVALID_PARAMETER );
684 return;
685 }
686
687 if ((process = get_process_from_id( req->pid )))
688 {
689 struct thread *thread = get_thread_from_id( req->tid );
690 if (thread)
691 {
692 continue_debug_event( process, thread, req->status );
693 release_object( thread );
694 }
695 release_object( process );
696 }
697 }
---- snip ---
Following relevant changes made this a regression:
*
https://source.winehq.org/git/wine.git/commitdiff/7332de64a5a204cc285bdc1f8768d3217103b7dd
("server: Validate status in continue_debug_event."), Part of Wine 5.2
*
https://source.winehq.org/git/wine.git/commitdiff/e2a1f00a3850dbce89ec0f85bc46fcd858f9a798
("server: Implement DBG_REPLY_LATER handling.")
With a fix applied, debugging (resuming) with CDB works again.
$ wine --version
wine-6.0-rc5
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.
More information about the wine-bugs
mailing list