Monitoring ALPC Messages

Sunday, February 12, 2017

The Advanced (or Asynchronous if you prefer) Local Procedure Calls (ALPC) is the internal communication mechanism Windows components use as an inter-process communication (IPC) mechanism for message exchange. Conceptually, it's similar in principle to Remote Procedure Calls (RPC), with client and server ports, but does not use any networking, and is optimized for different message sizes. ALPC messages can reveal the hidden communication between various processes that are almost invisible otherwise. Conceptually, hooking ALPC messages is possible but not easy. First, the user mode and kernel mode APIs are undocumented. Second, hooking would likely involve all processes for which...
no comments

Using (Modern) C++ in Driver Development

Wednesday, November 30, 2016

When most developers think of writing a driver, they think of hard core C programming, with C99/C11 usage as a bonus - if they’re lucky. However, C++ can be used today in driver development, but not just for the ability to declare variables at any point in a function (available in C99 as well), but use more useful C++ features, both old and new, available with the C++ 11 and C++14 standards. In the kernel, there is no standard library nor C++ runtime library, which means most types used in user mode are simply unavailable, such as std::string, std::vector,...
no comments

Kernel Pool Monitor – the GUI Version

Wednesday, September 14, 2016

The Windows Driver Kit (WDK) comes with a well known and pretty old tool called PoolMon. PoolMon shows kernel allocations done with ExAllocatePoolWithTag, where the pool type is typically Paged or NonPaged and each allocations is attached by a ‘tag’ – a four byte value that should indicate the component making the allocation. This is useful for finding memory leaks, since kernel memory is never automatically freed (as opposed to user mode processes). If a kernel component or driver sees its tag with increasing memory consumption – that would indicate a leak (unless it’s a transient burst of allocations...
no comments

Using CLRMD to replace KD/CDB/NTSD and maybe WinDbg?

Thursday, May 14, 2015

I’ve been using the WinDbg low level debugger for several years now when things get hairy such as looking inside a .NET process and searching for memory leaks and other nasties. Or investigating a dump file, sometimes a kernel crash dump file (created because of the infamous “blue screen of death”), or when faced with a production system where Visual Studio does not (and will not) exist. Anyone who’s ever used WinDbg (or its equivalent console based debuggers – CDB, NTSD and KD) knows the feeling of wanting to get at some information but not always sure how...
one comment

Tip: Enable Kernel Debug output on Vista and up

Wednesday, December 17, 2014

Those writing device drivers, or are interested in seeing outputs from a kernel driver’s calls to the KdPrint macro or the DbgPrint function may find that the messages don’t appear on Windows Vista or newer versions of Windows. Even when using a tool such as DebugView (from SysInternals), running with administrative privileges, with kernel capture turned on, nothing seem to appear from expected drivers: The reason is that in Vista and up kernel output is conditional, based on some flags that can be set in KdPrintEx, DbgPrintEx, etc. A complete explanation can be found in the MS...

Creating a “WinObj”-like Tool

Wednesday, February 5, 2014

The SysInternals WinObj tool allows looking into the Object Manager’s namespace: The left view looks like file system folders, but in fact these are logical folders maintained by the Object Manager (part of the Executive within the kernel) purely in memory. I will not get into details about the information itself that is provided by the tool in this post. You can find some information on the web and the book “The SysInternals Administrative Reference”. How does WinObj gets the information? One obvious way is to use a driver – in kernel mode everything is...