Debugging Stop 0x7A - KERNEL_DATA_INPAGE_ERROR

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 what it consists of, note that storage stack is a layer of drivers. The Partition Manager and Volume Manager both have drivers related to them, which are partmgr.sys and volmgr.sys.

Let's speak about the different types of driver, we have in the lower half of the storage stack, and whereby the problem is most likely to arise from:

• Class: These types of drivers conform to the standards set by Windows, and and help implement I/O processing for a particular type of device, in this case it supports I/O processing for hard disks. The Class driver can support a wide range of different manufacturers. Disk.sys is a example of a Class driver.
• Port: This drivers are written by Microsoft since the driver documentation for these, this is not freely available, therefore you will not find any of the routines used by these drivers on any official Microsoft sites. The I/O Request here is specific to that type of port. Ataport.sys is a example here. Port drivers are more a .DLL, since they provide support functions for Miniport developers, in order to avoid bugs and to allow to focus on more of the hardware logic.
• Miniport: These drivers are produced by third-party developers, and use the functions provided by the Port driver. These drivers help send the I/O Request to a specific port or adapter.

 A problem can happen anywhere on the storage stack, which leads to the bugcheck we're speaking about in this blog post. However, in order to work out where the problem with the storage stack had happened, we need to gather some more information. Parameter 2 is of greatest interest, since it provides a I/O error, these can be found on the MSDN page for Stop 0x7A.

Master File Table:

The user reported a message indicating that the MFT was corrupt and couldn't be read. This leads me to believe the problem found in the storage stack is related to the file system. Let's investigate further into what is the purpose of the MFT and it's general structure.

The Master File Table maintains and tracks all the files on our hard disks, including itself. It maintains information about the file attributes, file size, date of creation and even data content. The MFT grows in size as more entries (and files are created), however, bear in mind that this space is not deallocated from the MFT, instead the old MFT entries are left empty and can be reused. Each volume has a MFT, and the space which is allocated for the MFT by the System is called the MFT Zone.

References:

NTFS Master File Table (MFT) 

Master File Table (Windows)

NTFS - Wikipedia