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.

The IO manager has caught a misbehaving driver.
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.
Arg3: ffffb383dffedd40, IRP address.
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

(fffff800`7421a500) nt!VerifierIoGetDeviceProperty+0x1a | (fffff800`7421a530) 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
# Child-SP RetAddr Call Site
00 fffffc89`fb577148 fffff800`742186e3 nt!KeBugCheckEx
01 fffffc89`fb577150 fffff800`7421f947 nt!VerifierBugCheckIfAppropriate+0xdf
02 fffffc89`fb577190 fffff800`7421f6f6 nt!ViErrorFinishReport+0x117
03 fffffc89`fb5771f0 fffff800`73b4ba2c nt!VfErrorReport8+0x66
04 fffffc89`fb5772a0 fffff800`74049b8e nt!PpvUtilFailDriver+0x2c
05 fffffc89`fb5772d0 fffff800`7421a51a nt!IoGetDeviceProperty+0x1e01ee
06 fffffc89`fb5773d0 fffff806`cbb92fa4 nt!VerifierIoGetDeviceProperty+0x1a
07 fffffc89`fb577410 ffffb383`ed692f00 ctxusbm+0x12fa4
08 fffffc89`fb577418 00000000`00000000 0xffffb383`ed692f00

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

15: kd> ub fffff800`7421a51a L15
fffff800`7421a4e0 4883ec38 sub rsp,38h
fffff800`7421a4e4 488b051d890500 mov rax,qword ptr [nt!pXdvIoGetDeviceObjectPointer (fffff800`74272e08)]
fffff800`7421a4eb e8c09685ff call nt!guard_dispatch_icall (fffff800`73a73bb0)
fffff800`7421a4f0 4883c438 add rsp,38h
fffff800`7421a4f4 c3 ret
fffff800`7421a4f5 cc int 3
fffff800`7421a4f6 cc int 3
fffff800`7421a4f7 cc int 3
fffff800`7421a4f8 cc int 3
fffff800`7421a4f9 cc int 3
fffff800`7421a4fa cc int 3
fffff800`7421a4fb cc int 3
fffff800`7421a4fc cc int 3
fffff800`7421a4fd cc int 3
fffff800`7421a4fe cc int 3
fffff800`7421a4ff cc int 3
fffff800`7421a500 4883ec38 sub rsp,38h
fffff800`7421a504 4c8b542460 mov r10,qword ptr [rsp+60h]
fffff800`7421a509 488b05c8880500 mov rax,qword ptr [nt!pXdvIoGetDeviceProperty (fffff800`74272dd8)]
fffff800`7421a510 4c89542420 mov qword ptr [rsp+20h],r10
fffff800`7421a515 e8969685ff call nt!guard_dispatch_icall (fffff800`73a73bb0)

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 fffff800`7421f6f6
fffff800`7421f6da 780a js nt!VfErrorReport8+0x56 (fffff800`7421f6e6)
fffff800`7421f6dc 488d4c2430 lea rcx,[rsp+30h]
fffff800`7421f6e1 e87e289bff call nt!VfUtilDbgPrint (fffff800`73bd1f64)
fffff800`7421f6e6 4533c9 xor r9d,r9d
fffff800`7421f6e9 4c8bc6 mov r8,rsi
fffff800`7421f6ec 488bd7 mov rdx,rdi
fffff800`7421f6ef 8bcb mov ecx,ebx
fffff800`7421f6f1 e83a010000 call nt!ViErrorFinishReport (fffff800`7421f830)
15: kd> u nt!VfUtilDbgPrint
fffff800`73bd1f64 4c8bdc          mov     r11,rsp
fffff800`73bd1f67 49894b08        mov     qword ptr [r11+8],rcx
fffff800`73bd1f6b 49895310        mov     qword ptr [r11+10h],rdx
fffff800`73bd1f6f 4d894318        mov     qword ptr [r11+18h],r8
fffff800`73bd1f73 4d894b20        mov     qword ptr [r11+20h],r9
fffff800`73bd1f77 4883ec38        sub     rsp,38h
fffff800`73bd1f7b 4533c0          xor     r8d,r8d
fffff800`73bd1f7e 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:
Cannot read info offset from nt!ObpInfoMaskToOffset
\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
fffff806`cbb80000 fffff806`cbba2000 ctxusbm T (no symbols)
Loaded symbol image file: ctxusbm.sys
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:


Posted in Debugging, WinDbg, Windows Internals | Leave a comment

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 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.

task manager.JPG

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
+0x000 Pcb : _KPROCESS
+0x2d8 ProcessLock : _EX_PUSH_LOCK
+0x2e0 UniqueProcessId : Ptr64 Void
+0x2e8 ActiveProcessLinks : _LIST_ENTRY
+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
+0x000 Header : _DISPATCHER_HEADER
+0x018 ProfileListHead : _LIST_ENTRY
+0x028 DirectoryTableBase : Uint8B
+0x030 ThreadListHead : _LIST_ENTRY
+0x040 ProcessLock : Uint4B
+0x044 ProcessTimerDelay : Uint4B
+0x048 DeepFreezeStartTime : Uint8B
+0x050 Affinity : _KAFFINITY_EX
+0x0f8 ReadyListHead : _LIST_ENTRY
+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
+0x1c0 ThreadSeed : [20] Uint4B
+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
+0x274 ReadyTime : 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.

The ThreadListHead field is similar to the process active head for our active processes, and is the head of the doubly linked list for all the threads associated to our running process.

6: kd> dt _EPROCESS -y ThreadListHead
+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:


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

THREAD ffff950a3790b780 Cid 0004.000c Teb: 0000000000000000 Win32Thread: 0000000000000000 WAIT: (Executive) KernelMode Non-Alertable
fffff8013bb4b2e0 SynchronizationEvent

THREAD ffff950a378f3700 Cid 0004.0010 Teb: 0000000000000000 Win32Thread: 0000000000000000 WAIT: (Executive) KernelMode Non-Alertable
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
+0x000 Tcb : _KTHREAD
+0x5e8 CreateTime : _LARGE_INTEGER
+0x5f0 ExitTime : _LARGE_INTEGER
+0x5f0 KeyedWaitChain : _LIST_ENTRY
+0x600 ChargeOnlySession : Ptr64 Void
+0x608 PostBlockList : _LIST_ENTRY
+0x608 ForwardLinkShadow : Ptr64 Void
+0x610 StartAddress : Ptr64 Void
+0x618 TerminationPort : Ptr64 _TERMINATION_PORT
+0x618 ReaperLink : Ptr64 _ETHREAD
+0x618 KeyedWaitValue : Ptr64 Void
+0x620 ActiveTimerListLock : Uint8B
+0x628 ActiveTimerListHead : _LIST_ENTRY
+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
+0x690 Win32StartAddress : Ptr64 Void
+0x698 LegacyPowerObject : Ptr64 Void
+0x6a0 ThreadListEntry : _LIST_ENTRY
+0x6b0 RundownProtect : _EX_RUNDOWN_REF
+0x6b8 ThreadLock : _EX_PUSH_LOCK
+0x6c0 ReadClusterSize : Uint4B
+0x6c4 MmLockOrdering : Int4B
+0x6c8 CrossThreadFlags : Uint4B
+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
+0x000 Header : _DISPATCHER_HEADER
+0x018 SListFaultAddress : Ptr64 Void
+0x020 QuantumTarget : Uint8B
+0x028 InitialStack : Ptr64 Void
+0x030 StackLimit  : Ptr64 Void
+0x038 StackBase : Ptr64 Void
+0x040 ThreadLock : Uint8B
+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
+0x072 Alerted : [2] 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.


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
Win32 Start Address 0x0000000057901dbc
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
ffffe480`e018d908 fffff801`3b82eb7c : 00000000`0000001e ffffffff`c0000005 fffff805`f2dda7df 00000000`00000000 : nt!KeBugCheckEx
ffffe480`e018d910 fffff801`3b97b98e : ffffe480`e018e110 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchException+0x23c
ffffe480`e018dfc0 fffff801`3b979e57 : 00000000`00000000 00000000`0003081c ffff950a`00000000 00000036`b77d3868 : nt!KiExceptionDispatch+0xce
ffffe480`e018e1a0 fffff805`f2dda7df : ffff950a`00000000 00000000`00000000 00000000`00000000 ffffc582`a28fd128 : nt!KiPageFault+0x217 (TrapFrame @ ffffe480`e018e1a0)
ffffe480`e018e330 fffff805`f2ddb92d : ffffe480`e018e450 ffffe480`e018e638 ffff950a`3dfc6b00 fffff805`f2d21a94 : NTFS!NtfsPreRequestProcessingExtend+0x4f
ffffe480`e018e420 fffff805`f240563d : ffff950a`38d49170 ffff950a`42183240 ffff950a`39f46df0 ffff950a`42183628 : NTFS!NtfsFsdRead+0x1dd
ffffe480`e018e6a0 fffff805`f24034d6 : ffffe480`e018e730 00000000`00000003 00000000`0000000d 00000000`00000000 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x18d
ffffe480`e018e710 fffff801`3b8404a5 : ffff950a`42183260 ffff950a`42183240 ffff950a`3dfc6bf0 fffff801`3b892171 : FLTMGR!FltpDispatch+0xb6
ffffe480`e018e770 fffff801`3b8a5f42 : ffff950a`3e724a40 00000000`3b893da5 ffff950a`3e724aa0 ffff950a`3e724a60 : nt!IoPageReadEx+0x265
ffffe480`e018e7e0 fffff801`3b8a5970 : 00000000`00000003 ffffe480`e018e8b0 00000000`00000000 fffff801`3b870fe9 : nt!MiIssueHardFaultIo+0xb6
ffffe480`e018e830 fffff801`3b891486 : 00000000`c0033333 ffffe480`e018eb00 00000000`00000000 ffffe480`e018ea10 : nt!MiIssueHardFault+0x190
ffffe480`e018e910 fffff801`3b979d72 : ffff950a`3d56a080 000001c2`00000000 ffff950a`3debd310 ffff950a`3debd310 : nt!MmAccessFault+0xc96
ffffe480`e018eb00 00000000`572be790 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x132 (TrapFrame @ ffffe480`e018eb00)
00000000`fb5fe128 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 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.


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
# Child-SP RetAddr Call Site
00 ffffe480`e018d908 fffff801`3b82eb7c nt!KeBugCheckEx
01 ffffe480`e018d910 fffff801`3b97b98e nt!KiDispatchException+0x23c
02 ffffe480`e018dfc0 fffff801`3b979e57 nt!KiExceptionDispatch+0xce
03 ffffe480`e018e1a0 fffff805`f2dda7df nt!KiPageFault+0x217
04 ffffe480`e018e330 fffff805`f2ddb92d NTFS!NtfsPreRequestProcessingExtend+0x4f
05 ffffe480`e018e420 fffff805`f240563d NTFS!NtfsFsdRead+0x1dd
06 ffffe480`e018e6a0 fffff805`f24034d6 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x18d
07 ffffe480`e018e710 fffff801`3b8404a5 FLTMGR!FltpDispatch+0xb6
08 ffffe480`e018e770 fffff801`3b8a5f42 nt!IoPageReadEx+0x265
09 ffffe480`e018e7e0 fffff801`3b8a5970 nt!MiIssueHardFaultIo+0xb6
0a ffffe480`e018e830 fffff801`3b891486 nt!MiIssueHardFault+0x190
0b ffffe480`e018e910 fffff801`3b979d72 nt!MmAccessFault+0xc96
0c ffffe480`e018eb00 00000000`572be790 nt!KiPageFault+0x132
0d 00000000`fb5fe128 00000000`00000000 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 ffffe480`e018d908 fffff801`3b82eb7c 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
fffff801`3b9704c0 48894c2408 mov qword ptr [rsp+8],rcx ss:ffffe480`e018d910=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
MinorVersion 00003ad7
KdSecondaryVersion 00000000
DirectoryTableBase 00000001`6c054000
PfnDataBase ffffd880`00000000
PsLoadedModuleList fffff801`3bb505e0
PsActiveProcessHead fffff801`3bb4a040
MachineImageType 00008664
NumberProcessors 00000008
BugCheckCode 0000001e
BugCheckParameter1 ffffffff`c0000005
BugCheckParameter2 fffff805`f2dda7df
BugCheckParameter3 00000000`00000000
BugCheckParameter4 00000000`49c8820f


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 00000000`49c8820f, 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
ffffe480`e018d92c 00000000 49c8820f

Now, this is just an introduction to processes, threads and the stack; there is much more to learn! Although, I hope this article provides enough information to help you with your debugging efforts. If you wish to learn more about stack, then I throughly recommend you read the CodeMachine article below.

Further Reading:

CodeMachine – Article – X64 Deep Dive
Internals of Windows Thread
Registers (x86)

Posted in Windows Internals, Debugging, WinDbg | Leave a comment

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
Updates........: 0
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

Irp worker threads (PopIrpThreadList - fffff80088165a10)
THREAD: ffffd40e710c1040 (static)
THREAD: ffffd40e710d7040 (static)

Broadcast in progress: FALSE

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
0 e1 ffffd40e73f2ce40 00000000 fffff80b8707f3e0-ffffd40e74a431a0 Success Error Cancel pending
\Driver\ACPI ndis!ndisWaitWakeIoCompletion
Args: 00000005 00000000 00000000 00000000
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
fffff80b`88c00000 fffff80b`88c61000 mt7612US (no symbols)
Loaded symbol image file: mt7612US.sys
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.

Posted in Uncategorized | Leave a comment

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:     00000000`56706353
  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
fffff80f`55270000 fffff80f`5527e000   ScpVBus  T (no symbols)           
    Loaded symbol image file: ScpVBus.sys
    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
 # Child-SP          RetAddr           Call Site
00 ffffd801`60fb70f8 fffff802`7bdf803f nt!KeBugCheckEx
01 ffffd801`60fb7100 fffff802`7b8d9cef nt!VerifierBugCheckIfAppropriate+0x6b
02 ffffd801`60fb7140 fffff802`7bdef8b0 nt!VfReportIssueWithOptions+0x103
03 ffffd801`60fb7190 fffff802`7be05b3a nt!VfCheckPoolType+0x90
04 ffffd801`60fb71d0 fffff80f`5527b048 nt!VerifierExInitializeNPagedLookasideList+0x5a
05 ffffd801`60fb7250 ffffa60f`94f55410 ScpVBus+0xb048
06 ffffd801`60fb7258 00000000`00000000 0xffffa60f`94f55410

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

1: kd> ub fffff80f`5527b048
fffff80f`5527b027 53              push    rbx
fffff80f`5527b028 637056          movsxd  esi,dword ptr [rax+56h]
fffff80f`5527b02b 488d0d4ea3ffff  lea     rcx,[ScpVBus+0x5380 (fffff80f`55275380)]
fffff80f`5527b032 4533c9          xor     r9d,r9d
fffff80f`5527b035 4533c0          xor     r8d,r8d
fffff80f`5527b038 33d2            xor     edx,edx
fffff80f`5527b03a 48c740d818000000 mov     qword ptr [rax-28h],18h
fffff80f`5527b042 ff15d88fffff    call    qword ptr [ScpVBus+0x4020 (fffff80f`55274020)]
Posted in Uncategorized | Leave a comment

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.




Posted in Debugging, WinDbg | Leave a comment

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.


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!).




Posted in Uncategorized | Leave a comment