Reading Notebook: 05-August-09
Comments in italics are mine and express my own views, thoughts and opinions
Windows Internals by M. Russinovich, D. Solomon and A. Ionescu:
trap as exception or interrupt transfer from a thread to a fixed OS location (p. 85) - Long time ago I was interested in exception processing and how it relates to crash dumps. I wrote a few investigative posts and put them on this page: http://www.dumpanalysis.org/blog/index.php/interrupts-and-exceptions-explained/
viewing IDT (pp. 88 - 89) - here is the output of the first part of IDT from typical x86 kernel dump:
0: kd> !idt -a
Dumping IDT:
00: 805421b0 nt!KiTrap00
01: f620a4f6 ati2mtag+0x1774F6
02: Task Selector = 0x0058
03: f620a59c ati2mtag+0x17759C
04: 805428c0 nt!KiTrap04
05: 80542a20 nt!KiTrap05
06: 80542b94 nt!KiTrap06
07: 8054320c nt!KiTrap07
08: Task Selector = 0x0050
09: 80543610 nt!KiTrap09
0a: 80543730 nt!KiTrap0A
0b: 80543870 nt!KiTrap0B
0c: 80543ad0 nt!KiTrap0C
0d: 80543dbc nt!KiTrap0D
0e: 805444b8 nt!KiTrap0E
0f: 805447f0 nt!KiTrap0F
10: 80544910 nt!KiTrap10
11: 80544a4c nt!KiTrap11
12: Task Selector = 0×00A0
13: 80544bb4 nt!KiTrap13
14: 805447f0 nt!KiTrap0F
15: 805447f0 nt!KiTrap0F
16: 805447f0 nt!KiTrap0F
17: 805447f0 nt!KiTrap0F
18: 805447f0 nt!KiTrap0F
19: 805447f0 nt!KiTrap0F
1a: 805447f0 nt!KiTrap0F
1b: 805447f0 nt!KiTrap0F
1c: 805447f0 nt!KiTrap0F
1d: 805447f0 nt!KiTrap0F
1e: 805447f0 nt!KiTrap0F
1f: 806e710c hal!HalpApicSpuriousService
20: 00000000
21: 00000000
22: 00000000
23: 00000000
24: 00000000
25: 00000000
26: 00000000
27: 00000000
28: 00000000
29: 00000000
2a: 805419de nt!KiGetTickCount
2b: 80541ae0 nt!KiCallbackReturn
2c: 80541c90 nt!KiSetLowWaitHighThread
2d: 8054261c nt!KiDebugService
2e: 80541461 nt!KiSystemService
2f: 805447f0 nt!KiTrap0F
30: 80540b20 nt!KiUnexpectedInterrupt0
31: 80540b2a nt!KiUnexpectedInterrupt1
32: 80540b34 nt!KiUnexpectedInterrupt2
33: 80540b3e nt!KiUnexpectedInterrupt3
34: 80540b48 nt!KiUnexpectedInterrupt4
35: 80540b52 nt!KiUnexpectedInterrupt5
36: 80540b5c nt!KiUnexpectedInterrupt6
[…]
here is the output from my x64 machine (we see that KiTrap0E was renamed to KiPageFault):
1: kd> !idt
Dumping IDT:
00: fffff80001865180 nt!KiDivideErrorFault
01: fffff80001865240 nt!KiDebugTrapOrFault
02: fffff80001865380 nt!KiNmiInterrupt Stack = 0xFFFFFA60005F5D40
03: fffff800018656c0 nt!KiBreakpointTrap
04: fffff80001865780 nt!KiOverflowTrap
05: fffff80001865840 nt!KiBoundFault
06: fffff80001865900 nt!KiInvalidOpcodeFault
07: fffff80001865ac0 nt!KiNpxNotAvailableFault
08: fffff80001865b80 nt!KiDoubleFaultAbort Stack = 0xFFFFFA60005F1D40
09: fffff80001865c40 nt!KiNpxSegmentOverrunAbort
0a: fffff80001865d00 nt!KiInvalidTssFault
0b: fffff80001865dc0 nt!KiSegmentNotPresentFault
0c: fffff80001865ec0 nt!KiStackFault
0d: fffff80001865fc0 nt!KiGeneralProtectionFault
0e: fffff800018660c0 nt!KiPageFault
10: fffff80001866400 nt!KiFloatingErrorFault
11: fffff80001866540 nt!KiAlignmentFault
12: fffff80001866600 nt!KiMcheckAbort Stack = 0xFFFFFA60005F3D40
13: fffff80001866940 nt!KiXmmException
1f: fffff80001895290 nt!KiApcInterrupt
2c: fffff80001866ac0 nt!KiRaiseAssertion
2d: fffff80001866b80 nt!KiDebugServiceTrap
2f: fffff800018aeb60 nt!KiDpcInterrupt
37: fffff80001d58630 hal!HalpApicSpuriousService (KINTERRUPT fffff80001d585a0)
3f: fffff80001d586d0 hal!HalpApicSpuriousService (KINTERRUPT fffff80001d58640)
51: fffffa8003ec5c90 USBPORT!USBPORT_InterruptService (KINTERRUPT fffffa8003ec5c00)
HDAudBus!HdaController::Isr (KINTERRUPT fffffa8003ec5900)
61: fffffa8003ec5510 serial!SerialCIsrSw (KINTERRUPT fffffa8003ec5480)
72: fffffa8003ec5690 USBPORT!USBPORT_InterruptService (KINTERRUPT fffffa8003ec5600)
82: fffffa8003ec5a50 USBPORT!USBPORT_InterruptService (KINTERRUPT fffffa8003ec59c0)
92: fffffa8003ec5b10 USBPORT!USBPORT_InterruptService (KINTERRUPT fffffa8003ec5a80)
USBPORT!USBPORT_InterruptService (KINTERRUPT fffffa8003ec56c0)
a2: fffffa8003ec5810 USBPORT!USBPORT_InterruptService (KINTERRUPT fffffa8003ec5780)
USBPORT!USBPORT_InterruptService (KINTERRUPT fffffa8003ec5540)
b0: fffffa8003ec58d0 NDIS!ndisMiniportMessageIsr (KINTERRUPT fffffa8003ec5840)
b1: fffffa8003ec5f90 acpi!ACPIInterruptServiceRoutine (KINTERRUPT fffffa8003ec5f00)
b2: fffffa8003ec5bd0 ataport!IdePortInterrupt (KINTERRUPT fffffa8003ec5b40)
ataport!IdePortInterrupt (KINTERRUPT fffffa8003ec5e40)
ataport!IdePortInterrupt (KINTERRUPT fffffa8003ec5d80)
ataport!IdePortInterrupt (KINTERRUPT fffffa8003ec5cc0)
c1: fffff80001d58310 hal!HalpBroadcastCallService (KINTERRUPT fffff80001d58280)
d1: fffff800018611a0 nt!KiSecondaryClockInterrupt
d2: fffff80001d583b0 hal!HalpHpetRolloverInterrupt (KINTERRUPT fffff80001d58320)
df: fffff80001d58270 hal!HalpApicRebootService (KINTERRUPT fffff80001d581e0)
e1: fffff800018710a0 nt!KiIpiInterrupt
e3: fffff80001d58770 hal!HalpLocalApicErrorService (KINTERRUPT fffff80001d586e0)
fd: fffff80001d58810 hal!HalpProfileInterrupt (KINTERRUPT fffff80001d58780)
fe: fffff80001d588b0 hal!HalpPerfInterrupt (KINTERRUPT fffff80001d58820)
ff: 0000000000000000
x64 uses only APIC (p. 90) - !pic doesn’t work for x86 kernel dumps:
1: kd> !pic
!pic is for X86 targets only.
priority is thread attr. and IRQL is interrupt source attr. (p. 93) - orthogonality. I also created a few UML sequence diagrams in the past to illustrate the point: http://www.dumpanalysis.org/blog/index.php/2007/03/06/bugchecks-depicted-irql_not_less_or_equal/
Lazy IRQL - no PIC changes unless real interrupt (p. 93)
masked interrupts (by IRQL) may be serviced by another processor (p. 94)
APC level is thread-local, rescheduling doen’t block them (p. 94)
- Dmitry Vostokov @ SoftwareGeneralist.com -
_1125.png)
Coming Soon:
Fundamentals of Complete Crash and Hang Memory Dump Analysis
Management Bits: An Anthology from Reductionist Manager
Crash Dump Analysis for System Administrators and Support Engineers
New Magazines:
Debugged! MZ/PE: MagaZine for/from Practicing Engineers
New Books:
Introduction to Pattern-Driven Software Problem Solving
Memory Dump Analysis Anthology: Color Supplement for Volumes 4-5
Windows Debugging Notebook: Essential User Space WinDbg Commands
Memory Dump Analysis Anthology, Volume 5
Memory Dump Analysis Anthology, Volume 4
Memory Dump Analysis Anthology: Color Supplement for Volumes 1-3
Memory Dump Analysis Anthology, Volume 3
First Fault Software Problem Solving: A Guide for Engineers, Managers and Users
x64 Windows Debugging: Practical Foundations
Also available:
Windows Debugging: Practical Foundations
DLL List Landscape: The Art from Computer Memory Space
Dumps, Bugs and Debugging Forensics: The Adventures of Dr. Debugalov
WinDbg: A Reference Poster and Learning Cards
Memory Dump Analysis Anthology, Volume 2
Memory Dump Analysis Anthology, Volume 1
New Children's Book:
September 4th, 2009 at 3:15 pm
[…] gone wrong after the return from KiCallbackReturn. On x86 systems this is an IDT entry (2b). See an example output I did while writing down notes on Windows Internals. Windows NT/2000 Native API Reference states […]