[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]

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: [e-mail]
          Reporter: [e-mail]
      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-cont...

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/fe36b7baca253f1e95cc790b84...
("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/9b12eae9ea445bbdeae196312fb65d20...

--- 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/7332de64a5a204cc285bdc1f87...
("server: Validate status in continue_debug_event."), Part of Wine 5.2

*
https://source.winehq.org/git/wine.git/commitdiff/e2a1f00a3850dbce89ec0f85bc...
("server: Implement DBG_REPLY_LATER handling.")

With a fix applied, debugging (resuming) with CDB works again.

$ wine --version
wine-6.0-rc5

Regards