0

I was reading a reply to a question in the pintool mailing list here. Its mentioned that the delivery of asynchronous signals is delayed till the end of an analysis routine in a pintool. I'm curious about what exceptions in Windows qualify as an asynchronous signal.

1 Answers1

5

Basically nothing. But that's because you have the quotes around the wrong word. Windows doesn't have "signals".

Let me clarify that. You're referring to Linux, which like UNIX has a signal mechanism. This is a true OS-level functionality. Strangely enough, this OS feature made it into the C language (unlike far more useful stuff like directories). Windows does not offer UNIX signals, so C compilers for Windows have to fake them.

What Windows does have are exceptions, in particular Structured Exceptions. These are handled quite differently. For instance, they normally are handled by stack-based exception handlers - something which doesn't even make sense for "asynchronous signals". On Linux the signal handlers tend to remain constant, on Windows the exception handlers may change at every function call. Delaying an exception might deliver it to entirely the wrong handler.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • One special case that may be worth mentioning: Microsoft's C runtime library allows you to handle control-C events via C's signal mechanism, but does not behave according to the C standard (specifically, the signal handler executes in a separate thread). – Harry Johnston Apr 08 '15 at 21:33
  • @HarryJohnston, the control handler thread gets injected by csrss (in response to an LPC message from conhost). It starts at `kernel32!CtrlRoutine`. If the process is `BeingDebugged` (PEB) it raises `DBG_CONTROL_C` via `RtlRaiseException` before it executes the registered control handlers, including the CRT's handler. In principle you could call this function directly via `CreateRemoteThread`, but it's undocumented. – Eryk Sun Apr 10 '15 at 13:41