flynn017

This blog has really grown, especially during this month, it's been late nights after the pub and work and even college, just staying up and trying to write as much information as possible (whilst being concise and to the point), since I have so many ideas and topics I would like to write about. Anyway, I hope you enjoy reading my blog so far, and I hope it's helped you understand debugging a little more, and turn that at first glance alien language of memory addresses and WinDbg commands into something more understandable. Thanks for the support, and please keep reading my blog, and leave a comment or two, if I've made a mistake somewhere or you would like to have a certain topic added.

Okay, in my last blog post we discussed the theory of stacks in general, mostly referring to user stacks. In this blog post, I'm going to explain the different kinds of stacks available to the operating system. A thread consists of a user stack and a kernel stack. Firstly, we'll talk about user stacks, since these are more simple, and we've focused on these more in the last blog post. User Stacks We know when a thread is created, the Memory Manager reserves about 1MB of memory to the stack. We should also know that the stack isn't committed straight away, that is, the stack grows when local variables and function calls are created or called within the program. Only around 64KB of memory is initially committed to the stack. When the stack grows, and touches the Guard Page it expands, and part of the reserved region of the stack is committed to the stack. This should be a simple remainder of stacks discussed in my last blog post. Remember that user stacks will not shrink ...

Basic Concepts: The title could probably be called Stack Expansion or Stack Growth, depending upon how you like to name it. A thread stack is used to store information such as function parameters, function return addresses and local variables. It is allocated from virtual memory. A stack isn't committed fully straight away, instead portions of virtual memory are committed when needed, and the rest of the virtual memory allocated to the stack is reserved. Stacks have certain limits, and this how stack overflows are caused. A stack begins to use virtual memory outside of the reserved region.   When a stack begins to grow or expand, then it will access the Guard Page. Once the Guard Page has been accessed, then the amount of committed memory to stack will grow. The diagram illustrates this point. Notice how the Reserved level of memory has reduced in size?     KeExpandKernelStackAndCalloutEx and KeExpandKernelStackAndCallout can be used to expand a stack. Check the WDK docum...

This blog post for a continuation of thread scheduling as discussed in my previous blog post, although in this blog post I'm going to explain the concept of Quantum and Boosts. These both are deciding factors for thread scheduling. Thread Quantum A thread quantum is the amount of time a thread is allowed to execute for, before Windows interrupts the thread and lets a different thread of the same priority level run and execute. A thread can run for another quantum, if there are no other threads at that priority level. A thread quantum is around 2 clock intervals, and is governed by the HAL. We can check the length (in milliseconds) of a clock interval with the ClockRes program. Threads do not run based upon clock intervals, this is translated into a the number of clock cycles in a quantum, and is stored inside the variable called KiCyclesPerQuantum . Threads run for a Target Quantum which is the the number of clock cycles passed before the thread should stop executing. The Target...

The next few posts, or maybe this post if it doesn't get too large, will concern the matter of thread scheduling and priority levels. It will support perfectly the topic of interrupts and synchronization mechanisms which I've explained in the past. Priority Levels Each thread has it's own priority level and thread state. There are currently 32 different thread priority levels, which range from 0 to 32. The higher the priority, the more likely it is to run before any lower priority threads. You will need to also consider the concept of a Quantum, a Quantum is the amount of time a thread is allowed to run, before a thread of the same priority is scheduled to run. This system prevents errors like hangs and deadlocks. Remember higher priority threads can still interrupt lower priority threads, they take no consideration of a thread's quantum. The priority levels we are most interested in, are the variable or dynamic levels (1-15), since these are mapped for the use by the ...

I've seen this instruction cause problems quite frequently in the past, but I was still very new debugging then, and didn't know exactly what it was. The instruction isn't easy to find with a Google search, you'll have to download the Intel Developer's Manual, if you haven't done so, then there is a copy available on my SkyDrive . By looking at the parameters, we can see the type of exception which has happened is a Access Violation and the address of the instruction which caused the exception points to the xrstor instruction. This is also a x64 operating system, and thereby will have a x64 processor. We can see this in the dump file with the vertarget command. Now. let's dump the context switch and the exception. The call stack didn't reveal to me, apart from exception handling routines. The raw stack did in fact reveal a AMD/ATI graphics card driver.  Okay, we now have a possible candidate of why the instruction may have been used incorrectly. Howeve...

Overview: This bugcheck largely concerns the storage stack and the hard-drive or file system. I'm going to explain the aspects of the storage stack and the file system, and also a particular error message which a user has just had. I'm also currently downloading a 'real situation' Kernel Memory dump which is hopefully a Stop 0x7A, so this post may be edited later too. With these kind of bugchecks, you'll be lucky to have a dump file saved as a result of the nature of the problem. I'm just going to explain how it's caused and some of the methods we can be used to troubleshoot the problem. Generally, this bugcheck is caused by a serious virus infection or failing HDD/SSD and/or a corrupted filesystem. In a single sentence, the kernel wasn't able to page data from the page file stored on the hard-drive back into physical memory, as a result of a problem with the storage stack.  Storage Stack:   The above diagram illustrates how the storage stack looks and...