Identify the User-Mode Drivers Loaded into a WUDFHost.exe Instance

Friday, February 8, 2013

Once upon a time, it was fairly challenging to determine which services were running in an individual svchost.exe process. Today, with Process Explorer, there’s nothing easier – just hover over the svchost.exe process and you get a list of services, or double-click an svchost.exe process and go to the Services tab: A similar problem can arise with user-mode drivers (UMDF). User-mode drivers are COM DLLs loaded into WUDFHost.exe processes, and some WUDFHost.exe processes may contain more than one user-mode driver. Process Explorer does not help in identifying which user-mode drivers are loaded into a WUDFHost.exe process,...
one comment

Developing Device Drivers in Studio 11

Saturday, November 26, 2011

Another piece of great news delivered at //build/ has to do with device driver development. Coincidentally, a few weeks ago I posted a series of baby-steps with Windows driver development, and if you’ve read some of that you’d notice that the driver dev work is very different from application development – you use a different build environment, you deploy drivers manually, and you debug them with a different debugger. This story changes, however, with Visual Studio 11. You can now build drivers in Visual Studio, deploy them to test machines automatically, and debug (in kernel-mode!) using the Visual...

Open Kernel Crash Dumps in Visual Studio 11

Friday, October 14, 2011

A dream is coming true. A dream where all the debugging you’ll ever do on your developer box is going to be in a single tool – Visual Studio. In a later post, I will discuss device driver development in Visual Studio 11, which is another dream come true. For now, let’s take a look at how Visual Studio can open kernel crash dumps and perform crash analysis with all the comfy tool windows and UI that we know and love. To perform kernel crash analysis in Visual Studio 11, you will need to install the Windows...

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

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. ...

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...

Baby Steps in Windows Device Driver Development: Part 1, Install the Tools and Configure Kernel Debugging

Monday, May 30, 2011

As part of the Windows Internals course at SELA, I recently designed a set of exercises that serve as an introduction to Windows device driver development. Their purpose is to obtain a very cursory familiarity with what it means to build, deploy and load a driver, and consider some of the things available to kernel-mode components which make them way cooler than user-mode applications. Some of this work can be turned easily into a series of blog posts, which you can enjoy outside of the course’s context. However, if you’re looking for background on Windows subsystems and components,...
one comment