flynn017

Okay, here's another debugging example which has quite a simple methodology, a driver has returned to User-Mode while the IRQL Level was above PASSIVE_LEVEL or Level 0. The first parameter indicates the IRQL Level of the processor, in which in this case is Level 2 or DISPATCH_LEVEL. The first parameter indicates the address of the system call in which the driver has returned from. The main point to remember is that all threads which run in User-Mode run at the IRQL Level of 0, this is ensure that no User-Mode thread has a higher interrupt priority than any Kernel-Mode threads. In case, you wondering which cases a User-Mode application may need to call into Kernel-Mode, a good listing of examples can be found here - User-Mode Interactions: Guidelines for Kernel-Mode Drivers The stack does not reveal much, apart from this: The stack simply reveals a function in User-Mode calling the nt!KiServiceExit2 routine, which is a internal Kernel routine. The use of dd command in a stack can...

This is going to be my first little post on about how to use some of the features of Process Explorer , which is a very useful tool to have if you understand how to use it properly. If you understand how objects and handles work, then you may skip this paragraph and read the rest of the blog post, however, if you wish to gain a brief understanding on how objects and handles work then please continue reading. I will not be explaining how objects work completely, since this is quite a lengthy topic, although, I may explain objects in more detail in the future. Objects are basically System Resources, and handled by the Object Manager, we can also see with the WinObj Sysinternals Tool. Each object also maintains a handle count, which is number of open handles or active references to that object from processes. A object can only be destroyed, once all the handles to that object have been closed. Open WinObj, and then click File and then Run As Administrator. Select the Object Types fold...

Okay, linked lists are used often in Windows and are usually part of larger data structures. They are typically seen with the Windows Debugger (WinDbg) with the name of _LIST_ENTRY . This indicates a linked list data structure, or more specifically the list head of a linked list which contains information such as the Flink and Blink pointers.  Here is some example output using WinDbg: The data types being used here are 32-bit pointers , which is defined as follows: This is stored in the BaseTsd.h header file. For non-programmers or those who are simply interested, the #define preprocessor statement is used to substitute a identifier for something which shorter or easier to read. Here's a very simple example which I wrote myself: Getting back to the point, I started a discussion a while ago about Flink and Blink addresses, and what they meant on Sysnative - Understanding Flink and Blink Free-Lists (Stop 0x19) If you ever see, the parameters of the Flink and Blink Free List, and the...

We all know that Stop 0x124 contain very little practical information to work with, the stack consists of WHEA reporting routines and many commands have no significance to a Stop 0x124. The first thing to look at with a Stop 0x124 is the clock speed of the processor, generally a overclocked processor will mean that the user has most likely overclocked their GPU or RAM, and also changed the voltage settings. However, the !sysinfo cpuspeed extension does not always work like below: This is quite annoying, but there are other ways to view the clockspeed of a processor, we can see the !prcb extension to view the Processor Control Block, which is a private kernel data structure used to store thread scheduling information; DPC queue, detailed CPU vendor information and cache sizes etc. Using the !prcb extension doesn't provide much information, but using the address fffff780ffff0000 with the _KPRCB data structure will provide some very detailed information. Please be aware that not sp...

In a previous blog post , I explained some of the exception codes which are stored within a data structure called the Interrupt Dispatch Table, we can be viewed with WinDbg using the !idt extension. Here I would like to breifly explain how the Interrupt Dispatch Table works.  We can gain further information from each interrupt, when using the dt nt!_KINTERRUPT command, which will give you the following prototype: Drivers will use the IoConnectInterruptEx API, to provide a pointer to the above data structure, when registering a ISR for that device. Hardware interrupts are handled by a interrupt controller which then interrupts the CPU, and the CPU then reads the IRQ to match the request to the appropriate interrupt number. Most CPUs use a APIC interrupt controller, rather than the older PIC controller. You can attempt to use the !pic and !apic extensions to see which one you are using; only one extension will work. Furthermore, interrupts are serviced by a routine called a Inter...

It's Monday morning, and my week is going to be very busy, so I thought I'll write a small and simple blog post today. Kernel Data Structures contain lots of useful information when debugging, but it's understanding which data structures correspond to what situation and dump file and how to open these data structures. I highly recommend checking this website out for Kernel Data Structures and some debugging examples, it's such a excellent resource - Code Machine Articles - Kernel Data Structures Some of the data structures which are available in WinDbg are available on the Windows Driver Development Kit documentation. Okay, the dt nt!_* command lists all the available data structure prototypes, which WinDbg can open and format for you to understand, I find this especially useful for learning which data structures are relevant and what additional information they may contain. The above screenshot is only partially the output of the command, but due to size limitations...

I think this may be the one example of the a user-mode program, actually being the sole cause of a BSOD. While it's technically impossible for a user-mode program to cause a BSOD directly, it can be possible for a user-mode program to cause a kernel-mode driver to act in a manner which would cause a BSOD. In this case, the a user had downloaded several cracked games (which contained infected files), I even gave a warning that cracked games tend to be malware, and it looked like I was exactly right. So, lets begin: one of the games had a application error which I opened with Visual Studio, it indicated that a thread attempted to access a virtual address which it didn't have access to. It's most likely kernel address space in my opinion, I may check this later.  As soon as, I noticed this it gave me assumptions that the game(s) are most likely malware, since I already established with the user they were cracked, and they were in full acknowledgment of this too.  Looking at th...

A Stop 0xCA usually indicates something is wrong with the PnP Manager or a driver/device which has a device node within the PnP Manager's Device Tree. To keep this blog post manageable (I've read through three different pages of Windows Driver documentation), I'll add the relevant links to those pages if I can. The significant things to look at in this dump file, are the call stack and the driver object associated with the PDO (Physical Device Object) . We can there is something wrong with the PCI bus or a device connected to that bus by just opening the dump file: Let's get a overview of the nature of the dump file with: The most important page you will want to start with is this one - IRP_MN_QUERY_DEVICE_RELATIONS We can see a driver has deleted a PDO which has already been deleted, I found the wording of the error to be quite difficult to be honest. I decided to look into the supported dispatch routines (IRPs) which the driver object could handle with the !drvobj e...

Okay, I understand this blog post, isn't exactly related to BSODs but since this BSOD Analysts since to have to debug other errors too then I would I would write a blog post about this error which isn't exactly an error as such. As a result, of some of the misinformation I've seen on other forums about this issue, for example editing the registry DWORD value for the MaxFileSize key, since they believed it was a problem with Windows not being to able to save files above 0. I thought it would be necessary to explain what this error is related to. Firstly, open your registry, by clicking Start and then entering regedit. Accept the UAC prompt (if shown), and then navigate to the following registry key - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\Autologger\Circular Kernel Context Logger\MaxFileSize   You should see a set of key similar to the above picture.  A DWORD is a Windows API data type, and is a unsigned integer for those who know or are interested in progr...

Microsoft should have hopefully updated their symbol servers on Wednesday 16th October , although, some BSOD debuggers are still reporting problems with the symbols. I know, some dump files do have symbol errors occasionally, but if your getting a large amount then I would contact Microsoft. I've also been very ill for the last few days due to a very contagious stomach bug, so I haven't been presence at all in the online world for the last few days.

In one my previous blog posts, I wrote about Segmentation Faults , although, I didn't give much explanation to what a segment was and how it is used within the translation process. Memory segmentation is the method of dividing the computer's primary memory into segments, each segment will contain two parts which I'll attempt to explain later. Memory segmentation is one of the protection mechanisms which can be used to restrict access to certain areas of memory. It's important to understand, that the CPU can only understand machine instructions (binary), and that higher level languages are simply used for programmers to be able to write large and complex programs without much difficulty. The language above machine code is called Assembly, which enables programmers to create very fast and small programs to perform very specific tasks. It's important to remember that  programs can only use virtual memory (logical addresses), which have to be translated into physical...

Okay, the 8th of October saw many security updates delivered through Windows Update onto our systems. As a result of this, the timestamp for the NT Kernel may changed, and therefore has left the symbols currently on the Microsoft Server outdated, leading to the symbol errors we have been seeing. If I've read correctly, users' dump files who have not yet updated will show no symbol errors , and users who have updated will show symbol errors; this is not to say don't install the latest security updates, please do so if you haven't, but for BSOD Analysts I believe Microsoft should be updating their symbol server soon. Source - http://www.sysnative.com/forums/bsod-processing-apps-download-|-information-|-discussions/7359-ntoskrnl-exe-nt-kernel-symbol-errors-windbg.html

Stop 0x109's are not that frequent, but they do not provide much information to work with. Stop 0x109's are generally caused by driver modifying kernel code (Kernel Patch Protection detects this) and kernel code held within RAM has become corrupt (failing RAM modules). The purpose of this blog post, is mostly going to be explaining a little of Kernel Patch Protection and regions of the kernel which have been modified and are displayed within the bugcheck parameters. With a Stop 0x109 bugcheck, there is four different parameters, the only parameter in which you'll want to view is the fourth parameter which shows the corrupted region. The other parameters are undocumented and reserved for Microsoft use. The three parameters which I'll attempt to explain are: MSR, GDT and IDT. MSRs (Machine State Registers): Handlers for special instructions used for system calls. More Information - MSRs IDT (Interrupt Descriptor Table): A table which contains a list of ISRs and which in...

STPD.sys is a driver which is part of Daemon Tools and the Alcohol products, this driver is well-known to cause problems and should be removed. In this example, I wanted to demonstrate the usefulness of searching Windows Driver API documentation and look at the types of drivers which are known to cause Stop 0x24 bugchecks. The second parameter usually refers to the exception record and the third parameter usually refers to the context record, you can use the .exr and .cxr debugger commands to gain information from these parameters. We can see that the instruction which caused the access violation was nt!FsRtlLookupPerFileObjectContext which is documented within the Windows Driver API.     FsRtlLookupPerFileObjectContext , is used by filter drivers to receive the context of a previous file object; a file object can refer to an actual file or physical hard disk. The IRQL level is fine here, so no functions were being called at the incorrect IRQL level. From another bugchec...

Here's the list of prefixes for the Windows API function calls you may notice within a call stack. Please also be aware that i means Internal and p means private. Alpc = Advanced Local Inter-Process Communication Cc = Common Cache Cm = Configuration Manager Dbgk = Debugging Framework for User-Mode Em = Errata Manager Etw = Event Tracing for Windows Ex = Executive support routines FsRtl = File System driver Run-Time Library  Hal = Hardware Abstraction Layer Hvl = Hyper visor Library Io = I/O Manager Kd = Kernel Debugger Ke = Kernel Lsa = Local Security Authority Mm = Memory Manager Nt = NT System Services Ob = Object Manager Pf = Prefetcher Po = Power Manager Pp = PnP Manager Ps = Process Support Rtl = Run-time Library Se = Security Tm = Transaction Manager Vf = Verifier (Driver Verifier) Whea = Windows Hardware Error Architecture Wmi = Windows Management Instrumentation Wdi = Windows Diagnostic Infrastructure Zw = Similar to NT, but sets access mode to Kernel, which in turn elimin...

Okay, we all know that Stop 0x124's are very generic and irritating bugchecks since they don't provide much information at all to be honest. Although, this can be made easier by following reading the error mnemonics within the CPU documentation, which will provide further insight into how the error was caused. I actually learned this in I think it may have been one of Vir's quotes in one of YoYo's posts, so thanks for providing information on where to find the documentation. You will want to download the .PDF file of Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3: System Programming Guide , and then turn to page 2352. Here you will find the error mnemonics for the type of error, remember we can find the type of error and then decrypt it's meaning by using the !errrec extension with the second parameter of the bugcheck. Due to size limitations in which the Snipping Tool can expand to, I've taken a screenshot of  the relevant part of t...