The .trap command change to, and displays the trap frame register state of the context at the specified address. Trap Frames only exist in Kernel Mode. Trap Frames are used to store the registers of the current thread when an interrupt occurs, or when there is a system service call (the transfer from user mode to kernel mode). Note, each trap frame scenario stores only a subset of the registers. To view the trap frames on the current thread, use the kv command. The address of each trap frame is listed as a postfix on each frame that was trapped. Additional Resources: Inside - .ecxr (Change to and Display the Exception Context Record)Inside - .cxr (Change to and Display a Context structure)Inside - Windows SDKMicrosoft Docs - Debugging Tools for WindowsMicrosoft Docs - .cxr (Change to and Display Context Record)Microsoft Docs - .ecxr (Change to and Display Exception Context Record)Microsoft Docs - trap (Display Trap Frame)

The .cxr command changes the debugger context. Using .cxr (without an address) resets the context to the default context. Using .cxr sets the debugger context to the CONTEXT structure values at the specified address. Additional Resources: Inside - .exr (Display Exception Record)Inside - .ecxr (Change to and Display the Exception Context Record)Inside - Windows SDKMicrosoft Docs - Debugging Tools for WindowsMicrosoft Docs - .cxr (Change to and Display Context Record)Microsoft Docs - .ecxr (Change to and Display Exception Context Record)MSDN - CONTEXT structure

The .exr command displays the contents of an exception record (a EXCEPTION_RECORD structure). The EXCEPTION_RECORD structure contains the Instruction Address (the function raising the exception), the Exception Code, and (max 15) Exception Parameters. The structure may be in the addess space of the process (that is, raised by the code itself), or stored in the metadata of the dump file (as past to MiniDumpWriteDump). To view a structure in the address space of the process, use .exr To view the structure saved to the dump, use .exr -1 In general, start the debugging of a dump file by executing .exr -1, .ecxr and k. And then use !analyze -v. Additional Resources: Inside - .ecxr (Display, and change to, the Exception Context Record)Inside - Windows SDKMicrosoft Docs - Debugging Tools for WindowsMicrosoft Docs - .exr (Display Exception Record)

The .ecxr command changes to the context that is associated with the dump's exception. It displays the registers at that context. Use .cxr to reset the context to the default context. In general, start the debugging of a dump file by executing .exr -1, .ecxr and k. And then use !analyze -v. Additional Resources: Inside - .exr (Display Exception Record)Inside - .cxr (Change to and Display a Context structure)Inside - Windows SDKMicrosoft Docs - Debugging Tools for WindowsMicrosoft Docs - .ecxr (Display Exception Context Record)MSDN - MiniDumpWriteDump functionMSDN - MINIDUMP_EXCEPTION_INFORMATION structureMSDN - EXCEPTION_POINTERS structureNote: Also supported as ".excr" due to the high occurrence of typos.

The .lastevent command displays the most recent exception or event that occurred. The default debugger context is automatically set to the TID specified. To change the context manually, use the TID as an index: ~~[TID]s Microsoft Docs: .lastevent (Display Last Event)MiniDumpWriteDump functionMINIDUMP_EXCEPTION_INFORMATION structure The following are displayed: The Process Identifier (PID) in hex (e.g. 5704)The Thread Identifier (TID) in hex (e.g. 4f7c)The Exception Code's descriptionThe Exception Code in hex (e.g. c0000409)The Time of the event

0:000> .lastevent

Last event: 5704.4f7c: Security check failure or stack buffer overrun - code c0000409 (first/second chance not available)

debugger time: Thu Jul 13 17:46:27.824 2017 (UTC - 7:00)

The Windows SDK provides code and tools to aid the development and troubleshooting of applications and systems. For troubleshooting, it includes the: Windows Performance ToolkitDebugging Tools for WindowsApplication VerifierThe Windows Performance Toolkit is Event Tracing for Windows based. Use Windows Performance Recorder (WPR) to record traces. Use Windows Performance Analyzer (WPA) to review traces. WPT is used to troubleshoot performance and logic issues. The Debugging Tools for Windows can be used to debug a process (User Mode Debugging) or system (Kernel Mode Debugging). There are multiple debugger shells available; WinDbg.exe (GUI) and CDB.exe (Command Line) are popular. The debuggers are used to troubleshoot application and system crashes, hangs, and logic issues. Alternatively, you can install the preview of the WinDbg application - available in the Microsoft Store. Application Verifier is a dynamic verification tool for user-mode applications. This tool monitors application actions while the application runs, subjects the application to a variety of stresses and tests, and generates a report about potential errors in application execution or design. Additional Resources: Microsoft Docs - Windows 10 SDKMicrosoft Docs - Windows SDK (Archive)Microsoft Docs - Debugging Tools for WindowsMicrosoft Docs - Windows Performance ToolkitMicrosoft Docs - Application VerifierMicrosoft Docs - Event Tracing for WindowsMicrosoft Store - WinDbg Preview

Welcome to the Inside Show, the show that takes you inside Windows.In each ~5min episode, we review a Windows Feature, Windows Internal, Exception Code, Bugcheck Code or Debugger Command. The list of available episodes is in show's description on the home page. Email questions, comments and requests to [email protected]