1 / 28

Exception Dispatching

Exception Dispatching. Structured Exception Handling (1). Windows introduced a facility known as structured exception handling When (exceptions occur) Allows applications to gain control Application can fix condition and Return to the place the exception occurred,

crawfordk
Download Presentation

Exception Dispatching

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Exception Dispatching

  2. Structured Exception Handling (1) • Windows introduced a facility known as structured exception handling • When (exceptions occur) • Allows applications to gain control • Application can fix condition and • Return to the place the exception occurred, • Unwind the stack (terminating execution of the subroutine that raised the exception), • Or declare back to the system that the exception isn’t recognized and the system should continue searching for an exception handler that might process the exception.

  3. Structured Exception Handling (2) • Although exception handling is made accessible through language extensions • It is a system mechanism • Not language-specific. • On x86 • all exceptions have predefined interrupt numbers that directly correspond to the entry in the interrupt dispatch table (IDT). • Table on next page shows • x86-defined exceptions • Interrupt numbers • Because first entries of IDT are used for exceptions • Hardware interrupts are assigned entries later

  4. Exception Dispatcher • Many exceptions are serviced by kernel module -- exception dispatcher • Other simple exceptions are resolved by trap handler. • Exception dispatcher’s job is to find an exception handler to handle the exception.

  5. Kernel Handle Exception • Kernel traps and handles exceptions to user programs. • For example, encountering a breakpoint while executing a program being debugged generates an exception, which the kernel handles by calling the debugger. • Kernel handles certain other exceptions by returning unsuccessful state code to caller.

  6. Stack Frame • A few exceptions are allowed to filter back, untouched, to user mode. • For example, a memory access violation or an arithmetic overflow generates an exception. • Environment subsystem • Establish frame-based exception handlers to deal with these exceptions. • Frame-based refer to exception handler’s association with particular procedure activation. • When a procedure is invoked, a Stack frame representing that activation of the procedure is pushed onto the stack. • Stack frame can associating with some exception handlers, each of which protects a particular block of code in source program. • When exception occurs, kernel search for an exception handler associated with current stack frame, if none exist, kernel search for previous one, and so on. • If still none exist, kernel call its own default one.

  7. Trap frame • When exception occurs, a chain of events begins in kernel. • CPU hardware transfer control to kernel trap handler, which create a trap frame. • if (exception is resolved) • Trap frame allow system to resume where if left off. • Trap handler create an exception record containing the reason for exception and relative information.

  8. Default exception handling • If exception occurred in kernel mode, exception dispatcher call a routine to locate a frame-based exception handler to handle it. • Unhandled kernel-mode exceptions are considered fatal operating system errors, you can assume dispatcher always finds an exception handler. • If it occurred in user mode, what exception dispatcher does is more complex, you’ll see in Chapter 6. • Windows subsystem has debugger port and exception port to receive notification of user-mode exceptions. • Kernel use these in its default exception handling.

  9. Exception Dispatcher (1) • Exception dispatcher’s first action • See whether process that incurred exception has associated debugger process. • If (it does && system is Windows 2000) • Exception dispatcher • Send first-chance debug message via local procedure call (LPC) to the debugger port associated with the process. • LPC message • Is sent to session manager process, which then dispatches it to appropriate debugger process. • On Windows XP and Server 2003 • Exception dispatcher send debugger object message to debug object associated with process.

  10. Exception Dispatcher (2) • If(No debugger process attached process || debugger doesn’t handle exception) • Exception dispatcher • Switches into user mode • Copy trap frame to user stack formatted as a CONTEXT data structure. • Call routine to find frame-based exception handler. • If(none is found || none handles the exception) • Exception dispatcher • Switches back into kernel mode • Call debugger to allow user to do more debugging.

  11. Exception Dispatcher (3) • If(debugger isn’t running && no frame-based handlers be found) • The kernel • Send message to exception port associated with thread’s process. • Exception port • Registered by environment subsystem that controls this thread. • Give the environment subsystem, which presumably is listening at the port, the opportunity to translate exception into environment-specific signal or exception. • CSRSS(Client/Server Run-Time Subsystem) • Present message box notifying user of fault and terminate process, • When (POSIX get message from kernel) • POSIX subsystem send POSIX-style signal to thread • If(kernel progresses this far in processing exception && subsystem do not handle exception) • Kernel • Execute default exception handler to terminate process

  12. Unhandled Exceptions • All Windows thread • Have an exception handler declared at the top of the stack that processes unhandled exceptions • The exception handler • Is declared in internal Windows start-of-process or start-of-thread function. • Start-of-process function • Run when first thread in a process begins execution. • Call main entry point in the image. • Start-of-thread function • Run when a user create additional threads. • Call user-supplied thread start routine specified in CreateThread call.

  13. Windows Unhandled Exception Filter (1) • If(thread has unhandled exception) • Windows unhandled exception filter is called • Purpose of this function • Provide system-defined behavior for what to do

  14. Windows Unhandled Exception Filter (2) • Two important value • Auto • Debugger • Auto • Tell unhandled exception filter Whether to automatically run debugger • Or, ask user what to do • Default = 1 • Launch debugger automatically. • Installing development tools (ex: Visual Studio) changes this to 0 • Debugger value • A string • Pointing to path of debugger executable to run in the case of unhandled exception

  15. Debugger • Default debugger is Dr. Watson • \Windows\System32\Drwtsn32.exe • Not really a debugger • A postmortem tool • Activation • Capture state of the crashed application • Records it in • Log file (Drwtsn32.log) • Process crash dump file (User.dmp) • \Documents And Settings\All Users\Documents\DrWatson

  16. Configuration for Dr. Watson

  17. Log File & Crash Dump File • Log file • Contain basic information • Exception code • Name of the failed image • List of loaded DLLs • Stack and instruction trace for the thread that incurred exception • Crash dump file • Contain private pages in process at the time of exception • This crash dump file can be opened by WinDbg (Windows debugger, comes with Debugging Tools package, or Visual Studio 2003 and later) • Overwritten each time a process crash.

  18. Visual Notification (1) • Windows 2000 Pro. • Visual notification, default = on • After generate crash dump and records information in log file. • Message box displayed by Dr. Watson

  19. Visual Notification (2) • Dr. Watson process • Remains until message box is dismissed. • This is why visual notification is turned off by default in Windows 2000 Server system. • This default is used • Because • If(server application fail) • Usually nobody can dismiss message box. • Instead • Server applications should log errors to the Windows event log.

  20. Message Box On Windows 2000 • If(Auto value == 0) • Message box is displayed • If (click OK) • Process exit • If (click Cancel) • Launch system defined debugger process.

  21. Windows Error Reporting (1) • Windows XP and Server 2003 have Windows Error Reporting • More sophisticated error-reporting mechanism • Automates the submission of • User-mode process crashes • Kernel-mode system crashes • Configured • How to bring up dialog box ? • My Computer -> Properties -> Advanced -> Error Reporting • Or, System -> Error Reporting -> local or domain group policy settings • Store settings • HKLM\Software\Microsoft\PCHealth\ErrorReporting

  22. Windows Error Reporting (3) • When (catch an unhandled exception) • To see whether or not to initiate Windows Error Reporting • If (registry value == 0 || Debugger string contain “Drwtsn32”) • Unhandled exception filter • Load \Windows\System32\Faultrep.dll into failing process • Call its ReportFault function • ReportFault • Check error-reporting configuration • Purpose • To see whether this process crash should be reported • If so, • Create process running \Windows\System32\Dwwin.exe, • which display message box announcing process crash • Along with option to submit error report to Micro$oft. (as seen in figure of next page)

  23. Windows Error Reporting (4)

More Related