New
#11
This website explains more about the theory about BSODs and how they can occur, with explanations about interrupts etc. It seems to explain some of the more 'advanced' extensions and commands for BSOD analysis.
BSOD Tutorials and Information Links
-
-
New #12
Thanks, BlueRobot. That website is a treasure trove of knowledge to dive into. I have been interested in saving up for the author's Memory Dump Analysis Anthology, which basically shoves all of the website stuff into an easy-to-navigate book form.
I'd like to explain each command he presented in the article for the laymans:
!pcr - Every processor is required to dump its information - everything ranging from register values to current context to processor id and state info - and continue updating this information into a particular data structure called the PCR or Processor Control Region. It's what keeps everything nice and tidy for the operations of a particular logical processor (logical processors are made based on processor cores, physical CPUs and if Hyperthreading or some other similar feature is active). !pcr extension dumps this information in an easy-to-read format. Note that every PCR has a subsection called the PRCB or Processor Control Block, which contains the bulk the PCR's info. You can view that with !prcb or by dumping the data structure with symbols, demonstrated below.
dt - Means Display Type which is used to display data types, often which are structures. To keep things orderly, any kind of data that needs to be retained is often done in a type of structure. With the proper symbols, one can dump that structure in a format that can be easily read by human eyes. Give it the symbols to use and the start point of the actual data and it'll parse the data based on the symbols you specified. For example, we'll use the PRCB. The easiest method for this is by merely typing !PRCB:
It can be rather misleading, but the value highlighted is referring to the address of the PRCB structure, not the actual associated processor (which will be the PCR, since the PCR of a processor is the structure that represents that processor to Windows). So we just take that value and give it the right symbols, in this case it's _KPRCB.Code:1: kd> !prcb PRCB for Processor 1 at ffdff120: Current IRQL -- 2 Threads-- Current 861d4798 Next 00000000 Idle 807c7800 Processor Index 1 Number (0, 1) GroupSetMember 2 Interrupt Count -- 00000223 Times -- Dpc 00000000 Interrupt 00000000 Kernel 00000224 User 00000000
Understand that Windows kernel stuff names its items in a common nomenclature. For data structures it'll prefix it with an underscore (_) and for kernel-code it'll prefix it with the letter K. Keep this in mind with determining the symbols. So as an extra example, for the PCR structure it'd be _KPCR. If you want to know the exact structure names for other stuff, the WDK has a portion of it called Build Environments that offers public symbols and other extra documentation on all its kernel modules(that's covered publicly, of course). You'll find the symbols in those.
Anyways, let's dump the PRCB using the address and the _KPRCB structure symbols:
Recognize it automagically determined the module you wanted the symbols for were from the nt module. If you need to specify the exact module you have symbols for that you wanna look up, type it in followed by an exclamation mark then the symbol name, kinda like what you would see in a callstack for a thread. For this it'd be nt!_KPRCB instead of just typing _KPRCB for the symbol name in the command.Code:1: kd> dt _KPRCB ffdff120 nt!_KPRCB +0x000 MinorVersion : 1 +0x002 MajorVersion : 1 +0x004 CurrentThread : 0x861d4798 _KTHREAD +0x008 NextThread : (null) +0x00c IdleThread : 0x807c7800 _KTHREAD +0x010 LegacyNumber : 0x1 '' +0x011 NestingLevel : 0 '' +0x012 BuildType : 0 +0x014 CpuType : 6 '' +0x015 CpuID : 1 '' +0x016 CpuStep : 0xe0c +0x016 CpuStepping : 0xc '' +0x017 CpuModel : 0xe '' +0x018 ProcessorState : _KPROCESSOR_STATE +0x338 KernelReserved : [16] 0 +0x378 HalReserved : [16] 0xe100 +0x3b8 CFlushSize : 0x40 +0x3bc CoresPerPhysicalProcessor : 0x2 '' +0x3bd LogicalProcessorsPerCore : 0x1 '' +0x3be PrcbPad0 : [2] "" +0x3c0 MHz : 0x6c4 +0x3c4 CpuVendor : 0x1 '' +0x3c5 GroupIndex : 0x1 '' +0x3c6 Group : 0 +0x3c8 GroupSetMember : 2 +0x3cc Number : 1 +0x3d0 PrcbPad1 : [72] "" +0x418 LockQueue : [17] _KSPIN_LOCK_QUEUE +0x4a0 NpxThread : (null) +0x4a4 InterruptCount : 0x223 +0x4a8 KernelTime : 0x224 +0x4ac UserTime : 0 +0x4b0 DpcTime : 0 +0x4b4 DpcTimeCount : 0 +0x4b8 InterruptTime : 0 +0x4bc AdjustDpcThreshold : 0xd +0x4c0 PageColor : 0xd2 +0x4c4 DebuggerSavedIRQL : 0x2 '' +0x4c5 NodeColor : 0 '' +0x4c6 PrcbPad20 : [2] "" +0x4c8 NodeShiftedColor : 0 +0x4cc ParentNode : 0x83d4a300 _KNODE +0x4d0 SecondaryColorMask : 0x3f +0x4d4 DpcTimeLimit : 0x280 +0x4d8 PrcbPad21 : [2] 0 +0x4e0 CcFastReadNoWait : 0 +0x4e4 CcFastReadWait : 0x57 +0x4e8 CcFastReadNotPossible : 0 +0x4ec CcCopyReadNoWait : 0 +0x4f0 CcCopyReadWait : 0x61 +0x4f4 CcCopyReadNoWaitMiss : 0 +0x4f8 MmSpinLockOrdering : 0n0 +0x4fc IoReadOperationCount : 0n93 +0x500 IoWriteOperationCount : 0n0 +0x504 IoOtherOperationCount : 0n191 +0x508 IoReadTransferCount : _LARGE_INTEGER 0x1276c3 +0x510 IoWriteTransferCount : _LARGE_INTEGER 0x0 +0x518 IoOtherTransferCount : _LARGE_INTEGER 0x41ad +0x520 CcFastMdlReadNoWait : 0 +0x524 CcFastMdlReadWait : 0 +0x528 CcFastMdlReadNotPossible : 0 +0x52c CcMapDataNoWait : 0 +0x530 CcMapDataWait : 0x273 +0x534 CcPinMappedDataCount : 0xf +0x538 CcPinReadNoWait : 0 +0x53c CcPinReadWait : 0x5b +0x540 CcMdlReadNoWait : 0 +0x544 CcMdlReadWait : 0 +0x548 CcLazyWriteHotSpots : 0 +0x54c CcLazyWriteIos : 0 +0x550 CcLazyWritePages : 0 +0x554 CcDataFlushes : 0x38 +0x558 CcDataPages : 0x63 +0x55c CcLostDelayedWrites : 0 +0x560 CcFastReadResourceMiss : 0 +0x564 CcCopyReadWaitMiss : 0xa2 +0x568 CcFastMdlReadResourceMiss : 0 +0x56c CcMapDataNoWaitMiss : 0 +0x570 CcMapDataWaitMiss : 0x24 +0x574 CcPinReadNoWaitMiss : 0 +0x578 CcPinReadWaitMiss : 0x14 +0x57c CcMdlReadNoWaitMiss : 0 +0x580 CcMdlReadWaitMiss : 0 +0x584 CcReadAheadIos : 0x1f +0x588 KeAlignmentFixupCount : 0 +0x58c KeExceptionDispatchCount : 0xb +0x590 KeSystemCalls : 0x4322 +0x594 AvailableTime : 0x2f +0x598 PrcbPad22 : [2] 0 +0x5a0 PPLookasideList : [16] _PP_LOOKASIDE_LIST +0x620 PPNPagedLookasideList : [32] _GENERAL_LOOKASIDE_POOL +0xf20 PPPagedLookasideList : [32] _GENERAL_LOOKASIDE_POOL +0x1820 PacketBarrier : 0 +0x1824 ReverseStall : 0n3 +0x1828 IpiFrame : 0x88722bec Void +0x182c PrcbPad3 : [52] "" +0x1860 CurrentPacket : [3] (null) +0x186c TargetSet : 0 +0x1870 WorkerRoutine : 0x83c4828c void nt!KiFlushTargetSingleTb+0 +0x1874 IpiFrozen : 0 +0x1878 PrcbPad4 : [40] "" +0x18a0 RequestSummary : 0 +0x18a4 SignalDone : (null) +0x18a8 PrcbPad50 : [56] "" +0x18e0 DpcData : [2] _KDPC_DATA +0x1908 DpcStack : 0x807e3000 Void +0x190c MaximumDpcQueueDepth : 0n4 +0x1910 DpcRequestRate : 0 +0x1914 MinimumDpcRate : 3 +0x1918 DpcLastCount : 0xf +0x191c PrcbLock : 0 +0x1920 DpcGate : _KGATE +0x1930 ThreadDpcEnable : 0x1 '' +0x1931 QuantumEnd : 0 '' +0x1932 DpcRoutineActive : 0 '' +0x1933 IdleSchedule : 0 '' +0x1934 DpcRequestSummary : 0n0 +0x1934 DpcRequestSlot : [2] 0n0 +0x1934 NormalDpcState : 0n0 +0x1936 DpcThreadActive : 0y0 +0x1936 ThreadDpcState : 0n0 +0x1938 TimerHand : 0x2cf +0x193c LastTick : 0x2d0 +0x1940 MasterOffset : 0n0 +0x1944 PrcbPad41 : [2] 0 +0x194c PeriodicCount : 0 +0x1950 PeriodicBias : 0 +0x1958 TickOffset : 0 +0x1960 TimerTable : _KTIMER_TABLE +0x31a0 CallDpc : _KDPC +0x31c0 ClockKeepAlive : 0n1 +0x31c4 ClockCheckSlot : 0 '' +0x31c5 ClockPollCycle : 0x64 'd' +0x31c6 PrcbPad6 : [2] "" +0x31c8 DpcWatchdogPeriod : 0n1920 +0x31cc DpcWatchdogCount : 0n1451 +0x31d0 ThreadWatchdogPeriod : 0n0 +0x31d4 ThreadWatchdogCount : 0n0 +0x31d8 KeSpinLockOrdering : 0n0 +0x31dc PrcbPad70 : [1] 0 +0x31e0 WaitListHead : _LIST_ENTRY [ 0x861d14d4 - 0x861d280c ] +0x31e8 WaitLock : 0 +0x31ec ReadySummary : 0 +0x31f0 QueueIndex : 1 +0x31f4 DeferredReadyListHead : _SINGLE_LIST_ENTRY +0x31f8 StartCycles : 0x4`bfc91224 +0x3200 CycleTime : 0x1`3bb032ff +0x3208 HighCycleTime : 1 +0x320c PrcbPad71 : 0 +0x3210 PrcbPad72 : [2] 0 +0x3220 DispatcherReadyListHead : [32] _LIST_ENTRY [ 0x807c5340 - 0x807c5340 ] +0x3320 ChainedInterruptList : (null) +0x3324 LookasideIrpFloat : 0n2147483647 +0x3328 MmPageFaultCount : 0n16258 +0x332c MmCopyOnWriteCount : 0n5 +0x3330 MmTransitionCount : 0n11600 +0x3334 MmCacheTransitionCount : 0n0 +0x3338 MmDemandZeroCount : 0n1300 +0x333c MmPageReadCount : 0n851 +0x3340 MmPageReadIoCount : 0n175 +0x3344 MmCacheReadCount : 0n0 +0x3348 MmCacheIoCount : 0n0 +0x334c MmDirtyPagesWriteCount : 0n0 +0x3350 MmDirtyWriteIoCount : 0n0 +0x3354 MmMappedPagesWriteCount : 0n0 +0x3358 MmMappedWriteIoCount : 0n0 +0x335c CachedCommit : 0x100 +0x3360 CachedResidentAvailable : 0x87 +0x3364 HyperPte : 0x807e3005 Void +0x3368 PrcbPad8 : [4] "" +0x336c VendorString : [13] "GenuineIntel" +0x3379 InitialApicId : 0x1 '' +0x337a LogicalProcessorsPerPhysicalProcessor : 0x2 '' +0x337b PrcbPad9 : [5] "" +0x3380 FeatureBits : 0xa08f3fff +0x3388 UpdateSignature : _LARGE_INTEGER 0x54`00000000 +0x3390 IsrTime : 0 +0x3398 RuntimeAccumulation : 0x6b49d20 +0x33a0 PowerState : _PROCESSOR_POWER_STATE +0x3468 DpcWatchdogDpc : _KDPC +0x3488 DpcWatchdogTimer : _KTIMER +0x34b0 WheaInfo : 0x867dd81c Void +0x34b4 EtwSupport : 0x861f0940 Void +0x34b8 InterruptObjectPool : _SLIST_HEADER +0x34c0 HypercallPageList : _SLIST_HEADER +0x34c8 HypercallPageVirtual : (null) +0x34cc VirtualApicAssist : (null) +0x34d0 StatisticsPage : (null) +0x34d4 RateControl : (null) +0x34d8 Cache : [5] _CACHE_DESCRIPTOR +0x3514 CacheCount : 3 +0x3518 CacheProcessorMask : [5] 2 +0x352c PackageProcessorSet : _KAFFINITY_EX +0x3538 PrcbPad91 : [1] 0 +0x353c CoreProcessorSet : 2 +0x3540 TimerExpirationDpc : _KDPC +0x3560 SpinLockAcquireCount : 0x8d4a8 +0x3564 SpinLockContentionCount : 0x40 +0x3568 SpinLockSpinCount : 0xca8 +0x356c IpiSendRequestBroadcastCount : 0 +0x3570 IpiSendRequestRoutineCount : 0x280c +0x3574 IpiSendSoftwareInterruptCount : 0x8ca +0x3578 ExInitializeResourceCount : 0x99 +0x357c ExReInitializeResourceCount : 2 +0x3580 ExDeleteResourceCount : 0x52 +0x3584 ExecutiveResourceAcquiresCount : 0x82c4 +0x3588 ExecutiveResourceContentionsCount : 0x22 +0x358c ExecutiveResourceReleaseExclusiveCount : 0x629 +0x3590 ExecutiveResourceReleaseSharedCount : 0x7c83 +0x3594 ExecutiveResourceConvertsCount : 5 +0x3598 ExAcqResExclusiveAttempts : 0x4eb +0x359c ExAcqResExclusiveAcquiresExclusive : 0x3d7 +0x35a0 ExAcqResExclusiveAcquiresExclusiveRecursive : 0x10f +0x35a4 ExAcqResExclusiveWaits : 0xb +0x35a8 ExAcqResExclusiveNotAcquires : 5 +0x35ac ExAcqResSharedAttempts : 0x7d71 +0x35b0 ExAcqResSharedAcquiresExclusive : 0x161 +0x35b4 ExAcqResSharedAcquiresShared : 0x78e1 +0x35b8 ExAcqResSharedAcquiresSharedRecursive : 0x32f +0x35bc ExAcqResSharedWaits : 0x17 +0x35c0 ExAcqResSharedNotAcquires : 0 +0x35c4 ExAcqResSharedStarveExclusiveAttempts : 0x6d +0x35c8 ExAcqResSharedStarveExclusiveAcquiresExclusive : 1 +0x35cc ExAcqResSharedStarveExclusiveAcquiresShared : 0x69 +0x35d0 ExAcqResSharedStarveExclusiveAcquiresSharedRecursive : 3 +0x35d4 ExAcqResSharedStarveExclusiveWaits : 0 +0x35d8 ExAcqResSharedStarveExclusiveNotAcquires : 0 +0x35dc ExAcqResSharedWaitForExclusiveAttempts : 0 +0x35e0 ExAcqResSharedWaitForExclusiveAcquiresExclusive : 0 +0x35e4 ExAcqResSharedWaitForExclusiveAcquiresShared : 0 +0x35e8 ExAcqResSharedWaitForExclusiveAcquiresSharedRecursive : 0 +0x35ec ExAcqResSharedWaitForExclusiveWaits : 0 +0x35f0 ExAcqResSharedWaitForExclusiveNotAcquires : 0 +0x35f4 ExSetResOwnerPointerExclusive : 0 +0x35f8 ExSetResOwnerPointerSharedNew : 2 +0x35fc ExSetResOwnerPointerSharedOld : 0 +0x3600 ExTryToAcqExclusiveAttempts : 0 +0x3604 ExTryToAcqExclusiveAcquires : 0 +0x3608 ExBoostExclusiveOwner : 1 +0x360c ExBoostSharedOwners : 0 +0x3610 ExEtwSynchTrackingNotificationsCount : 0 +0x3614 ExEtwSynchTrackingNotificationsAccountedCount : 0 +0x3618 Context : 0x807c2138 _CONTEXT +0x361c ContextFlags : 0x10017 +0x3620 ExtendedState : 0x807f3000 _XSAVE_AREA
Notice the info here is a lot more verbose than from the !PRCB command. There are some substructures lying in here (which, btw, the PRCB is a substructure of the PCR structure). Navigate to those the same way you would with this one, using their appropriate offsets for the starting address. Example would be the Processor State substructure, which is represented by _KPROCESSOR_STATE symbol. It's at offset 0x018, so add 18 to the previous address we used and we'll have the correct address:
This is also split into two substructures. Follow those in the same manner.Code:1: kd> dt _KPROCESSOR_STATE ffdff120+18 nt!_KPROCESSOR_STATE +0x000 ContextFrame : _CONTEXT +0x2cc SpecialRegisters : _KSPECIAL_REGISTERS
There's actually a more simplified and less meticulous method to perusing data structures than this, but I gave this example to show how data structures work and how they can be navigated without such luxuries. If you wanna know the easier ways, look at the Windbg manual for the dt command.
ln - Means to list nearest symbol. Give it an address and it'll look up if any module data sits in that address, and if so, it'll give the nearest symbols for it, if available. Good to determine if a portion of memory is a function, data structure, etc.
dds - One of the very many 'd' commands to dump raw memory out. With this one, it means 'dump doubles with symbols'. That means dump the data and show it as double words (4 bytes, or 32 bits) and check each double word if it's a pointer, and if so, check the symbols for the data it's pointing too and display those if present. A better option typically will be dps, which is the same but it will dump the data in a format that's either double word or quad word, depending if the processor architecture of the system is 32-bit or 64-bit, respectively. Very useful stuff in dumping raw thread stacks.
idt - Means Interrupt Dispatch Table. Each processor (logical) has its own dispatch table filled in by drivers and the like so that if a specific interrupt vector is hit in code, it'll divert code execution to the function associated with that interrupt vector.
Phew, that was quite a bit! Hope any of it helps. If still confused on some of the descriptions, I'll be happy to simplify further.
-
New #13
Thanks Vir, very good explanations of some of the commands and extensions, will be very helpful!
-
-
New #15
I've posted it
then what should i do next?
thank you
-
New #16
saiko neru this is a BSOD information thread and sub-forum, please start a new thread in this section: BSOD Help and Support - Windows 7 Help Forums
-
New #17
Sorry I'm resurrecting a old thread, but I'm going to post a bunch of new links:
Gustavo Duarte
ListServer/Forum and OSR Online - The Home Page for Windows Driver Developers
Analyze -v
CodeMachine Inc. - Consulting and Training
MSDN Blogs
Defrag Tools | Channel 9
MSDN Library <-- Driver API's and Concepts
http://www.opening-windows.com/techa...internals2.htm <-- APC Internals
BSODTutorials <-- My Blog
http://blogs.technet.com/b/markrussinovich/
-
New #18
KernelMode.info ? Index page <-- Forum
The forum seems to be quiet, but the users ask/answer more advanced questions about operating system internals, debugging and reverse engineering. It seems to be mostly security oriented.
-
New #19
Forgot about this one - Expanded Main Page - OSDev Wiki
-
New #20
Great links on data alignment (Microsoft and IBM) - Data alignment: Straighten up and fly right and Windows Data Alignment on IPF, x86, and x86-64
Quote
Related Discussions