New subject: [Bug 44819] kernel32.OutputDebugString/ ntdll.DbgPrint should throw DBG_PRINTEXCEPTION_C a second time if attached debugger didn 't consume it

25 Mar 2018


      https://bugs.winehq.org/show_bug.cgi?id=44819
Bug ID: 44819
           Summary: kernel32.OutputDebugString/ntdll.DbgPrint should throw
                    DBG_PRINTEXCEPTION_C a second time if attached
                    debugger didn't consume it
           Product: Wine
           Version: 3.4
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ntdll
          Assignee: wine-bugs@winehq.org
          Reporter: focht@gmx.net
      Distribution: ---
Hello folks,
to track
https://github.com/wine-staging/wine-staging/blob/master/patches/ntdll-Excep...
Unfortunately there is no further information/details on this.
My guess would be that Sebastian observed this behaviour while debugging some
application under native Windows.
I've found some interesting/related remarks about this behaviour here:
https://www.virusbulletin.com/virusbulletin/2009/01/anti-unpacker-tricks-par...
The observed behaviour is described in 'ntdll.DbgPrint' remark:
--- quote ---
Similarly, despite the fact that the ntdll DbgPrint() function raises the
DBG_PRINTEXCEPTION_C (0x40010006) exception, a registered Structured Exception
Handler will not see it. Once again, the reason is that Windows registers its
own Structured Exception Handler internally, which consumes the exception if a
debugger does not do so. As such, the presence of a debugger that consumes the
exception cannot be inferred by the absence of it.
However, as discussed previously, in Windows XP and later, any registered
Vectored Exception Handler will run before the Structured Exception Handler
that Windows registers and the presence of a debugger that consumes the
exception can now be inferred by the absence of the exception. Further, a
different exception is delivered to the Vectored Exception Handler if a
debugger is present but has not consumed the exception, or if a debugger is not
present. If a debugger is present but has not consumed the exception, then
Windows will deliver the DBG_PRINTEXCEPTION_C (0x40010006) exception. If a
debugger is not present, then Windows will deliver the
EXCEPTION_ACCESS_VIOLATION (0xC0000005) exception. The presence of a debugger
can now be inferred by either the absence of the exception, or by the value of
the exception.
--- quote ---
remark for 'kernel32.OutputDebugString':
--- quote ---
Despite the fact that the kernel32 OutputDebugString() function raises the
DBG_PRINTEXCEPTION_C (0x40010006) exception, a registered Structured Exception
Handler will not see it. The reason is that Windows registers its own
Structured Exception Handler internally, which consumes the exception if a
debugger does not do so. As such, the presence of a debugger that consumes the
exception cannot be inferred by the absence of the exception.
However, in Windows XP and later, any registered Vectored Exception Handler
will run before the Structured Exception Handler that Windows registers. This
might be considered a bug in Windows. In this case the presence of a debugger
that consumes the exception can be inferred by its absence.
--- quote ---
$ wine --version
wine-3.4
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.

[Bug 44819] New: kernel32.OutputDebugString/ ntdll.DbgPrint should throw DBG_PRINTEXCEPTION_C a second time if attached debugger didn 't consume it