Re: The Complete Debugging Guide to Stop 0x124
The Complete Debugging Guide to Stop 0x124 - Part 3
In the previous two parts, we examined error packets and error records, now we will begin to discuss the debugging methodology involved with a Stop 0x124 bugcheck, and how to gather useful debugging information from the dump file using WinDbg. I've split this final part into two sections: processor type errors and PCIe type errors, since these are both the most common errors you'll experience when debugging a Stop 0x124 bugcheck.
Processor Type Errors:
Upon loading the dump file into WinDbg, you will be greeted with the following parameters:
Code:
BugCheck 124, {0, fffffa80080d2028, f6000d80, 40150}
Probably caused by : GenuineIntel
The first parameter is the type of error source as discussed in Part 1. As mentioned previously, it is stored within the enumeration called
_WHEA_ERROR_SOURCE_TYPE, and from looking at the value of the parameter we know that the error source type was a Machine Check Exception (MCE). A MCE is a troubleshooting mechanism used by the processor to report hardware errors to the operating system. It can be used to report a wide variety of errors, including cache errors, bus errors and memory errors. The most common from my experience is the that MCE reports cache errors.
The second parameter is the address of the error record, which as explained in Part 2, is represented by
_WHEA_ERROR_RECORD. This is the most important parameter of both of the bugcheck types. We will be using the
!errrec extension to dump this structure and examine the sections which were also discussed in Part 2.
The third and fourth parameters are the higher and lower bits of the
MCi_STATUS registers, which do not have any significant additional debugging value, apart from self interest of the CPU architecture. If you wish, you can dump the contents in WinDbg using the following:
Code:
0: kd> dt hal!_MCi_STATUS
+0x000 McaErrorCode : Uint2B
+0x002 ModelErrorCode : Uint2B
+0x004 OtherInformation : Pos 0, 23 Bits
+0x004 ActionRequired : Pos 23, 1 Bit
+0x004 Signalling : Pos 24, 1 Bit
+0x004 ContextCorrupt : Pos 25, 1 Bit
+0x004 AddressValid : Pos 26, 1 Bit
+0x004 MiscValid : Pos 27, 1 Bit
+0x004 ErrorEnabled : Pos 28, 1 Bit
+0x004 UncorrectedError : Pos 29, 1 Bit
+0x004 StatusOverFlow : Pos 30, 1 Bit
+0x004 Valid : Pos 31, 1 Bit
+0x000 QuadPart : Uint8B
You'll have to dump the other values using the
.formats command and then comparing the
MCi_STATUS structure to the bit values.
I've highlighted the GenuineIntel string since some users make the mistake of assuming automatically that the processor is at fault, and this is simply not true. The string is used to identify if the system is using a real Intel processor. For informational purposes, the string can be found in the following structure:
Code:
0: kd> dt nt!_KPRCB -y VendorString
+0x4bb8 VendorString : [13] UChar
From this particular example, we can find the address of the PRCB by using the
!prcb extension and then using the given address on the above mentioned structure.
Code:
0: kd> !prcb
PRCB for Processor 0 at fffff780ffff0000:
Current IRQL -- 15
Threads-- Current fffffa8007618b50 Next 0000000000000000 Idle fffff8000345fcc0
Processor Index 0 Number (0, 0) GroupSetMember 1
Interrupt Count -- 000b8afa
Times -- Dpc 00000100 Interrupt 00000023
Kernel 0002724c User 00000698
Code:
0: kd> dt nt!_KPRCB -y VendorString fffff780ffff0000
+0x4bb8 VendorString : [13] "GenuineIntel"
Okay, we have now established the meaning of the parameters, and have discovered that error was reported the processor through MCE. We will now need to dump the error record.
Code:
0: kd> !errrec fffffa80080d2028
===============================================================================
Common Platform Error Record @ fffffa80080d2028
-------------------------------------------------------------------------------
Record Id : 01d090ac66cc4cb7
Severity : Fatal (1)
Length : 928
Creator : Microsoft
Notify Type : Machine Check Exception
Timestamp : 5/17/2015 15:10:51 (UTC)
Flags : 0x00000000
===============================================================================
Section 0 : Processor Generic
-------------------------------------------------------------------------------
Descriptor @ fffffa80080d20a8
Section @ fffffa80080d2180
Offset : 344
Length : 192
Flags : 0x00000001 Primary
Severity : Fatal
Proc. Type : x86/x64
Instr. Set : x64
Error Type : Cache error
Operation : Instruction Execute
Flags : 0x00
Level : 0
CPU Version : 0x00000000000106e5
Processor ID : 0x0000000000000000
===============================================================================
Section 1 : x86/x64 Processor Specific
-------------------------------------------------------------------------------
Descriptor @ fffffa80080d20f0
Section @ fffffa80080d2240
Offset : 536
Length : 128
Flags : 0x00000000
Severity : Fatal
Local APIC Id : 0x0000000000000000
CPU Id : e5 06 01 00 00 08 10 00 - fd e3 98 00 ff fb eb bf
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
Proc. Info 0 @ fffffa80080d2240
===============================================================================
Section 2 : x86/x64 MCA
-------------------------------------------------------------------------------
Descriptor @ fffffa80080d2138
Section @ fffffa80080d22c0
Offset : 664
Length : 264
Flags : 0x00000000
Severity : Fatal
Error : ICACHEL0_IRD_ERR (Proc 0 Bank 2)
Status : 0xf6000d8000040150
Address : 0x00000000004b6990
Misc. : 0x0000000000000000
The most important section is
Section 2: x86/x64 MCA, since this section contains data specific to the data which the MCE would have reported to WHEA. We that error severity was fatal, thus leading to the creation of the bugcheck to begin with. I'll go back to Section 0 in a moment. In Section 2, the Error field contains a mnemonic to type of error which is shown in Section 0. The mnemonic can be deciphered using the Intel processor documentation from following page
2352.
There is 4 different error classifications if you don't consider the generic processor error type. These error classifications come to form what is known as a compound error code. In our example I've highlighted the sections which can vary and take different values depending upon the situation.
The current compound error classifications are:
| Type | Interpretation |
| Generic Cache Hierarchy | Generic Cache Hierarchy Error |
| TLB Errors | {TT}TLB{LL}_ERR |
| Memory Controller Errors | {MMM}_CHANNEL_{CCCC}_ERR |
| Cache Hierarchy Errors | {TT}CACHE{LL}_{RRRR}_ERR |
| Bus and Interconnect Errors | BUS{LL}_{PP}_{RRRR}_{II}_{T}_ERR |
I've taken
Table 15-9 (
Section 15.9.2) from the Intel documentation and cut it down into two sections, for our example we will be looking at the Cache Hierarchy Errors. Just to clarify, when dumping the error record and looking at the CPU mnemonic, attempt to decipher which error interpretation should be applied so your able to investigate the cause of the error in greater depth. The following mnemonics have been copied from the Intel documentation, I've added the section numbers if you wish to check yourself.
The {TT} variable is known as the
Transaction Type (
Section 15.9.2.2) and can take the following values:
- I = Instruction
- D = Data
- G = Generic
In our particular type, the transaction type was an instruction, so we know that the error was based around the execution of some instruction.
The {LL} variable is known as the
Level (Level of the Memory Hierarchy (
Section 15.9.2.3)) and points to the type of cache which has experienced the error condition. It can take the following values:
- L0 = Level 0
- L1 = Level 1
- L2 = Level 2
- LG = Level Generic
The {RRRR} is known as the
Request Type (
Section 15.9.2.4) field and indicates the type of instruction or action which was being carried out at the time of the error. The variable can take the following values:
- ERR = Generic Error
- RD = Generic Read
- WR = Generic Write
- DRD = Data Read
- DWR = Data Write
- IRD = Instruction Fetch
- PREFETCH = Prefetch
- EVICT = Eviction
- SNOOP = Snoop
I will quickly provide the meanings of the other sub-fields to save having to trawl through the Intel documentation. The {MMM} and {CCCC} fields primarily apply to Memory Controller errors. {MMM} is a 3-bit field called the
Memory Transaction Type, whereas, {CCCC} is a 4-bit field for
Channels. The memory controller error mnemonics can be found in
Section 15.9.2.5.
The {MMM} field has the meanings of:
- GEN = Generic undefined request
- RD = Memory Read Error
- WR = Memory Write Error
- AC = Address/Command Error
- MS = Memory Scrubbing Error
The {CCCC} field has one meaning which is CHN corresponds to the Channel Number.
Bus and Interconnect errors have three additional fields called {PP} for
Participation; {T} for
Timeout and {II} for
I/O or
Memory. The bus and interconnect error mnemonics can be found in
Section 15.9.2.6.
{PP} defines how the processor participated within the request, and thus:
- SRC = Local processor originated request
- RES = Local processor responded to the request
- OBS = Local processor observed the error as a third party
{T} defines if the processor requested for a timeout of the error or not:
- TIMEOUT = Request timed out
- NOTIMEOUT = Request didn't time out
{II} defines the processor bus asked for memory access or I/O access.
- M = Memory Access
- I/O = IO
We have examined the error condition and have a good understanding of what the error is pertains to, however, we will need to gather some general hardware information to either check for patches or to provide greater troubleshooting information to the hardware manufacturer. There are several WinDbg extensions which enable us to achieve this.
Code:
2: kd> !sysinfo machineid
Machine ID Information [From Smbios 2.7, DMIVersion 39, Size=3456]
BiosMajorRelease = 4
BiosMinorRelease = 6
BiosVendor = American Megatrends Inc.
BiosVersion = 1005
BiosReleaseDate = 10/11/2012
SystemManufacturer = System manufacturer
SystemProductName = System Product Name
SystemFamily = To be filled by O.E.M.
SystemVersion = System Version
SystemSKU = SKU
BaseBoardManufacturer = ASUSTeK COMPUTER INC.
BaseBoardProduct = P8H77-M LE
BaseBoardVersion = Rev X.0x
The
!sysinfo machineid extension can give motherboard and BIOS information, from here I would be able to check the motherboard documentation to ensure that the hardware is compatible and if any patches have been released to resolve any issues the user may be experiencing.
Code:
2: kd> !sysinfo cpuspeed
CPUID: "Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz"
MaxSpeed: 3200
CurrentSpeed: 3192
The
!sysinfo cpuspeed extension enables us to iinvestigate the clockspeed of the processor and if the user has been overclocking their processor. As commonly stated, overclocking can use system instablity and produce excessive heat production which could be affecting the normal operation of the system.
Code:
2: kd> !sysinfo cpuinfo
[CPU Information]
~MHz = REG_DWORD 3192
Component Information = REG_BINARY 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
Configuration Data = REG_FULL_RESOURCE_DESCRIPTOR ff,ff,ff,ff,ff,ff,ff,ff,0,0,0,0,0,0,0,0
Identifier = REG_SZ Intel64 Family 6 Model 58 Stepping 9
ProcessorNameString = REG_SZ Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz
Update Signature = REG_BINARY 0,0,0,0,12,0,0,0
Update Status = REG_DWORD 2
VendorIdentifier = REG_SZ GenuineIntel
MSR8B = REG_QWORD 1200000000
The
!sysinfo cpuinfo extension provides some greater depth into the processor family and model, which is great when reporting a bug to Intel or AMD, since they will be to investigate the issue further and provide any insight into if the error is specific to a certain processor type. You may also noticed that I'm using a different dump file from previous part of this tutorial too!
The
!sysinfo microcode provides similar information to the previous extension:
Code:
2: kd> !sysinfo cpumicrocode
Initial Microcode Version: 00000012:00000000
Cached Microcode Version: 00000012:00000000
Processor Family: 06
Processor Model: 3a
Processor Stepping: 09
Again, simply as personal preference, you will wish to dump the model information about all the processors on the system with
!cpuinfo:
Code:
2: kd> !cpuinfo
CP F/M/S Manufacturer MHz PRCB Signature MSR 8B Signature Features
0 6,58,9 GenuineIntel 3192 0000001200000000 21193ffe
1 6,58,9 GenuineIntel 3192 0000001200000000 21193ffe
2 6,58,9 GenuineIntel 3192 0000001200000000 21193ffe
3 6,58,9 GenuineIntel 3192 0000001200000000 21193ffe
Cached Update Signature 0000001200000000
Initial Update Signature 0000001200000000
Alternatively, you could use
!cpuid which provides the exact same information:
Code:
2: kd> !cpuid
CP F/M/S Manufacturer MHz
0 6,58,9 GenuineIntel 3192
1 6,58,9 GenuineIntel 3192
2 6,58,9 GenuineIntel 3192
3 6,58,9 GenuineIntel 3192
You can gather temperature information about the system through the use
!tz and
!tzinfo extensions, I won't directly discuss the purpose of thermal zones and how they work in this tutorial since it would needlessly go out of scope and produce another page of writing. You can find more information about thermal zones in the ACPI documentation or through this
discussion thread created by myself and
Patrick when we first discovered the extensions.
Code:
2: kd> !tz
0 - ThermalZone @ 0xfffffa8004073310
State: Read Flags: 0x00000002 Initialized
Mode: Active PendingMode: Active
ActivePoint: 0x00000002 PendingActivePoint: 0x00000002
Throttle: 0x00000064
SampleRate: 0x00000000 ThrottleReasons: 0
LastTime: 0x0000000000000000 LastTemp: 0x00000000 (0.0K)
PassiveTimer: 0xfffffa8004073340
PassiveDpc: 0xfffffa8004073380
OverThrottled: 0xfffffa80040733c0
Irp: 0xfffffa8004680c80
Device: 0x00000000
Thermal Info: 0xfffffa80040733e0
1 - ThermalZone @ 0xfffffa8003679310
State: Read Flags: 0x00000002 Initialized
Mode: Active PendingMode: Active
ActivePoint: 0x00000000 PendingActivePoint: 0x00000000
Throttle: 0x00000064
SampleRate: 0x00000000 ThrottleReasons: 0
LastTime: 0x0000000000000000 LastTemp: 0x00000000 (0.0K)
PassiveTimer: 0xfffffa8003679340
PassiveDpc: 0xfffffa8003679380
OverThrottled: 0xfffffa80036793c0
Irp: 0xfffffa8004074310
Device: 0x00000000
Thermal Info: 0xfffffa80036793e0
The
!tzinfo extension provides information about a specific thermal zone:
Code:
2: kd> !tzinfo 0xfffffa80036793e0
ThermalInfo @ 0xfffffa80036793e0
Stamp: 0x00000007 Constant1: 0x00000001 Constant2: 0x00000005
Period: 0x0000000a ActiveCnt: 0x00000000 AffinityEx: 0xfffffa80036793f0
Current Temperature: 0x00000bd6 (303.0K)
Passive TripPoint Temperature: 0x00000ed0 (379.2K)
Hibernate TripPoint Temperature: 0x00000000 (0.0K)
Critical TripPoint Temperature: 0x00000ed0 (379.2K)
PCIe Type Errors:
As shown before, we are going to dump the error record and then examine the relevant sections. The sections displayed with PCIe crashes are generally more lengthy and complex to understand. I would advise the full use of the PCIe documentation if available.
Code:
3: kd> !errrec 869348d4
===============================================================================
Common Platform Error Record @ 869348d4
-------------------------------------------------------------------------------
Record Id : 01cd07d8bce4740f
Severity : Fatal (1)
Length : 672
Creator : Microsoft
Notify Type : PCI Express Error
Timestamp : 3/22/2012 3:06:44 (UTC)
Flags : 0x00000000
===============================================================================
Section 0 : PCI Express
-------------------------------------------------------------------------------
Descriptor @ 86934954
Section @ 869349e4
Offset : 272
Length : 208
Flags : 0x00000001 Primary
Severity : Recoverable
Port Type : Root Port
Version : 1.1
Command/Status: 0x4010/0x0507
Device Id :
VenId:DevId : 8086:340a
Class code : 030400
Function No : 0x00
Device No : 0x03
Segment : 0x0000
Primary Bus : 0x00
Second. Bus : 0x00
Slot : 0x0000
Dev. Serial # : 0000000000000000
Express Capability Information @ 86934a18
Device Caps : 00008021 Role-Based Error Reporting: 1
Device Ctl : 0107 ur FE NF CE
Dev Status : 0003 ur fe NF CE
Root Ctl : 0008 fs nfs cs
AER Information @ ffffffff86934a54
Uncorrectable Error Status : 00000020 ur ecrc mtlp rof uc ca cto fcp ptlp SD dlp und
Uncorrectable Error Mask : 00000000 ur ecrc mtlp rof uc ca cto fcp ptlp sd dlp und
Uncorrectable Error Severity : 00062010 ur ecrc MTLP ROF uc ca cto FCP ptlp sd DLP und
Correctable Error Status : 00000000 adv rtto rnro dllp tlp re
Correctable Error Mask : 00000000 adv rtto rnro dllp tlp re
Caps & Control : 00000005 ecrcchken ecrcchkcap ecrcgenen ecrcgencap FEP
Header Log : 00000000 00000000 00000000 00000000
Root Error Command : 00000000 fen nfen cen
Root Error Status : 00000000 MSG# 00 fer nfer fuf mur ur mcr cer
Correctable Error Source ID : 00,00,00
Correctable Error Source ID : 00,00,00
===============================================================================
Section 1 : Processor Generic
-------------------------------------------------------------------------------
Descriptor @ 8693499c
Section @ 86934ab4
Offset : 480
Length : 192
Flags : 0x00000000
Severity : Informational
Proc. Type : x86/x64
Instr. Set : x86
CPU Version : 0x00000000000106a5
Processor ID : 0x0000000000000006
Section 0 of the error record is the only important section of the error record with this form of bugcheck. I'll start with identifying the device of the bugcheck using the Vendor ID and Device ID fields. The bugcheck indicates the error occurred at the Root Port, and from the
PCI Database, we know that the device was the
Intel I/O Hub PCIe Root Port. Unfortunately, this information is far too generic and doesn't point to the exact cause of the bugcheck. From here, we would need to begin checking the PCIe devices which are connected to the system and how they interact with the other components.
To gather more information regarding the error, we need to investigate the meanings of the error codes shown in the AER; it is important to remember that we will be using the
_PCI_EXPRESS_ROOTPORT_AER_CAPABILITY structure. The Uncorrectable Error Status is presented by the _PCI_EXPRESS_UNCORRECTABLE_ERROR_STATUS structure, which contains the bitfields for the error codes shown in the register. If we dump the this structure, then we can see that the captialised letters correspond to the bitfields which have been set to true.
Code:
3: kd> dt pci!_PCI_EXPRESS_UNCORRECTABLE_ERROR_STATUS
+0x000 Undefined : Pos 0, 1 Bit
+0x000 Reserved1 : Pos 1, 3 Bits
+0x000 DataLinkProtocolError : Pos 4, 1 Bit
+0x000 SurpriseDownError : Pos 5, 1 Bit
+0x000 Reserved2 : Pos 6, 6 Bits
+0x000 PoisonedTLP : Pos 12, 1 Bit
+0x000 FlowControlProtocolError : Pos 13, 1 Bit
+0x000 CompletionTimeout : Pos 14, 1 Bit
+0x000 CompleterAbort : Pos 15, 1 Bit
+0x000 UnexpectedCompletion : Pos 16, 1 Bit
+0x000 ReceiverOverflow : Pos 17, 1 Bit
+0x000 MalformedTLP : Pos 18, 1 Bit
+0x000 ECRCError : Pos 19, 1 Bit
+0x000 UnsupportedRequestError : Pos 20, 1 Bit
+0x000 Reserved3 : Pos 21, 11 Bits
+0x000 AsULONG : Uint4B
Since the Suprise Down (
SD) error bitfield is the also one which has been set, then we can investigate further into what a exactly a Surprise Down error is. In short, it indicates a loss of connection between two devices, although, I will give a slightly more detailed defintion with the use of the PCIe documentation. I've added the section numbers for reference.
A Surprise Down error occurs when a
TLP (Transaction Layer Protocol) request packet is sent numerous times to a device across a link, and then device doesn't respond positively. TLP's are similar to IRPs and are present within the
Transaction Layer (
Section 2) of the PCIe topology, which is responsible for issuing and responding to TLPs.
For those experienced with debugging, you can imagine this situation as a Stop 0x9F, a IRP is sent but becomes stuck for some unknown reason. Once a threshold can be met, then the link is considered to be inactive or malfunctioning and thus a bugcheck is raised to alert the operating system of this error. The best methodology for this type of error would be to investigate the connections of the devices on the motherboard; check for any loosely seated cards and dust which may have built up inside the slots.
Moreover, simply as a matter of interest, the Bus Number, Device Number and Function Number are used to map a device into the
PCI Configuration Space. We use can the
!pci extension to view such information, but please note that you will require a live debugging session with a x86 computer.
Code:
lkd> !pci
PCI Segment 0 Bus 0
00:0 1022:1510.00 Cmd[0006:.mb...] Sts[0220:.6...] AMD Host Bridge SubID:1022:1510
01:0 1002:9806.00 Cmd[0407:imb...] Sts[0010:c....] ATI VGA Compatible Controller SubID:103c:3387
01:1 1002:1314.00 Cmd[0006:.mb...] Sts[0010:c....] ATI Class:4:3:0 SubID:103c:3387
04:0 1022:1512.00 Cmd[0004:..b...] Sts[0010:c....] AMD PCI-PCI Bridge 0->0x1-0x1
11:0 1002:4394.00 Cmd[0007:imb...] Sts[0230:c6...] ATI Class:1:6:1 SubID:103c:3387
12:0 1002:4397.00 Cmd[0016:.mb...] Sts[02a0:.6...] ATI USB Controller SubID:103c:3387
12:2 1002:4396.00 Cmd[0016:.mb...] Sts[02b0:c6...] ATI USB2 Controller SubID:103c:3387
13:0 1002:4397.00 Cmd[0016:.mb...] Sts[02a0:.6...] ATI USB Controller SubID:103c:3387
13:2 1002:4396.00 Cmd[0016:.mb...] Sts[02b0:c6...] ATI USB2 Controller SubID:103c:3387
14:0 1002:4385.42 Cmd[0403:im....] Sts[0220:.6...] ATI SMBus Controller SubID:103c:3387
14:2 1002:4383.40 Cmd[0006:.mb...] Sts[0410:c....] ATI Class:4:3:0 SubID:103c:3387
14:3 1002:439d.40 Cmd[000f:imb...] Sts[0220:.6...] ATI ISA Bridge SubID:103c:3387
14:4 1002:4384.40 Cmd[0407:imb...] Sts[02a0:.6...] ATI PCI-PCI Bridge 0->0x2-0x2
15:0 1002:43a0.00 Cmd[0007:imb...] Sts[0810:c..A.] ATI PCI-PCI Bridge 0->0x3-0x6
15:1 1002:43a1.00 Cmd[0007:imb...] Sts[0010:c....] ATI PCI-PCI Bridge 0->0x7-0x7
16:0 1002:4397.00 Cmd[0016:.mb...] Sts[02a0:.6...] ATI USB Controller SubID:103c:3387
16:2 1002:4396.00 Cmd[0016:.mb...] Sts[02b0:c6...] ATI USB2 Controller SubID:103c:3387
18:0 1022:1700.43 Cmd[0000:......] Sts[0010:c....] AMD Host Bridge
18:1 1022:1701.00 Cmd[0000:......] Sts[0000:.....] AMD Host Bridge
18:2 1022:1702.00 Cmd[0000:......] Sts[0000:.....] AMD Host Bridge
18:3 1022:1703.00 Cmd[0000:......] Sts[0010:c....] AMD Host Bridge
18:4 1022:1704.00 Cmd[0000:......] Sts[0000:.....] AMD Host Bridge
18:5 1022:1718.00 Cmd[0000:......] Sts[0000:.....] AMD Host Bridge
18:6 1022:1716.00 Cmd[0000:......] Sts[0000:.....] AMD Host Bridge
18:7 1022:1719.00 Cmd[0000:......] Sts[0000:.....] AMD Host Bridge
The first column indicates the device number and the second column shows the function number of that particular device. We can gather even further information using the
!pcitree extension which shows all the devices which have enumerated on the bus:
Code:
lkd> !pcitree
Bus 0x0 (FDO Ext 86688ae0)
(d=0, f=0) 10221510 devext 0x8665cc10 devstack 0x8665cb58 0600 Bridge/HOST to PCI
(d=1, f=0) 10029806 devext 0x8665c738 devstack 0x8665c680 0300 Display Controller/VGA
(d=1, f=1) 10021314 devext 0x866720e8 devstack 0x86672030 0403 Multimedia Device/Unknown Sub Class
(d=4, f=0) 10221512 devext 0x86672c10 devstack 0x86672b58 0604 Bridge/PCI to PCI
Bus 0x1 (FDO Ext 86680d18)
No devices have been enumerated on this bus.
(d=11, f=0) 10024394 devext 0x86672738 devstack 0x86672680 0106 Mass Storage Controller/Unknown Sub Class
(d=12, f=0) 10024397 devext 0x866730e8 devstack 0x86673030 0c03 Serial Bus Controller/USB
(d=12, f=2) 10024396 devext 0x86673c10 devstack 0x86673b58 0c03 Serial Bus Controller/USB
(d=13, f=0) 10024397 devext 0x86673738 devstack 0x86673680 0c03 Serial Bus Controller/USB
(d=13, f=2) 10024396 devext 0x866740e8 devstack 0x86674030 0c03 Serial Bus Controller/USB
(d=14, f=0) 10024385 devext 0x86674c10 devstack 0x86674b58 0c05 Serial Bus Controller/Unknown Sub Class
(d=14, f=2) 10024383 devext 0x86674738 devstack 0x86674680 0403 Multimedia Device/Unknown Sub Class
(d=14, f=3) 1002439d devext 0x866750e8 devstack 0x86675030 0601 Bridge/PCI to ISA
(d=14, f=4) 10024384 devext 0x86675c10 devstack 0x86675b58 0604 Bridge/PCI to PCI
Bus 0x2 (FDO Ext 86685888)
No devices have been enumerated on this bus.
(d=15, f=0) 100243a0 devext 0x86675738 devstack 0x86675680 0604 Bridge/PCI to PCI
Bus 0x3 (FDO Ext 866853e0)
(d=0, f=0) 14e44727 devext 0x86a787c8 devstack 0x86a78710 0280 Network Controller/'Other'
(d=15, f=1) 100243a1 devext 0x8667c0e8 devstack 0x8667c030 0604 Bridge/PCI to PCI
Bus 0x7 (FDO Ext 8668fea8)
(d=0, f=0) 10ec8168 devext 0x86a7dc10 devstack 0x86a7db58 0200 Network Controller/Ethernet
(d=16, f=0) 10024397 devext 0x8667cc10 devstack 0x8667cb58 0c03 Serial Bus Controller/USB
(d=16, f=2) 10024396 devext 0x8667c738 devstack 0x8667c680 0c03 Serial Bus Controller/USB
(d=18, f=0) 10221700 devext 0x8667d0e8 devstack 0x8667d030 0600 Bridge/HOST to PCI
(d=18, f=1) 10221701 devext 0x8667dc10 devstack 0x8667db58 0600 Bridge/HOST to PCI
(d=18, f=2) 10221702 devext 0x8667d738 devstack 0x8667d680 0600 Bridge/HOST to PCI
(d=18, f=3) 10221703 devext 0x8667e0e8 devstack 0x8667e030 0600 Bridge/HOST to PCI
(d=18, f=4) 10221704 devext 0x8667ec10 devstack 0x8667eb58 0600 Bridge/HOST to PCI
(d=18, f=5) 10221718 devext 0x8667e738 devstack 0x8667e680 0600 Bridge/HOST to PCI
(d=18, f=6) 10221716 devext 0x8667f0e8 devstack 0x8667f030 0600 Bridge/HOST to PCI
(d=18, f=7) 10221719 devext 0x8667fc10 devstack 0x8667fb58 0600 Bridge/HOST to PCI
Total PCI Root busses processed = 1
Total PCI Segments processed = 1
The
D represents the device number, the
F represents the function number, and the first block of highlighted charachters indicates the Device ID with the subsequent block of characters being used to show the Vendor ID of the device.
Code:
lkd> !devext 0x8665cc10
PDO Extension, Bus 0x0, Device 0, Function 0.
DevObj 0x8665cb58 Parent FDO DevExt 0x86688ae0
Device State = PciStarted
Vendor ID 1022 (ADVANCED MICRO DEVICES) Device ID 1510
Subsystem Vendor ID 1022 (ADVANCED MICRO DEVICES) Subsystem ID 1510
Header Type 0, Class Base/Sub 06/00 (Bridge/HOST to PCI)
Programming Interface: 00, Revision: 00, IntPin: 00, RawLine 00
Possible Decodes ((cmd & 7) = 7): BMI Capabilities: Ptr =
Logical Device Power State: D0
Device Wake Level: Unspecified
WaitWakeIrp:
Device Requirements structure has changed size. Update extension.
Device Resources structure has changed size. Update extension.
Interrupt Requirement:
Interrupt Resource:
The
!devext extension can provide some additional information about the device, which is useful for debugging purposes. There another field within the error record which I had forgotten to mention, and that is the
Class Code register.
The register is very useful for identifying the type of device which could be causing the problem. The register is divided into three different parts:
Class,
Sub-Class and
Prog. I/F. From our example, we can see that the class is
0x3, the sub-class is
0x4 and the Prog. I/F is
0x0. If we were to check the meanings of these values, then we would reach the conclusion a display controller had reported the error to the operating system.
0x3 is the class number for display controllers, and the sub-class points to general category of display controllers. This makes sense in the context of this dump since the issue lied with a TV tuner card (the dump was previously debugged by
Vir Gnarus). A complete list of PCI Class codes can be found here -
http://wiki.xomb.org/index.php?title=PCI_Class_Codes
I hope this tutorial series given a in-depth insight into the internals of a Stop 0x124 and some of the debugging methodologies we could use to debug such bugchecks. I didn't wish to delve too deeply into the technical details of PCIe and x86/x64 architectures since it would leave the scope of this tutorial and generate too much 'fluff' and 'filler'.
I hope you enjoyed this tutorial, and if you wish to suggest any amendments or corrections then please comment/post below. Moreover, please note that I've a list of reference material regarding PCI-e and CPU architecture in this thread -
Hardware Architecture Documentation Links
