Tracking Unusable Virtual Memory in VMMap

Tuesday, July 22, 2014

VMMap is a great Sysinternals tool that can visualize the virtual memory of a specific process and help understand what memory is being used for. It has specific reports for thread stacks, images, Win32 heaps, and GC heaps. Occasionally, VMMap will report unusable virtual memory, which is not the same as free memory. Here's an example of a VMMap report for a 32-bit process (which has a total of 2GB virtual memory): Where is this "unusable" memory coming from, and why can't it be used? The Windows virtual memory manager has a 64KB allocation granularity. When you allocate memory directly...
one comment

Diagnosing a Non-Paged Pool Leak with Asynchronous I/O

Thursday, February 20, 2014

I spent a few hours last week chasing a non-paged pool leak caused by a simple Win32 application. After some divide-and-conquer work, we were able to pinpoint the line of code causing the leak -- a seemingly innocent WSARecv call that performs an asynchronous socket receive. How can a user-mode application cause a non-paged pool leak that quickly accumulates to dozens of megabytes of kernel memory? Read on for the details. If you'd like to replicate this problem yourself and experiment with the diagnostic process described below, use the following gist. It's 54 lines of code including error handling and #includes. Capturing...
no comments

An Exercise in Virtual to Physical Memory Translation

Monday, September 23, 2013

In this post, we will explore virtual address translation through a real-world example. If you’d like, the instructions here should be sufficiently detailed for you to perform this experiment on your own, with a kernel debugger (a local kernel debugger session or even LiveKD is sufficient). Let’s start with the basics. For a great walkthrough of how memory translation works on x86-64 and x86, you should read Luke Hutchinson’s blog post. Alternatively, Windows Internals (6th edition) contains an even more detailed description of address translation in the Memory Manager chapter (volume 2). Now let’s go ahead and...
no comments

Windows Memory Manager’s Preferential Treatment of Access Faults in the Interlocked Singly Linked List Pop Implementation

Saturday, August 11, 2012

Special treatment is always a good thing, especially when you find that the kernel part of Windows gives preferential treatment to its user mode counterpart. Executive summary: It turns out that the Windows memory manager’s access fault handler, which handles the exception raised by the CPU when an invalid memory access occurs, has a special case for an expected access violation that might be raised when popping an item from an interlocked singly linked list (SList). The rationale for this special treatment is probably the prohibitive cost of setting up an exception handling frame in the popping function....
one comment

Baby Steps in Windows Device Driver Development: Part 6, Hiding Processes

Tuesday, August 16, 2011

Last time around, we’ve seen how to do something slightly useful in our driver. This time, we’ll simulate a technique used over ten years ago by Windows kernel rootkits to hide a process from tools such as Task Manager. First, some background: the Windows scheduler doesn’t need process information to run code. The scheduler needs access only to threads—threads ready for execution are stored in a set of ready queues. When a thread enters a wait state, the system tracks its information using _KWAIT_BLOCK structures, which again don’t require access to processes. Still, the system keeps track...

Baby Steps in Windows Device Driver Development: Part 5, Monitoring Processes

Saturday, July 2, 2011

The first remotely useful thing we are going to do with our newly acquired knowledge about device driver development is to register a callback for whenever a process is created, and output the information on the parent and child processes. (Frankly, this can be accomplished quite as easily using the WMI Win32_ProcessStartTrace event class, but bear with me here.) The PsSetCreateProcessNotifyRoutine function is a service provided by the process manager in the executive, which allows us to register a callback for when processes are created. This can be useful in the context of a security product, auditing software,...
no comments

SELA Developer Days 2011 – Windows Internals

Thursday, June 30, 2011

The SELA Developer Days conference has been adjourned :-) My one-day session today, titled Windows Internals for Busy Developers, was something I came up with a couple of months ago and was sure it wouldn’t be popular – after all, we have a five-day Windows Internals course and most people interested enough in the subject would want to attend the full training with labs, demos, and detailed walkthroughs of all Windows components. I was surprised to find 16 attendees in my class, all eager to learn about Windows architecture and components, diagnostic tools, kernel debugging, and internal...
no comments

Baby Steps in Windows Device Driver Development: Part 4, Kernel Debugging

Monday, June 20, 2011

Now that you have a driver running on the target system, it’s time to learn how to debug it if the need arises. In the first part, you configured the virtual machine for kernel debugging over a virtual serial port, and connected to the kernel debugging session using WinDbg. Familiarity with WinDbg commands for unmanaged debugging is a major plus here, but there are numerous new extension commands that are available only in kernel-mode which you will have to learn anyway. Commands you might need: bp to set a breakpoint ...
no comments

Baby Steps in Windows Device Driver Development: Part 3, Receiving IOCTLs

Friday, June 10, 2011

Now that we can compile, deploy, install and start a driver, it’s time for something more interesting. In this post, we’ll send controls to our driver from a user-mode application. To receive information from the outside, we need to teach our driver to respond to device I/O control codes (IOCTLs) which can be delivered to it from user mode using the DeviceIoControl Win32 API. We have already seen how our driver can tell Windows what the unload routine is using the PDRIVER_OBJECT structure. Handling IOCTLs is very similar, we just need to provide another routine or two. ...
one comment

Baby Steps in Windows Device Driver Development: Part 2, “Hello World” Driver

Saturday, June 4, 2011

In this installment, we will compile and deploy our first driver. You should have all the tools installed already. Windows device drivers are reactive programs—all they really do is respond to events, somewhat similar to GUI programs. The kinds of events drivers recognize include: Loading the driver into memory and unloading it from memory Adding a new hardware device for which the driver is responsible Transitioning to a power-savings mode Reading and writing from a device Handling an...