flynn017

Firstly, thanks to YoYo155 , for asking his friend about flipped bits and Segmentation faults. If the flipped bit is occurring within the exact same register consistently, then it's a problem with the CPU for sure, and less likely to be associated with the motherboard or PSU. If flipped bits are happening in different registers, then the problem is most likely to be associated with the ALU, which also means the CPU is at a fault. The ALU stands for the Arithmetic and Logic Unit, and is used to perform arithmetic and other logic.

A user at Sysnative Forums, asked a interesting question, and in my attempt to answer the question. I also started to learn myself some information about misaligned pointers and segmentation faults (also known as access violations and bus errors). The thread can be found here - Misaligned IP - Sysnative Forums A posted a few links related to the question in my two posts answering that question. "A segmentation fault (often shortened to segfault ), bus error, or access violation is generally an attempt to access memory that the CPU cannot physically address. It occurs when the hardware notifies an operating system about a memory access violation." All the links to information about the specifics of misaligned pointers can be found in the thread. The main reason for this blog post, is because I think I've managed to relate a potentially bad CPU to Access Violation error within this dump file. The second parameter is the address of the exception record, and the third p...

Another debugging lesson, with a simple bugcheck, which is very similar to a Stop 0xD1 or Stop 0xA. Although, I'm sure this bugcheck only occurs with the use of Driver Verifier, but I may be wrong about this. The parameters are very similar to those of the Stop Code mentioned above, for instance we can see the memory address referenced and the type of operation being performed. This bugcheck is caused by drivers referencing memory addresses which already been freed, and therefore addresses which they do not own. The page fault may have resulted, since the driver has referenced a page which isn't committed to it's address space, which in turn would mean a access violation being raised. We can see that the page fault, resulted upon the memcpy function call, which is used to copy data between two different buffers or memory addresses. More Documentation Here - memcopy function Windows From viewing the call stack, we can see the klif.sys driver belongs Kaspersky, which is kno...

I've found a new interesting bugcheck which is commonly related to objects and handles. Please note before reading, this a Minidump file, and some of the extensions which you would use may not work in this example, unless you have a Kernel Memory dump available. Objects are system resources and managed by a sub system called the Object Manager. There are a range of different objects, and here's the complete list: Process - The 'box' of virtual address space in which thread objects execute and are controlled. Thread - Executable object for a process. Job - A group of processes connected to one object (More Information here - Job Objects (Windows) ) Section - A area of shared memory. File - Opened file or I/O device. Token - Security privileges and properties for a process or thread. Event - Synchronization and notification mechanism. Semaphore - Synchronization mechanism which allows a certain number of threads access to a resource.  Mutex - Allows only one thr...

I've seen this bugcheck and it's parameter 403, becoming more common recently, and therefore thought I would share how I go around debugging the problem. Stop 0x1As rarely tell us what the parameters actually indicate and substitute to, therefore we need to check some documentation provided by Microsoft on their WDK (Windows Driver Kit) on MSDN. Stop 0x1A Documentation - Bug Check 0x1A: MEMORY_MANAGEMENT "The page table and PFNs are out of sync . This is probably a hardware error, especially if parameters 3 & 4 differ by only a single bit." The above is the meaning for the first parameter of 403, remember to always check the first parameter, the other parameters are usually meaningless unless you probably work for Microsoft. So, in this example, we need to examine the binary representation of the two parameters and then compare their bits. We can use the .formats command to examine and compare the two parameters together like so:  The parameters differ greatly...

Hey everyone, I thought I'll add some information about the the internals mechanisms of Windows, in this example I'm going to write about the process working set and the basic management of working set. The process working set is the number of pages referenced by a process. The working set is the number of virtual pages which are currently in physical memory. By default, the minimum working set is 50 pages and the maximum limit is 345 pages for a single process. Although, these limits can be ignored, if the system has enough free memory. We can examine the current working set for a process by using the !process extension with either the Process ID or the process' address.  We see the current working set, and the working set maximum and minimum sizes. We can also see the page fault count for the current process and it's pool usuage.  With a page fault, the Working Set Manager must examine if the current pages are to replaced (trimmed) and sent to the disk, or additional ...

I've found a Minidump, in which I finally show the !pte extension, with this example a driver has attempted to execute a non-executable region of memory. Basically, a device driver has referenced a invalid memory address. The first parameter is the virtual address which was referenced by the device driver. The !pte shows the mapping between the virtual and physical memory address, the PDE is the address of the Page Directory Entry.  I've highlighted the PTE Status bits and Protection bits, and here is where I will explain what the currenty set bits mean: D (Dirty) - The page has been written to previously.  A (Accessed) - The page has been read. K (Kernel Mode) - The page has a Kernel Mode owner. W - The page is writtable and able to written to. E - The page is executable. V - The page is valid, and has a physical page corresponding to it. There are a few other PTE bits, which are not with this current example, although, I'll quickly explain them here: C = Copy on Write ...

Stop 0xC4 is a bugcheck produced when Driver Verifier finds a driver which violates one or more of it's current settings. The first parameter points to the type of violation, and in this example, the violation is the use of a invalid handle; a user-mode handle is being used within kernel-mode. A handle is very simply a reference to an object. An object is usually some kind of system resource, but for this example, the handle belongs to a process object. We can see the driver we caused the problem, but let's investigate further into dump file (please note this is a Minidump), the third parameter contains the address of the process which owns the handle. We can use the !process extension with the third parameter to gain some information about the process, and any associated threads owned by the process. We can view the working set for the current process (useful for Stop 0xF4), and also the currently associated thread. Here, we could use the !handle extension with the address o...

I thought I'll add a solved example for a Stop 0x101, to give you an idea of some the commands which are useful to use when debugging. Please note, I found that pending IRP packet with !irpfind extension, which finds all the IRPs for the system. Stop 0x101 - Solved   Hope you enjoy reading :)  

Hey everyone, I've got another Stop 0x9F example to show you, in this example I'm going to explain how to find the supported sleep states for a device and find the model of the hardware. I thought this would be especially helpful with the athrx.sys BSODs, since the looking up on the Driver Reference Table usually points to a generic entry. Firstly, we'll use the !devstack extension on the second parameter of the bugcheck. The !devstack extension will display the device stack for a associated device object. Remember parameter two is the physical device object. The > symbol points to the entry which matches the device object address used. I should also explain what a device stack is. A device stack is simply a list of device objects associated with a device node, each device object also has a associated a driver objects.  IRPs are usually processed by multiple device stacks. It's important to remember that a single driver object can have multiple device objects. A ...

This blog post is going to more of a link to a thread again, but I'm going to quickly explain the fields within the _POOL_HEADER data structure. Please note !pool and !pooval are explained in my Stop 0xC2 blog post. Stop 0x19 Example - With Stop 0xC5 and Stop 0xC2   Every pool allocation, has a data structure called the Header, this is used to store information about the pool allocation such as it's size, it's owner and the previous allocation before it within the linked list. The Block Size means the current size of the pool allocation. Previous Size contains the size of the previous pool allocation. Pool Tag is the owner of the pool allocation. You could use the !poolfind extension to find the allocation owned by that pool tag.