## Debugging Stop 0xC9 – The Tale of the Missing Device Object

One of the users at Sysnative Forums posted in our BSOD Academy regarding a question about a Driver Verifier induced bugcheck and why is it blaming the Windows kernel. I believe that this may have been due to the fact which call Driver Verifier believed to where the crash had occurred. Although, while investigating this, I found something rather interesting. Read on to find out more!

The bugcheck was a Stop 0xC9, these are very straight forward to debug and typically the faulty driver string will have been displayed within the bugcheck message.

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
The IO manager has caught a misbehaving driver.
Arguments:
Arg1: 000000000000024d, A driver has passed an invalid device object to a function that requires a PDO.
Arg2: fffff8007421a51a, The address in the driver's code where the error was detected.
Arg4: 0000000000000000, Device object address.

At first glance, we can clearly see that a null device object must have been passed to a function which required it. Conveniently, the bugcheck even provides the address of the function within the second parameter. At this point you may be thinking, so what? We have all the information conveniently provided to us, so why are we worried? Well, the address of the third parameter is not actually an IRP!

15: kd> !irp ffffb383dffedd40
IRP signature does not match, probably not an IRP. Use any flag to force.

Okay, that’s odd, why is the debugger stating that the address is an IRP? I do not know the answer to that question, but I would assume that it may be a bug with how this bugcheck is produced.

We know that the third parameter will be no help to us now, so let’s try the second parameter and see which function call required our missing device object.

15: kd> ln fffff8007421a51a
Browse module
Set bu breakpoint

(fffff8007421a500) nt!VerifierIoGetDeviceProperty+0x1a | (fffff8007421a530) nt!VerifierIoGetDevicePropertyData

Okay, we’ve now found where the system crashed. IoGetDeviceProperty takes a pointer to a device object as its first parameter, and the bugcheck states this in the first parameter.

If we dump the call stack, we can see what driver called the function mentioned.

15: kd> knL
00 fffffc89fb577148 fffff800742186e3 nt!KeBugCheckEx
01 fffffc89fb577150 fffff8007421f947 nt!VerifierBugCheckIfAppropriate+0xdf
02 fffffc89fb577190 fffff8007421f6f6 nt!ViErrorFinishReport+0x117
03 fffffc89fb5771f0 fffff80073b4ba2c nt!VfErrorReport8+0x66
04 fffffc89fb5772a0 fffff80074049b8e nt!PpvUtilFailDriver+0x2c
05 fffffc89fb5772d0 fffff8007421a51a nt!IoGetDeviceProperty+0x1e01ee
06 fffffc89fb5773d0 fffff806cbb92fa4 nt!VerifierIoGetDeviceProperty+0x1a
07 fffffc89fb577410 ffffb383ed692f00 ctxusbm+0x12fa4
08 fffffc89fb577418 0000000000000000 0xffffb383ed692f00

We can disassemble backwards using the return address, this will show us the parameters which were made before calling IoGetDeviceProperty.

15: kd> ub fffff8007421a51a L15
nt!VerifierIoGetDeviceObjectPointer:
fffff8007421a4e0 4883ec38 sub rsp,38h
fffff8007421a4e4 488b051d890500 mov rax,qword ptr [nt!pXdvIoGetDeviceObjectPointer (fffff80074272e08)]
fffff8007421a4eb e8c09685ff call nt!guard_dispatch_icall (fffff80073a73bb0)
fffff8007421a4f0 4883c438 add rsp,38h
fffff8007421a4f4 c3 ret
fffff8007421a4f5 cc int 3
fffff8007421a4f6 cc int 3
fffff8007421a4f7 cc int 3
fffff8007421a4f8 cc int 3
fffff8007421a4f9 cc int 3
fffff8007421a4fa cc int 3
fffff8007421a4fb cc int 3
fffff8007421a4fc cc int 3
fffff8007421a4fd cc int 3
fffff8007421a4fe cc int 3
fffff8007421a4ff cc int 3
nt!VerifierIoGetDeviceProperty:
fffff8007421a500 4883ec38 sub rsp,38h
fffff8007421a504 4c8b542460 mov r10,qword ptr [rsp+60h]
fffff8007421a509 488b05c8880500 mov rax,qword ptr [nt!pXdvIoGetDeviceProperty (fffff80074272dd8)]
fffff8007421a510 4c89542420 mov qword ptr [rsp+20h],r10
fffff8007421a515 e8969685ff call nt!guard_dispatch_icall (fffff80073a73bb0)

Okay, we can now see a call to IoGetDeviceObjectPointer, which returns a pointer to the device object which we are trying to query. Unfortunately, since this is a Minidump, much of the registers haven’t been saved and further disassembly is very difficult. Although, based on the information reported in the bugcheck parameters, we can safely assume that a null pointer was likely returned which lead to our bugcheck.

But, what is the third parameter? Let’s find out!

I’ll presume that you will have the PDE debugger extension installed. If not, then it can be found here.

15: kd> !dpx
Start memory scan : 0xfffffc89fb577148 (\$csp)
End memory scan : 0xfffffc89fb578000 (Kernel Stack Base)

rsp : 0xfffffc89fb577148 : 0xfffff800742186e3 : nt!VerifierBugCheckIfAppropriate+0xdf
r12 : 0xffffb383ed698ff0 : !da "3333333333333333"
0xfffffc89fb577148 : 0xfffff800742186e3 : nt!VerifierBugCheckIfAppropriate+0xdf
0xfffffc89fb577160 : 0xfffff8007421a51a : nt!VerifierIoGetDeviceProperty+0x1a
0xfffffc89fb577188 : 0xfffff8007421f947 : nt!ViErrorFinishReport+0x117
0xfffffc89fb5771a8 : 0xfffff8007426a8c0 : nt!ViErrorDescriptions
0xfffffc89fb5771c0 : 0xfffff8007421a51a : nt!VerifierIoGetDeviceProperty+0x1a
0xfffffc89fb5771c8 : 0xfffff80074205b10 : !da ""A driver has passed an invalid device object to a function that requires.a PDO.""
0xfffffc89fb5771e0 : 0xfffff8007421a51a : nt!VerifierIoGetDeviceProperty+0x1a
0xfffffc89fb5771e8 : 0xfffff8007421f6f6 : nt!VfErrorReport8+0x66
0xfffffc89fb577220 : 0x41746972706c7543 : !da ""CulpritAddress = FFFFF8007421A51A, DeviceObject = FFFFB383DFFEDD40..""
0xfffffc89fb577228 : 0x3d20737365726464 : !da ""ddress = FFFFF8007421A51A, DeviceObject = FFFFB383DFFEDD40..""
0xfffffc89fb577230 : 0x3038464646464620 : !da "" FFFFF8007421A51A, DeviceObject = FFFFB383DFFEDD40..""
0xfffffc89fb577238 : 0x3135413132343730 : !da ""07421A51A, DeviceObject = FFFFB383DFFEDD40..""
0xfffffc89fb577240 : 0x6369766544202c41 : !da ""A, DeviceObject = FFFFB383DFFEDD40..""
0xfffffc89fb577248 : 0x207463656a624f65 : !da ""eObject = FFFFB383DFFEDD40..""
0xfffffc89fb577250 : 0x334246464646203d : !da ""= FFFFB383DFFEDD40..""
0xfffffc89fb577258 : 0x4444454646443338 : !da "83DFFEDD40.."
0xfffffc89fb577298 : 0xfffff80073b4ba2c : nt!PpvUtilFailDriver+0x2c

We can now see that several strings were passed to the stack which illustrate what the parameters are. This was carried out by VfUtilDbgPrint function.

15: kd> ub fffff8007421f6f6
nt!VfErrorReport8+0x4a:
fffff8007421f6da 780a js nt!VfErrorReport8+0x56 (fffff8007421f6e6)
fffff8007421f6dc 488d4c2430 lea rcx,[rsp+30h]
fffff8007421f6e1 e87e289bff call nt!VfUtilDbgPrint (fffff80073bd1f64)
fffff8007421f6e6 4533c9 xor r9d,r9d
fffff8007421f6e9 4c8bc6 mov r8,rsi
fffff8007421f6ec 488bd7 mov rdx,rdi
fffff8007421f6ef 8bcb mov ecx,ebx
fffff8007421f6f1 e83a010000 call nt!ViErrorFinishReport (fffff8007421f830)
15: kd> u nt!VfUtilDbgPrint
nt!VfUtilDbgPrint:
fffff80073bd1f64 4c8bdc          mov     r11,rsp
fffff80073bd1f67 49894b08        mov     qword ptr [r11+8],rcx
fffff80073bd1f6b 49895310        mov     qword ptr [r11+10h],rdx
fffff80073bd1f6f 4d894318        mov     qword ptr [r11+18h],r8
fffff80073bd1f73 4d894b20        mov     qword ptr [r11+20h],r9
fffff80073bd1f77 4883ec38        sub     rsp,38h
fffff80073bd1f7b 4533c0          xor     r8d,r8d
fffff80073bd1f7e c644242801      mov     byte ptr [rsp+28h],1

The r9 register contains the third parameter of our bugcheck.

To verify that this is in fact a device object, can we dump the address with the !devobj extension.

15: kd> !devobj ffffb383dffedd40
Device object (ffffb383dffedd40) is for:
\Driver\USBHUB3 DriverObject ffffb383da54fc80
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00002044
SecurityDescriptor ffffa1054d2532e0 DevExt ffffb383e82dfbe0 DevObjExt ffffb383dffedeb8
ExtensionFlags (0x80000000) DOE_DESIGNATED_FDO
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffffb383e8c90e00 Name paged out
Device queue is not busy.

Mystery solved!

And based on our findings and what the call stack tells us, we can presume that the third-party driver (Citrix USB) is the most likely culprit of the crash.

15: kd> lmvm ctxusbm
Browse full module list
start end module name
fffff806cbb80000 fffff806cbba2000 ctxusbm T (no symbols)
Image path: \SystemRoot\system32\DRIVERS\ctxusbm.sys
Image name: ctxusbm.sys
Browse all global symbols functions data
Timestamp: Fri Jan 26 15:49:00 2018 (5A6B4DEC)
CheckSum: 000222E4
ImageSize: 00022000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:

## Introduction to Processes, Threads and Stacks

I’ve spoken many times about processes and threads in the past. However, this post will hopefully wrap up the basics and provide a solid introduction to this topic. I originally wrote about this on Sysnative Forums, but thought it would be good to have some new content on this site which I’ve neglected for the past year or so now.

Processes:

Processes are integral to the Windows operating system. Every time you open an application such as a web browser, you’re creating and interacting with a process. What are processes? Why are they important and how can we explore them within WinDbg? In this section, we will be exploring the answer to those questions.

To understand what a process and what a thread is, we can use the analogy of a factory. The process is the factory, it is responsible for producing certain outputs, and is nothing more than a building to house our operations and the workers who must work together to produce those outputs. The workers in this instance are our threads, and will be the ones who work within the process, these workers must operate in perfect synchronization in order to avoid any mishaps from happening and to ensure that the day-to-day operations of the factory are running smoothly.

Every process within is represented with a special structure called _EPROCESS, we can dump this structure within WinDbg using the following command:

6: kd> dt _EPROCESS
nt!_EPROCESS
+0x000 Pcb : _KPROCESS
+0x2d8 ProcessLock : _EX_PUSH_LOCK
+0x2e0 UniqueProcessId : Ptr64 Void
+0x2f8 RundownProtect : _EX_RUNDOWN_REF
+0x300 Flags2 : Uint4B
+0x300 JobNotReallyActive : Pos 0, 1 Bit
+0x300 AccountingFolded : Pos 1, 1 Bit
+0x300 NewProcessReported : Pos 2, 1 Bit
+0x300 ExitProcessReported : Pos 3, 1 Bit
+0x300 ReportCommitChanges : Pos 4, 1 Bit
+0x300 LastReportMemory : Pos 5, 1 Bit
+0x300 ForceWakeCharge : Pos 6, 1 Bit
+0x300 CrossSessionCreate : Pos 7, 1 Bit
+0x300 NeedsHandleRundown : Pos 8, 1 Bit
+0x300 RefTraceEnabled : Pos 9, 1 Bit
+0x300 DisableDynamicCode : Pos 10, 1 Bit
+0x300 EmptyJobEvaluated : Pos 11, 1 Bit
+0x300 DefaultPagePriority : Pos 12, 3 Bits
+0x300 PrimaryTokenFrozen : Pos 15, 1 Bit
+0x300 ProcessVerifierTarget : Pos 16, 1 Bit
+0x300 StackRandomizationDisabled : Pos 17, 1 Bit
+0x300 AffinityPermanent : Pos 18, 1 Bit
+0x300 AffinityUpdateEnable : Pos 19, 1 Bit
+0x300 PropagateNode : Pos 20, 1 Bit
+0x300 ExplicitAffinity : Pos 21, 1 Bit
+0x300 ProcessExecutionState : Pos 22, 2 Bits
+0x300 DisallowStrippedImages : Pos 24, 1 Bit
+0x300 HighEntropyASLREnabled : Pos 25, 1 Bit
+0x300 ExtensionPointDisable : Pos 26, 1 Bit
+0x300 ForceRelocateImages : Pos 27, 1 Bit
+0x300 ProcessStateChangeRequest : Pos 28, 2 Bits
+0x300 ProcessStateChangeInProgress : Pos 30, 1 Bit
+0x300 DisallowWin32kSystemCalls : Pos 31, 1 Bit
+0x304 Flags : Uint4B
[...]

I’ve highlighted three of the fields which I feel are important to understand for a small introduction to processes. Please note that there are many more useful fields within this structure, but they require much more knowledge about the Windows operating system.

The UniqueProcessId field is self explanatory and is a unique Id assigned to each process upon creation. This is usually seen in other aspects of Windows as Pid.

The ActiveProcessLinks field is more interesting. It refers to the doubly linked list in which all processes belong to when they are created. This enables Windows to keep track of all the active processes running on the system. This can be manipulated by malicious programs to hide themselves, but fortunately, there is techniques which can be used to detect this kind of manipulation. More details can be found here – Rootkits: Direct Kernel Object Manipulation and Processes

The list head of this doubly linked list is found in a global variable called PsActiveProcessHead. This is the start of the doubly linked list. However, I won’t delve into this too much as it is out of the scope of this article. You can dump the address using the following command:

? poi(PsActiveProcessHead)

You may noticed another process called _KPROCESS referenced to from the Pcb field, and we can dump it within WinDbg in the same way as before:

6: kd> dt _KPROCESS
nt!_KPROCESS
+0x028 DirectoryTableBase : Uint8B
+0x040 ProcessLock : Uint4B
+0x044 ProcessTimerDelay : Uint4B
+0x048 DeepFreezeStartTime : Uint8B
+0x050 Affinity : _KAFFINITY_EX
+0x108 SwapListEntry : _SINGLE_LIST_ENTRY
+0x110 ActiveProcessors : _KAFFINITY_EX
+0x1b8 AutoAlignment : Pos 0, 1 Bit
+0x1b8 DisableBoost : Pos 1, 1 Bit
+0x1b8 DisableQuantum : Pos 2, 1 Bit
+0x1b8 DeepFreeze : Pos 3, 1 Bit
+0x1b8 TimerVirtualization : Pos 4, 1 Bit
+0x1b8 CheckStackExtents : Pos 5, 1 Bit
+0x1b8 PpmPolicy : Pos 6, 2 Bits
+0x1b8 ActiveGroupsMask : Pos 8, 20 Bits
+0x1b8 ReservedFlags : Pos 28, 4 Bits
+0x1b8 ProcessFlags : Int4B
+0x1bc BasePriority : Char
+0x1bd QuantumReset : Char
+0x1be Visited : UChar
+0x1bf Flags : _KEXECUTE_OPTIONS
+0x210 IdealNode : [20] Uint2B
+0x238 IdealGlobalNode : Uint2B
+0x23a Spare1 : Uint2B
+0x23c StackCount : _KSTACK_COUNT
+0x240 ProcessListEntry : _LIST_ENTRY
+0x250 CycleTime : Uint8B
+0x258 ContextSwitches : Uint8B
+0x260 SchedulingGroup : Ptr64 _KSCHEDULING_GROUP
+0x268 FreezeCount : Uint4B
+0x26c KernelTime : Uint4B
+0x270 UserTime : Uint4B
+0x278 Spare2 : [80] UChar
+0x2c8 InstrumentationCallback : Ptr64 Void
+0x2d0 SecurePid : Uint8B

Now, there isn’t too much of a difference between _EPROCESS and _KPROCESS apart from their fields. The purpose of this was to increase the level of abstraction within processes. The acronym for the Pcb field is Process Control Block. I’ve highlighted two fields of interest, one of which will lead directly into the next topic of this article which is threads.

The DirectoryTableBase field is an important field used in memory management and address translation. We won’t cover the details of address translation here, although, it should be mentioned that it is performed using what is known as page tables. The field contains the address of first table which is used in address translation.

6: kd> dt _EPROCESS -y ThreadListHead
nt!_EPROCESS
+0x488 ThreadListHead : _LIST_ENTRY

There is a much easier method for dumping process information and that is through the use of the following debugger command extension:

!process

If we do not specify the address of the process, then it will dump the details of the last process which was running at the time of the crash.

0: kd> !process
PROCESS ffff950a37820040
SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000
DirBase: 001aa000 ObjectTable: ffffc58291002100 HandleCount: 3021.
Image: System
VadRoot ffff950a39f0b850 Vads 125 Clone 0 Private 34. Modified 387903. Locked 64.
DeviceMap ffffc5829101bd80
Token ffffc58291016a10
ElapsedTime 08:48:37.316
UserTime 00:00:00.000
KernelTime 00:03:39.234
QuotaPoolUsage[PagedPool] 0
QuotaPoolUsage[NonPagedPool] 136
Working Set Sizes (now,min,max) (5527, 50, 450) (22108KB, 200KB, 1800KB)
PeakWorkingSetSize 7613
VirtualSize 25 Mb
PeakVirtualSize 33 Mb
PageFaultCount 15055
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 46

fffff8013bb4b2e0 SynchronizationEvent

fffff8013bb4c1e0 Semaphore Limit 0x7fffffff

[...]

Notice some of the similar information we saw in the _EPROCESS and _KPROCESS structures from earlier? The Image field is the name of the process; in our case, it was the system process. We can also see all the current threads associated to this process too, along with, their thread addresses which we which will use in the next section.

Threads are where the process execution takes place. Threads are no more than units of execution. Each thread will have two stacks: one of which is for the kernel and one of which is for user mode. We’ll explore stacks in the next section. Like with processes, each thread has a _ETHREAD structure and a _KTHREAD structure. Let’s firstly dump the _ETHREAD structure:

6: kd> dt _ETHREAD
+0x5e8 CreateTime : _LARGE_INTEGER
+0x5f0 ExitTime : _LARGE_INTEGER
+0x5f0 KeyedWaitChain : _LIST_ENTRY
+0x600 ChargeOnlySession : Ptr64 Void
+0x608 PostBlockList : _LIST_ENTRY
+0x618 TerminationPort : Ptr64 _TERMINATION_PORT
+0x618 KeyedWaitValue : Ptr64 Void
+0x620 ActiveTimerListLock : Uint8B
+0x638 Cid : _CLIENT_ID
+0x648 KeyedWaitSemaphore : _KSEMAPHORE
+0x648 AlpcWaitSemaphore : _KSEMAPHORE
+0x668 ClientSecurity : _PS_CLIENT_SECURITY_CONTEXT
+0x670 IrpList  : _LIST_ENTRY
+0x680 TopLevelIrp : Uint8B
+0x688 DeviceToVerify : Ptr64 _DEVICE_OBJECT
+0x698 LegacyPowerObject : Ptr64 Void
+0x6b0 RundownProtect : _EX_RUNDOWN_REF
+0x6c4 MmLockOrdering : Int4B
+0x6c8 Terminated : Pos 0, 1 Bit
+0x6c8 ThreadInserted : Pos 1, 1 Bit
+0x6c8 HideFromDebugger : Pos 2, 1 Bit
+0x6c8 ActiveImpersonationInfo : Pos 3, 1 Bit
+0x6c8 HardErrorsAreDisabled : Pos 4, 1 Bit
+0x6c8 BreakOnTermination : Pos 5, 1 Bit
+0x6c8 SkipCreationMsg : Pos 6, 1 Bit
+0x6c8 SkipTerminationMsg : Pos 7, 1 Bit
+0x6c8 CopyTokenOnOpen : Pos 8, 1 Bit
+0x6c8 ThreadIoPriority : Pos 9, 3 Bits
+0x6c8 ThreadPagePriority : Pos 12, 3 Bits

[...]

The Tcb field refers to the thread control block and is a reference to the _KTHREAD structure.

The Cid field is the unique identifier associated with each thread.

The IrpList is a doubly linked list of IRPs which have been generated by this thread. IRPs are I/O request packets which are used by I/O manager to complete various operations such as power management including putting devices in a sleep state.

Now, let’s dump the _KTHREAD structure and investigate some of its fields:

6: kd> dt _KTHREAD
+0x020 QuantumTarget : Uint8B
+0x028 InitialStack : Ptr64 Void
+0x030 StackLimit  : Ptr64 Void
+0x038 StackBase : Ptr64 Void
+0x048 CycleTime : Uint8B
+0x050 CurrentRunTime : Uint4B
+0x054 ExpectedRunTime : Uint4B
+0x058 KernelStack : Ptr64 Void
+0x060 StateSaveArea : Ptr64 _XSAVE_FORMAT
+0x068 SchedulingGroup : Ptr64 _KSCHEDULING_GROUP
+0x070 WaitRegister : _KWAIT_STATUS_REGISTER
+0x071 Running : UChar
+0x074 AutoBoostActive : Pos 0, 1 Bit
+0x074 ReadyTransition : Pos 1, 1 Bit
+0x074 WaitNext : Pos 2, 1 Bit
+0x074 SystemAffinityActive : Pos 3, 1 Bit
+0x074 Alertable : Pos 4, 1 Bit
+0x074 UserStackWalkActive : Pos 5, 1 Bit
+0x074 ApcInterruptRequest : Pos 6, 1 Bit
+0x074 QuantumEndMigrate : Pos 7, 1 Bit
+0x074 UmsDirectedSwitchEnable : Pos 8, 1 Bit
+0x074 TimerActive : Pos 9, 1 Bit
+0x074 SystemThread : Pos 10, 1 Bit
+0x074 ProcessDetachActive : Pos 11, 1 Bit
+0x074 CalloutActive : Pos 12, 1 Bit
+0x074 ScbReadyQueue : Pos 13, 1 Bit
+0x074 ApcQueueable : Pos 14, 1 Bit
+0x074 ReservedStackInUse : Pos 15, 1 Bit
+0x074 UmsPerformingSyscall : Pos 16, 1 Bit
+0x074 TimerSuspended : Pos 17, 1 Bit

[...]

The StackLimit and StackBase fields refer to the end and the beginning of the call stack associated to this thread respectively. The KernelStack field contains a pointer to the beginning of the kernel stack. We can use the addresses referenced by these pointers with the dps command to dump the entire stack of thread.

As before, we can dump the details of a thread in a much more user friendly way using the !thread debugger extension.

!thread

6: kd> !thread
THREAD ffff950a3d56a080 Cid 2650.0be8 Teb: 00000017e3638000 Win32Thread: ffff950a3c0c6550 RUNNING on processor 6
IRP List:
ffff950a42183240: (0006,0478) Flags: 00060043 Mdl: ffff950a3e724b40
Not impersonating
DeviceMap ffffc582aa67e490
Owning Process ffff950a3f462080 Image: OSBuddy64.exe
Attached Process N/A Image: N/A
Wait Start TickCount 2030855 Ticks: 1 (0:00:00:00.015)
Context Switch Count 2818893 IdealProcessor: 6
UserTime 01:04:06.640
KernelTime 00:23:55.015
Stack Init ffffe480e018ec90 Current ffffe480e018df50
Base ffffe480e018f000 Limit ffffe480e0189000 Call 0000000000000000
Priority 6 BasePriority 6 PriorityDecrement 0 IoPriority 2 PagePriority 5

Child-SP RetAddr : Args to Child : Call Site
ffffe480e018d908 fffff8013b82eb7c : 000000000000001e ffffffffc0000005 fffff805f2dda7df 0000000000000000 : nt!KeBugCheckEx
ffffe480e018d910 fffff8013b97b98e : ffffe480e018e110 0000000000000000 0000000000000000 0000000000000000 : nt!KiDispatchException+0x23c
ffffe480e018dfc0 fffff8013b979e57 : 0000000000000000 000000000003081c ffff950a00000000 00000036b77d3868 : nt!KiExceptionDispatch+0xce
ffffe480e018e1a0 fffff805f2dda7df : ffff950a00000000 0000000000000000 0000000000000000 ffffc582a28fd128 : nt!KiPageFault+0x217 (TrapFrame @ ffffe480e018e1a0)
ffffe480e018e330 fffff805f2ddb92d : ffffe480e018e450 ffffe480e018e638 ffff950a3dfc6b00 fffff805f2d21a94 : NTFS!NtfsPreRequestProcessingExtend+0x4f
ffffe480e018e420 fffff805f240563d : ffff950a38d49170 ffff950a42183240 ffff950a39f46df0 ffff950a42183628 : NTFS!NtfsFsdRead+0x1dd
ffffe480e018e6a0 fffff805f24034d6 : ffffe480e018e730 0000000000000003 000000000000000d 0000000000000000 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x18d
ffffe480e018e710 fffff8013b8404a5 : ffff950a42183260 ffff950a42183240 ffff950a3dfc6bf0 fffff8013b892171 : FLTMGR!FltpDispatch+0xb6
ffffe480e018e770 fffff8013b8a5f42 : ffff950a3e724a40 000000003b893da5 ffff950a3e724aa0 ffff950a3e724a60 : nt!IoPageReadEx+0x265
ffffe480e018e7e0 fffff8013b8a5970 : 0000000000000003 ffffe480e018e8b0 0000000000000000 fffff8013b870fe9 : nt!MiIssueHardFaultIo+0xb6
ffffe480e018e830 fffff8013b891486 : 00000000c0033333 ffffe480e018eb00 0000000000000000 ffffe480e018ea10 : nt!MiIssueHardFault+0x190
ffffe480e018e910 fffff8013b979d72 : ffff950a3d56a080 000001c200000000 ffff950a3debd310 ffff950a3debd310 : nt!MmAccessFault+0xc96
ffffe480e018eb00 00000000572be790 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiPageFault+0x132 (TrapFrame @ ffffe480e018eb00)
00000000fb5fe128 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x572be790

The highlighted fields correspond directly to the fields discussed within the _ETHREAD and _KTHREAD structures. You can now also see the call stack for this thread. We’ll discuss call stacks in the next section.

Stacks:

Each thread has its own call stack. When we are debugging kernel crash dumps, we are actually examining the kernel version of the thread’s call stack.

You can think of a call stack as the operations which the thread has been completing. Call stacks are read from the top to the bottom. The last call is placed at the top and the first call is placed at the bottom. Call stacks follow what is known as LIFO (Last In First Out). This means that the last stack frame to be pushed (inserted) onto the stack, is the first stack frame to be popped (removed) from the stack. Each function call results in a new stack frame being pushed onto the stack, once this function has returned, then the stack frame is popped.

We’ll discuss stack frames momentarily.

Firstly, let’s dump the call stack for the thread. Using the WinDbg k command will dump the call stack for the current thread context.

6: kd> k
00 ffffe480e018d908 fffff8013b82eb7c nt!KeBugCheckEx
01 ffffe480e018d910 fffff8013b97b98e nt!KiDispatchException+0x23c
02 ffffe480e018dfc0 fffff8013b979e57 nt!KiExceptionDispatch+0xce
03 ffffe480e018e1a0 fffff805f2dda7df nt!KiPageFault+0x217
04 ffffe480e018e330 fffff805f2ddb92d NTFS!NtfsPreRequestProcessingExtend+0x4f
05 ffffe480e018e420 fffff805f240563d NTFS!NtfsFsdRead+0x1dd
06 ffffe480e018e6a0 fffff805f24034d6 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x18d
07 ffffe480e018e710 fffff8013b8404a5 FLTMGR!FltpDispatch+0xb6
08 ffffe480e018e770 fffff8013b8a5f42 nt!IoPageReadEx+0x265
09 ffffe480e018e7e0 fffff8013b8a5970 nt!MiIssueHardFaultIo+0xb6
0a ffffe480e018e830 fffff8013b891486 nt!MiIssueHardFault+0x190
0b ffffe480e018e910 fffff8013b979d72 nt!MmAccessFault+0xc96
0c ffffe480e018eb00 00000000572be790 nt!KiPageFault+0x132
0d 00000000fb5fe128 0000000000000000 0x572be790

If examine the stack, we can see four different columns: the stack frame number (#), the stack pointer address (Child-SP), the return address once the call has completed (RetAddr) and the function call being made (Call Site). The k command is the simplest of the WinDbg call stack unwind commands, there are many different variations which dump varying information regarding the call stack, however, the k command will be suffice for this article.

As we can see in the call stack, the last call was to nt!KeBugCheckEx, this the bugcheck exception handler which builds and dispatches our blue screen of death. Each line within the call stack represents an individual stack frame. We can dump a stack frame using the .frame command with the /r switch to dump the registers:

6: kd> .frame /r 0
00 ffffe480e018d908 fffff8013b82eb7c nt!KeBugCheckEx
rax=0000000049c8820f rbx=ffffe480e018e0f8 rcx=000000000000001e
rdx=ffffffffc0000005 rsi=ffffe480e018d940 rdi=ffffe480e018e0f8
rip=fffff8013b9704c0 rsp=ffffe480e018d908 rbp=ffffe480e018de40
r8=fffff805f2dda7df r9=0000000000000000 r10=0000000000000000
r11=00007ffffffeffff r12=000000000010001f r13=0000000000000000
r14=ffffe480e018e1a0 r15=ffff950a42183200
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00000246
nt!KeBugCheckEx:
fffff8013b9704c0 48894c2408 mov qword ptr [rsp+8],rcx ss:ffffe480e018d910=000000000000001e

Now each stack frame will have it’s own registers saved and parameters pushed to the stack. The first four parameters to a function call are always pushed to rcx, rdx, r8 and r9 registers respectively on x64 machines. Any other additional parameters are pushed onto the stack itself.

Now, using the previously mentioned function call, we can see this in action by dumping the bugcheck parameters using the .dumpdebug command comparing them to the values stored in the parameters within the call stack frame.

6: kd> .dumpdebug
----- 64 bit Kernel Bitmap Dump Analysis - Kernel address space is available,
User address space may not be available.

MajorVersion 0000000f
KdSecondaryVersion 00000000
DirectoryTableBase 000000016c054000
PfnDataBase ffffd88000000000
PsActiveProcessHead fffff8013bb4a040
MachineImageType 00008664
NumberProcessors 00000008
BugCheckCode 0000001e
BugCheckParameter1 ffffffffc0000005
BugCheckParameter2 fffff805f2dda7df
BugCheckParameter3 0000000000000000
BugCheckParameter4 0000000049c8820f

[...]

As you can see, the first parameter of the bugcheck is pushed into the rcx register, the second parameter is pushed into the rdx register, and the third and fourth into the r8 and r9 registers. However, you may be a little confused now?

The .dumpdebug command is stating that fourth parameter is 0000000049c8820f, but the r9 register contains the value of third parameter? This is because the KeBugCheckEx function actually takes the STOP code as the first parameter. The fourth bugcheck parameter is actually the fifth parameter to be passed to the function and can be found on the stack.

We can find this by using the stack pointer address stored in the rsp register, and using the dd command with the appropriate offset.

6: kd> dd ffffe480e018d908+24 l2
ffffe480e018d92c 00000000 49c8820f

## Debugging Stop 0x17C – PDC_LOCK_WATCHDOG

Stop 0x17C is a very rare bugcheck which I have only come across on a handful of occasions, and therefore it can be quite daunting to debug, especially since there is almost no documentation.

The bugcheck appears to be caused by a synchronization issue, whereby a thread has held a lock for longer than the allocated time limit. I’m uncertain on what exactly a PDC lock is, and haven’t been able to find any useful information on it. However, judging by the context in which crash was occurring, I believe that I have been able to devise a suitable debugging methodology for this bugcheck.

Firstly, since the bugcheck appears to be occurring when the system was entering or leaving standby mode, I firstly dumped the power state information using the !poaction debugger extension.

0: kd> !poaction
PopAction: fffff80088166820
State..........: 0 - Idle
Action.........: None
Lightest State.: Unspecified
Flags..........: 10000003 QueryApps|UIAllowed
Irp minor......: ??
System State...: Unspecified
Hiber Context..: 0000000000000000

Allocated power irps (PopIrpList - fffff80088166ee0)
IRP: ffffd40e760c88a0 (wait-wake/S4), PDO: ffffd40e73f1c060
IRP: ffffd40e7525c940 (wait-wake/S4), PDO: ffffd40e75223620
IRP: ffffd40e75245940 (wait-wake/S4), PDO: ffffd40e75251060
IRP: ffffd40e752dfc10 (wait-wake/S4), PDO: ffffd40e75e14060
IRP: ffffd40e76f3ec10 (wait-wake/S4), PDO: ffffd40e75157050
IRP: ffffd40e753a1ab0 (wait-wake/S4), PDO: ffffd40e76eeda90
IRP: ffffd40e753e9010 (wait-wake/S4), PDO: ffffd40e7539a060
IRP: ffffd40e753908b0 (wait-wake/S4), PDO: ffffd40e75398060
IRP: ffffd40e753e48b0 (wait-wake/S4), PDO: ffffd40e7538f060
IRP: ffffd40e752bb010 (wait-wake/S4), PDO: ffffd40e7538e060
IRP: ffffd40e76f2ac10 (wait-wake/S4), PDO: ffffd40e76e84060
IRP: ffffd40e7558b740 (wait-wake/S4), PDO: ffffd40e75153050
IRP: ffffd40e752e1c10 (wait-wake/S4), PDO: ffffd40e76ea63c0
IRP: ffffd40e7b509700 (wait-wake/S4), PDO: ffffd40e76e98060

No Device State present

There appears to be number of power IRPs related to the S4 power state which is Hibernation mode. The system appears to be in the standby mode; this was implemented in Windows 8, and allows a system to instantly ‘wake’ from a sleep state.

Let’s examine one of these IRPs and see what type of I/O request is being issued.

0: kd> !irp ffffd40e760c88a0
Irp is active with 4 stacks 2 is current (= 0xffffd40e760c89b8)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_POWER(16), IRP_MN_WAIT_WAKE(0)]
0 e1 ffffd40e73f2ce40 00000000 fffff80b8707f3e0-ffffd40e74a431a0 Success Error Cancel pending
\Driver\ACPI ndis!ndisWaitWakeIoCompletion
Args: 00000005 00000000 00000000 00000000
[IRP_MJ_POWER(16), IRP_MN_WAIT_WAKE(0)]
0 e0 ffffd40e74a43050 00000000 fffff80087f21890-ffffd40e73f50f00 Success Error Cancel
Page 35f36 not present in the dump file. Type ".hh dbgerr004" for details
Page 35f36 not present in the dump file. Type ".hh dbgerr004" for details
*** ERROR: Module load completed but symbols could not be loaded for e1d65x64.sys
\Driver\e1dexpress nt!PopRequestCompletion
Args: 00000005 00000000 00000000 00000000
[N/A(0), N/A(0)]
0 0 00000000 00000000 00000000-ffffd40e73f50f00

Args: 00000000 00000000 00000000 00000000[/code]

The major code for the IRP is 16, and therefore we know that we are dealing with a power management related request. The Minor code is 0, and as a result, we know that the I/O request is related to waking from a sleep power transition state. The parameter provided with IRP indicates the lowest power state in which the device can be awoken from. We can dump the enumeration values for system power states using the following:

0: kd> dt nt!_SYSTEM_POWER_STATE
PowerSystemUnspecified = 0n0
PowerSystemWorking = 0n1
PowerSystemSleeping1 = 0n2
PowerSystemSleeping2 = 0n3
PowerSystemSleeping3 = 0n4
PowerSystemHibernate = 0n5
PowerSystemShutdown = 0n6
PowerSystemMaximum = 0n7

We can see that the device is able to accept requests when it is in the hibernation power state.

The driver present in the IRP stack was related to Intel. I’ve chosen another IRP (ffffd40e753a1ab0), and this time it revealed that an Xbox driver was present with a time stamp of 2015. From my experience, Xbox drivers are usually unstable and tend to cause several BSODs, and thus could be a likely culprit for the crash. It is also important to note that the driver seemed to be network related too.

0: kd> lmvm mt7612US

start end module name
fffff80b88c00000 fffff80b88c61000 mt7612US (no symbols)
Image path: \SystemRoot\System32\drivers\mt7612US.sys
Image name: mt7612US.sys
Timestamp: Wed Dec 9 06:44:11 2015 (5667CDBB)
CheckSum: 00062A42
ImageSize: 00061000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

Unfortunately, the OP hasn’t come to me regarded our suggestions of updating the driver, and thereby we can’t be certain how effective this debugging methodology will be for future dumps.

## Debugging Stop 0xC4 – Pool Allocation Error

A Stop 0xC4 is thrown by Driver Verifier and is typically very easy to debug. However, I thought I would show a few aspects of the bugcheck which are useful for identifying how the crash occurred and how you can find this information using WinDbg.

There are three key parameters for a Stop 0xC4: the first parameter, third parameter and fourth parameter.

BugCheck C4, {2000, fffff80f5527b048, 0, 56706353}
Probably caused by : ScpVBus.sys ( ScpVBus+b048 )

The first parameter indicates that the caller of the function was expecting a non-executable pool allocation, however, was provided with a executable pool allocation instead. The third parameter provides the pool type for the allocation.

We can find the pool type enumeration values within the POOL_TYPE enumeration.

: kd> dt nt!_POOL_TYPE
NonPagedPool = 0n0
NonPagedPoolExecute = 0n0
PagedPool = 0n1
NonPagedPoolMustSucceed = 0n2
DontUseThisType = 0n3
NonPagedPoolCacheAligned = 0n4
PagedPoolCacheAligned = 0n5
NonPagedPoolCacheAlignedMustS = 0n6
MaxPoolType = 0n7
NonPagedPoolBase = 0n0
NonPagedPoolBaseMustSucceed = 0n2
NonPagedPoolBaseCacheAligned = 0n4
NonPagedPoolBaseCacheAlignedMustS = 0n6
NonPagedPoolSession = 0n32
PagedPoolSession = 0n33
NonPagedPoolMustSucceedSession = 0n34
DontUseThisTypeSession = 0n35
NonPagedPoolCacheAlignedSession = 0n36
PagedPoolCacheAlignedSession = 0n37
NonPagedPoolCacheAlignedMustSSession = 0n38
NonPagedPoolNx = 0n512
NonPagedPoolNxCacheAligned = 0n516
NonPagedPoolSessionNx = 0n544

The fourth parameter contains the address of the pool tag. We can use the .formats command with the address to obtain the stored string and then reverse the string to provide the pool tag. This string can then be used with the !pooltag extension to provide the name of the driver. Although, it should be noted that the !pooltag extension will only provide definitions for drivers defined within the pooltag.txt file.

1: kd> .formats 56706353
Evaluate expression:
Hex:     0000000056706353
Decimal: 1450206035
Octal:   0000000000012634061523
Binary:  00000000 00000000 00000000 00000000 01010110 01110000 01100011 01010011
Chars:   ....VpcS
Time:    Tue Dec 15 11:00:35 2015
Float:   low 6.60773e+013 high 0
Double:  7.16497e-315

The reverse of VpcS is ScpV.

1: kd> !pooltag ScpV
Pooltag ScpV
Description: Mass storage driver tags

It appears that the pool tag is a generic tag used for a wide range of mass storage devices.

Using the lmvm command with the driver from the bugcheck description, we can see that the driver which potentially caused the crash was related to a bus driver.

1: kd> lmvm ScpVBus
Browse full module list
start             end                 module name
fffff80f55270000 fffff80f5527e000   ScpVBus  T (no symbols)
Image path: ScpVBus.sys
Image name: ScpVBus.sys
Browse all global symbols  functions  data
Timestamp:        Sun May  5 14:31:26 2013 (5186CFAE)
CheckSum:         00010BD7
ImageSize:        0000E000
Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:

To be specific, the driver was a third-party bus driver related to Dual Shock 3.

In addition to this, we can use the second parameter as the return address to find who called the faulting instruction. Again, this appears to be point to our third-party bus driver.

1: kd> knL
00 ffffd80160fb70f8 fffff8027bdf803f nt!KeBugCheckEx
01 ffffd80160fb7100 fffff8027b8d9cef nt!VerifierBugCheckIfAppropriate+0x6b
02 ffffd80160fb7140 fffff8027bdef8b0 nt!VfReportIssueWithOptions+0x103
03 ffffd80160fb7190 fffff8027be05b3a nt!VfCheckPoolType+0x90
04 ffffd80160fb71d0 fffff80f5527b048 nt!VerifierExInitializeNPagedLookasideList+0x5a
05 ffffd80160fb7250 ffffa60f94f55410 ScpVBus+0xb048
06 ffffd80160fb7258 0000000000000000 0xffffa60f94f55410

Using the ub command on the return address we can see that the disassembly reveals several calls involving the ScpVBus.

1: kd> ub fffff80f5527b048
ScpVBus+0xb027:
fffff80f5527b027 53              push    rbx
fffff80f5527b028 637056          movsxd  esi,dword ptr [rax+56h]
fffff80f5527b02b 488d0d4ea3ffff  lea     rcx,[ScpVBus+0x5380 (fffff80f55275380)]
fffff80f5527b032 4533c9          xor     r9d,r9d
fffff80f5527b035 4533c0          xor     r8d,r8d
fffff80f5527b038 33d2            xor     edx,edx
fffff80f5527b03a 48c740d818000000 mov     qword ptr [rax-28h],18h
fffff80f5527b042 ff15d88fffff    call    qword ptr [ScpVBus+0x4020 (fffff80f55274020)]

## Release of WinDbg Preview for Windows 10

Microsoft have decided to release a new version of WinDbg with a new UI. The UI has been designed to provide WinDbg with a more contemporary appearance, and more importantly, provide easier access to some of the important features of WinDbg such as the Registers window and the Command output window.

WinDbg Preview – Dark Theme

I’ve only started to use the preview version of WinDbg today, however, I have noted that once a dump file has been loaded into the debugger, the last line of the call stack is also printed. In addition to this, you’re also now able to switch between a light and dark themed Windbg, which is a feature that I quite enjoy using, especially if you’re potentially using WinDbg for long periods of time.

The underlying engine is the exact same at the moment, and therefore all the usual extensions and commands will work with this version of WinDbg. Although, I feel that debugger is rather sluggish against its current counterpart, despite the fact, that Microsoft have stated it has been designed to be smoother!

For more details, please visit the following blog post on Debugging Tools for Windows, which also provides the download link for the debugger. Please note that Microsoft have made no intentions yet to release the preview version for other operating system builds such as Windows 7. Although, I suspect that further alterations will be made to this version of WinDbg in the future, which will hopefully allow backwards compatibility with earlier operating systems.

## Some Notes on the Goldbach Conjecture

The Goldbach Conjecture is a very simple conjecture to understand providing you have some basic knowledge about primes. It is one of those conjectures which is very easy to comprehend, but fiendishly difficult to solve. It was first conceived during a letter written by Goldbach to Euler in 1742. There is currently a strong and weak version of the Goldbach Conjecture, with the weak conjecture actually being the original conjecture.

xkcd: Goldbach Conjectures

The original conjecture asks to prove that all positive integers greater than 2 are equivalent to the sum of three primes, the only problem with the original conjecture, is that Goldbach considered the unit “1” to be prime, which has now been dismissed in Mathematics. However, the conjecture has been restated by Euler to the following modern equivalent, which is known as the strong Goldbach Conjecture (sometimes referred to as the binary Goldbach Conjecture):

Strong Goldbach Conjecture: Every positive even integer greater than or equal to 4, can be expressed as the sum of two primes.

The conjecture can also be expressed using the totient function:

$\phi (p) + \phi (q) = 2m$,

where m is a positive integer and p and q are both prime numbers. The totient function can be defined as the following (p is prime):

$\phi(p) = p - 1$

The weaker version of the Goldbach conjecture asks a slightly different question, and is as follows:

Weak Goldbach Conjecture: Every odd integer greater than or equal to 9, can be expressed as the sum of three odd primes.

Similarly, Levy’s Conjecture claims that all odd integers greater than or equal to 7, can be expressed the sum of prime and twice a prime.

$p + 2q = n$, where n is a positive integer greater than or equal to 7, and p and q are both primes.

Goldbach Number:

Goldbach numbers are any positive even integers which are the sum of two odd primes.

Goldbach Partition:

The Goldbach Partition is the number of ways in which a positive even integer n, can be written as the sum of two primes. The function which produces these partitions is called the Goldbach Partition function $G(n)$. It is defined in the following manner:

$G(n) = #{(p, q) | n = p + q, p \le q}$

Methods for proving the Goldbach Conjecture:

The two most common methods which have been used for solving the Goldbach Conjecture involve the Hardy-Littlewood Method along with a number of different sieving methods which have been used to produce greater asymptotic bounds on the distribution of which natural numbers can be written as Goldbach Partitions.

References:

Goldbach Conjecture – Wolfram MathWorld

Goldbach Partition – Wolfram MathWorld

Goldbach Number – Wolfram MathWorld

On Partitions of Goldbach’s Conjecture (Woon)

Posted in Uncategorized | 1 Comment

## Project Euler: Problem 29

Problem 29 is actually a very easy problem to solve, but I will not provide the direct code, however, instead will provide the answer to the problem along with some insight into how to solve the problem using Java or a similar programming language.

The solution for the problem is 9183.

There are three key constructs which you will need to include in your code, and these are:

• Nested For-loop
• Power function
• A collection to hold the sequence of numbers generated from the power function.

If you use the above programming constructs within your problem, then you’ll the solution to the problem almost instantly. A important point to remember is to consider the size of the numbers which will be generated, and which data types will be able to hold such large numbers (integers won’t work!).