flynn017

Another memory corruption related bugcheck, but this time, it related to the use of the Special Pool option available within Driver Verifier. MSDN Blogs (NT Debugging) wrote a excellent article explaining Special Pool, and how it works which I've added to a blog post for this month, so I would highly recommend checking that article out before reading this blog post to have a full understanding of Special Pool and Slop Bytes.  The first parameter is what we are most interested in, this the address which was attempting to freed, but was picked up by Driver Verifier due to the single bit corruption within the Slop Bytes region. Firstly, let's examine the pool page in which the address belonged to with the !pool extension. We can see the pool page is obviously corrupted, but let's investigate further with the !poolval extension on the suggested address provided by the dump file. Let's look even further with the _POOL_HEADER data structure: Okay, we can clearly see that th...

Okay, each time I come across a Stop 0x4E, it always seems to point to memory corruption and the last instruction being the MiBadShareCount line. By the way, I've learned that Mi prefix most likely means Internal Memory Management/Manager. I'll take into consideration, that you would know that are different fields depending upon the PFN Data Structure being used by the operating system, and from my understanding, the above example applies to PFNs being used for a page part of a working set for a process. For those, who do not know what working set is, it is simply the number of virtual pages present in physical memory for one given process. It is important to remember that software uses virtual memory pages, and these are simply translated into physical addresses by the MMU. On a side note, I'm still trying to find out what page states the numbers reference, so if anyone knows then please post a comment on this post. Anyway, back to the point, we can see with this bugcheck...

This is going to be a very simple blog post, listing how to view all the DLL extensions you have loaded and how to list all the extensions available from that DLL. Firstly, let's start with the .chain command which part of WinDbg. The .chain simply lists all the loaded DLLs for that dump file, when clicking the link (in blue ), we can see all the available extensions from that DLL. As an example, I've used the CMKD.dll: We can gain further information about those listed commands by typing !CMKD.help : The .help command lists the help information for all the commands for WindDbg , clicking the links will produce help specific to all the commands listed under that letter. Here's U as an example:

A Stop 0x74 is usually related to registry corruption, especially the System hive, whereby all the system configuration information is stored. Although, this bugcheck can be related to the wrong file permissions set for a registry file , and RAM corruption. The only useful parameter and information I found I could gather from this dump file, was by using the !error extension with the fourth parameter, which should produce something like this: "Error code: (NTSTATUS) 0xc000014c (3221225804) - {The Registry Is Corrupt}  The structure of one of the files that contains Registry data is corrupt, or the image of the file in memory is corrupt, or the file could not be recovered because the alternate copy or log was absent or corrupt."  

Note: Before reading this article, please take into consideration this is a old dump file, and the cause of the crash was due to a bug in Windows 8, which Microsoft have now released a fix for, which can be downloaded here - http://support.microsoft.com/kb/2778344 We can see this dump file originates from a Windows 8 system, by using the vertarget command we can gain some useful operating system information. Another side note, I would like to add with this bugcheck, is make sure you also update your graphics card drivers and the list of installed of Windows Updates/Hot Fixes can be found within the SystemInfo.txt file. I would like to explain briefly, what Session Space is, and how it related to this bugcheck. This address space is area of memory assigned to one particular session, and is shared by all the processes within that particular session space. A session is simply all the processes running within that user's logon. Each session is given a Session ID which helps identify ...

Here's a another custom made .DLL, I've actually had this library for a while now, but I've only just remembered it, so you may see this used in the future too. CodeMachine Debugger Extension DLL (CMKD.dll) If you don't understand how to load a custom .DLL, please read this post here -  Loading Custom Debugger Extensions - !load and !dpx

Andrew Richards has developed a really custom .DLL, with some really nice debugger extensions for us debuggers to test out and use with dump files. The only one. I've used so far is the !dpx extension, which dumps all the useful information from a raw stack. This extension is going to replace the !thread and then dps method. Firstly, you need to download the .DLL from SkyDrive , and unzip the folder. Once you have download and unzipped the folder, navigate to your appropriate operating system architecture, either x86 or x64, and then copy the .DLL . I'm not sure what the other folders contain as I haven't watched the Defrag Tools video yet. Once copied, you will need to paste the .DLL into this folder (follow these instructions below): C:\ or the partition you have Windows installed on > Program Files > Windows Kits > 8.0 (dependent upon version) > Debuggers > x86 (or x64) Paste the file into that folder, and then accept the UAC prompt. You will then nee...

There's a nice article explaining the arrangement of special pool on the NT Debugging website, and I thought I would share it with my readers - Understanding Pool Corruption Part 2 – Special Pool for Buffer Overruns

This blog is most likely, going to be more of me attempting to explain relocation and the relocation fix up table. The first parameter indicates that image relocation fix-up table has become corrupt, the image relocation table is a table of pointers for a program, which are used to assign memory addresses to parts of the program. Each pointer is called a fix-up. Pointers are basically used in programming, to assign or use memory addresses in programs. The MSDN documentation points out, that this issue is more hardware related, and therefore the only valid reasons I could think of are - corrupt memory addresses are being assigned or maybe the MMU wasn't translating virtual pages to physical pages, resulting in invalid memory addresses.

I thought I'll debug a Stop 0xFE tonight, which is usually related to problems with USB device drivers. I tend to stay away from Stop 0xFE's, as a result of my experience with them, when I first started debugging, but I'm going to start taking them on again. We need to firstly check what the parameters correspond to, by checking the MSDN site and checking the references for this bugcheck.   Checking the documentation provided, we can see that the bugcheck happened, as a result of the driver waiting for a suspend-port request to complete. With this bugcheck, I would check the USB driver timestamps with the lmtsm command, and then update the drivers. I would additionally recommend turning off USB Port Suspension .