Rubato and Chord

Vector Deleting Destructor

Reiley Yang — Thu, 09 May 2013 14:24:00 GMT

Today one guy in my team asked a question regarding the behavior of delete[] operator in C++ - how does the program know it needs to call CBar::~CBar instead of CFoo::~CFoo?

Note that the vector deleting destructor is a feature in Microsoft C++ Compiler, not required by the C++ standard.

#define _CRTDBG_MAP_ALLOC
#include <malloc.h>
#include <crtdbg.h>

class CFoo
{
public:
  virtual ~CFoo() = 0;
};

class CBar
{
  virtual ~CBar()
  {
    _CrtDbgBreak();
  }
};

void __cdecl main()
{
  CBar* p = new CBar[1];
  delete[] (CFoo*)p; // what does this mean?
  _CrtDumpMemoryLeaks();
}

Well the short answer would be - how does virtual destructor work and how does the program know the actual number of elements in the array?

If you've spent time on understanding the object layout in C++ and COM, you would know that virtual functions are backed by vtable, and it will not be too difficult to understand BSTR.

So we are ready for the answer - delete[] is a combination of BSTR and virtual function.

CBar::`vector deleting destructor':
000007F7CD2E1140  mov         dword ptr [rsp+10h],edx  
000007F7CD2E1144  mov         qword ptr [rsp+8],rcx  
000007F7CD2E1149  sub         rsp,28h  
000007F7CD2E114D  mov         eax,dword ptr [rsp+38h]  
000007F7CD2E1151 and eax,2
000007F7CD2E1154 test eax,eax
000007F7CD2E1156 je CBar::`vector deleting destructor'+5Eh (07F7CD2E119Eh)  
000007F7CD2E1158  lea         r9,[CBar::~CBar (07F7CD2E1120h)] ; the address of CBar::~CBar 
000007F7CD2E115F  mov         rax,qword ptr [this]             ; this pointer  
000007F7CD2E1164  mov         r8d,dword ptr [rax-8]            ; array size *((size_t*)this - 1)  
000007F7CD2E1168  mov         edx,8                            ; sizeof(CBar)  
000007F7CD2E116D  mov         rcx,qword ptr [this]             ; this pointer  
000007F7CD2E1172  call        `vector destructor iterator' (07F7CD2E1220h)

As you can see here, the vector deleting destructor was emitted as a virtual function in vtable, it takes a flag parameter, if flag & 0x2 equals to true, the actual function vector destructor iterator would get called.

The size of array was stored using the BSTR approach, passed in via the r8d register.

The callstack from Visual Studio Debugger also tells us the same thing:

crtdbg.exe!`vector destructor iterator'(void * __t, unsigned __int64 __s, int __n, void (void *) * __f)	C++
crtdbg.exe!CBar::`vector deleting destructor'(unsigned int)	C++
crtdbg.exe!main() Line 22	C++
crtdbg.exe!__tmainCRTStartup() Line 536	C
crtdbg.exe!mainCRTStartup() Line 377	C
kernel32.dll!BaseThreadInitThunk()	Unknown
ntdll.dll!RtlUserThreadStart()	Unknown

Regarding the actual meaning of the flag I mentioned, I'll leave it as a homework for the readers (hint: you may try out the DGML tool).

Undocumented Environment Variables

Reiley Yang — Wed, 08 May 2013 14:09:18 GMT

Although we have less Easter Eggs, there are still a huge number of undocumented behaviors.

Recently I'm writing a CLR profiler using ICorProfilerCallback for fun, the CLR profiler was modeled as an in-proc COM server, and the activition was done through environment variables:

SET COR_ENABLE_PROFILING=1
SET COR_PROFILER={XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
SET COR_PROFILER_PATH="C:\FOO\BAR\MyProfiler.dll"

Immediately I realized there must be a lot more environment variables, and it was a perfect time to use WinDBG:

cdb.exe -hd -g -G -xi ld -xe cpr -c "bu KERNELBASE!GetEnvironmentVariableW \"du @rcx; gc\"; g" "%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\csc.exe"

0:000> cdb: Reading initial command 'bu KERNELBASE!GetEnvironmentVariableW "du @rcx; gc"; g'
000007fe`581406f0  "SHIM_DEBUG_LEVEL"
000007fe`58140428  "SHIM_FILE_LOG"
000007fe`581406f0  "SHIM_DEBUG_LEVEL"
SHIMVIEW: ShimInfo(Complete)
(ba0.db8): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
000007fe`5c4eada0 cc              int     3
0:000> g
Microsoft (R) Visual C# Compiler version 4.0.30319.17929
for Microsoft (R) .NET Framework 4.5
Copyright (C) Microsoft Corporation. All rights reserved.

warning CS2008: No source files specified
000000a3`60e9c230  "COMPlus_Version"
000000a3`60e9c230  "COMPlus_InstallRoot"
000000a3`60e9b790  "COMPlus_InstallRoot"
000000a3`60e9c140  "COMPlus_DefaultVersion"
000000a3`60e9bad0  "COMPlus_InstallRoot"
000000a3`60e9b880  "COMPlus_InstallRoot"
000000a3`60e9b8a0  "COMPlus_3gbEatMem"
000000a3`60e9b400  "COMPLUS_CLRLoadLogDir"
000000a3`60e9b1d0  "COMPlus_InstallRoot"
000000a3`60e9b180  "COMPlus_NicPath"
000000a3`60e9b180  "COMPlus_RegistryRoot"
000000a3`60e9b180  "COMPlus_AssemblyPath"
000000a3`60e9b180  "COMPlus_AssemblyPath2"
000000a3`60e9ab80  "COMPLUS_InstallRoot"
000000a3`60e9ab40  "COMPLUS_DefaultVersion"
000000a3`60e9ab40  "COMPLUS_Version"
000000a3`60e9af60  "COMPLUS_ApplicationMigrationRunt"
000000a3`60e9afa0  "imeActivationConfigPath"
000000a3`60e9afb0  "COMPLUS_OnlyUseLatestCLR"
000007fe`51a06580  "APPX_PROCESS"
000000a3`60e9af60  "COMPLUS_BuildFlavor"
000007f6`2e5c16a8  "LIB"
error CS1562: Outputs without source must have the /out option specified

As we can see, the red parts are the environment variables used by Application Compatibility team for debugging a shim.

The blue parts are the environment variables used by COMPLUS, which was the original name for .NET.

Notice that there is guarantee of completeness using my WinDBG approach, since GetEnvironmentVariableW is not the only way to retrieve environment variables.

I'll leave a homework for the readers - find the envrionment variables consumed by the Visual Studio IDE (hint: you need to modify the command line to make it work under 32bit).

The Pit of Success

Reiley Yang — Sat, 27 Apr 2013 14:55:00 GMT

The Pit of Success: in stark contrast to a summit, a peak, or a journey across a desert to find victory through many trials and surprises, we want our customers to simply fall into winning practices by using our platform and frameworks. To the extent that we make it easy to get into trouble we fail.

- by Rico Mariani

In my self-introduction, I mentioned my past experience on developing ATL, CRT, MFC and STL. I've learned a lot from this experience, and as I work with people who develop services based on .NET platform, there are many interesting findings. Each time I stepped back and looked at things that have been developed, the more I love the "The Pit of Success" concept brought up by Rico Mariani. So here I'm trying to share some of my personal understanding.

ATL (not including ATL Server) is my personal favorite library for the following reasons:

ATL is a library instead of framework

in order to adopt ATL you don't have to change any existing architecture

ATL is lightweight

in most cases you can just use ATL header files, without dealing with *.lib files and DLLs
ATL won't bloat the binary size too much
ATL won't harm performance for sure

ATL is predictable

debugging through ATL source is straightforward
the main purpose of ATL is to make COM programming easier in C++, not to hide the complexity of the operating system concepts
the COM wrapper has a very clear definition on the thread safety

CRT is the library from which I learned a lot:

CRT acts as a bridge between the operating system and most applications

dealing with application startup and cleanup
providing runtime services (e.g. backing C++ exception scope with SEH and exception filters)
balancing between the underlying system implementation and the C/C++ standard specification

CRT has evil contracts with C++ compiler toolchain
CRT is not only consumed by normal applications, but also by operating system and compiler toolchain (which sounds like an infinite loop)
CRT always sits in the frontline of supporting new hardware architecture
CRT needs to be the most stable and compatible library

MFC is a framework consisting of class libraries:

it's easy to get started with MFC
MFC takes care of window management, messaging, COM and many great things
you really need to understand MFC in order to use it well, especially when you run into bug hell

STL is a C++ template library, which I've used extensively (in combination with Boost) when I was in school, when I developed STL and when I have good reason to use STL:

if I have a free choice, normally I would tend not to use STL
debugging template code is not easy, especially the code that makes extensive use of template meta-programming and macro meta-programming
running code coverage analysis against template code is tricky (source line coverage is almost meaningless, you have to use basic block coverage)
it's bad idea to pass (e.g. parameter, exception) STL objects across module boundary, since the underlying contract (e.g. object layout) might be different
binary size might bloat and turn into a serious problem

Error and Exception Revisited

Reiley Yang — Fri, 05 Apr 2013 14:18:00 GMT

Unless suffering is the direct and immediate object of life, our existence must entirely fail of its aim. It is absurd to look upon the enormous amount of pain that abounds everywhere in the world, and originates in needs and necessities inseparable from life itself, as serving no purpose at all and the result of mere chance. Each separate misfortune, as it comes, seems, no doubt, to be something exceptional; but misfortune in general is the rule.

- by Arthur Schopenhauer

In the world of programming, error and exceptions seem to be unavoidable, this is especially true when it comes to writing production quality code.

Windows programming can be challenging when both error and exception are used.

Exception

Exception always exists, even if you don't care, it would disrupt the normal flow of execution. In Windows operating system exception is implemented as SEH/VEH, with the support from CPU.

The key characteristics of exception in Windows are:

Disrupt the normal flow of execution, which translates to pipeline invalidation and slowness.
Can be used consistently in user mode and kernel mode.
Always go to kernel mode, processed by CPU exception or trap.
Has a lot of great features like continue execution, first chance versus second chance.
Unhandled exception would go to the operating system, which would kill the application (e.g. Dr. Watson) or system (e.g. BSOD).
If you swallow the exceptions used by the operating system or runtime (which you shouldn't catch), the application might not function correctly (e.g. you might get access violation while accessing the PAGE_GUARD page from callstack).

The third famous exception is Out of Memory - for device drivers and server application, you always want to handle it; for client application, probably not as critical (e.g. if Visual Studio IDE is running out of memory, we just let it crash).

The second famous exception is Stack Overflow - for hosting environment and fundamental libraries like CRT, you need to take it into consideration; in other cases it means you have design issue, and normally you don't want to handle it.

Let's take a look at the following pseudo code:

try
{
  // do something
}
catch(StackOverflowException ex)
{
  log("oops, stack overflow {0}", ex.stack);
  throw ex;
}
finally
{
  // close file handle, etc.
}

There are several things I can tell:

Having "throw ex" would ruin the exception information, better use "throw" instead.
The "log" function doesn't have much stack space, it could trigger another stack overflow.
When the exception was re-thrown, we are already miles away from the original place of the problem - we are not keeping the scene intact, and nobody would want to debug a dump file for this case.
The process is dying, close file handle will not make it any better, operating system would do that for you. More importantly, it is very likely that you are making things even worse.
If you are using latest version of .NET framework, normally you are NOT allowed to catch StackOverflowException:

In prior versions of the .NET Framework, your application could catch a StackOverflowException object (for example, to recover from unbounded recursion). However, that practice is currently discouraged because significant additional code is required to reliably catch a stack overflow exception and continue program execution.

Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default. Consequently, users are advised to write their code to detect and prevent a stack overflow. For example, if your application depends on recursion, use a counter or a state condition to terminate the recursive loop. Note that an application that hosts the common language runtime (CLR) can specify that the CLR unload the application domain where the stack overflow exception occurs and let the corresponding process continue. For more information, see ICLRPolicyManager Interface and Hosting Overview.

Windows 95, Windows 98, Windows 98 Second Edition, Windows Millennium Edition Platform Note: A thrown StackOverflowException cannot be caught by a try-catch block. Consequently, the exception causes the process to terminate immediately.

The most famous exception is Access Violation, in normal cases this would be a killer bug which stop the entire development team.

Error

Error is more like a convention, the main characteristics of error are:

Lightweight - doesn't require infrastructure support from operating system and CPU.
Less picky comparing to exception - error wouldn't complain whether you've paid enough attention to it, however it might eventually kill you if not handled properly.

Windows Error Code

Most Win32 API would return BOOL value. If FALSE is returned, the error code is stored in TEB as DWORD, which can be retrieved by using GetLastError.

You can use WinDBG's !ext.gle or Visual Studio's $ERR trick to retrieve the last error code from TEB, which also work for dump files.

The good side of storing last error in a central place (e.g. TEB) is the ability to set Data Breakpoint to see where is the error coming from. Also in later version of Windows there is a feature to do similar things:

Registry API in advapi32.dll is special, Windows error code is returned directly as LONG (signed long).

WinSock and NetAPI have similar concept but different mapping.

NTSTATUS

Lower layer of the operating system makes use of NTSTATUS, which has a similar structure as Win32 error, an incomplete mapping table can be found from Mapping NT Status Error Codes to Win32 Error Codes.

For LSA (Local Security Authority) specifically, the NTSTATUS return value can be converted to Win32 error using LsaNtStatusToWinError.

HRESULT

COM makes use of HRESULT, which was designed to be a super container for all kinds of error codes. There is a macro HRESULT_FROM_WIN32 (p.s. in later version of Windows this has been changed to an inline function) which converts Windows Error Code to HRESULT.

One caveat about HRESULT is that one has to always keep in mind of S_OK, S_FALSE, SUCCEEDED and FAILED, and understand the differences.

Since there are so many different kinds of error codes, even people working in Microsoft may get confused, that's why people tend to create tools and make the situation better:

WinDBG extension command !ext.error, which supports both Windows Error Code and NTSTATUS.
Visual Studio debugger.
Error Code Look-up tool, implemented by the Exchange team.

A Debugging Approach to Windows RT

Reiley Yang — Wed, 26 Dec 2012 13:11:00 GMT

Recently I got a Surface with Windows RT. Needless to mention, it's wonderful!

I've figured out some quick facts about Windows RT by looking at the C:\Windows\system32\ntdll.dll from Windows RT:

A complete NT (instead of WINCE) kernel and almost a full stack of Windows operating system.
Almost the same PE/COFF structure as x86.
Using ARM's "non classic RISC style" Thumb-2 instruction set (pImageNtHeaders->FileHeader.Machine == IMAGE_FILE_MACHINE_ARMNT), which has great code density, and in turn gives smaller binary and less memory pressure.

I've never had a chance to debug Thumb-2 code before, so I've listed the things I need to grasp:

Fundamental ARM architecture and Thumb-2 instructions.
ABI (Application Binary Interface), calling convention and exception handling mechanism.
Programming and debugging.

Programming

Although Visual Studio 2012 doesn't have an ARM version, it does included the x86 cross toolchain which allows targeting ARM architecture, which can be found from %ProgramFiles(x86)%\Microsoft Visual Studio 11.0\VC\bin\x86_arm\. By setting the correct environment variable (INCLUDE, LIB, LIBPATH, PATH) we can generate ARM module smoothly.

int main()
{
  return 0;
}

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_arm>cl.exe /link /NODEFAULTLIB /ENTRY:main test.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.51106.1 for ARM Copyright (C) Microsoft Corporation.  All rights reserved.

test.cpp
Microsoft (R) Incremental Linker Version 11.00.51106.1
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:test.exe
/machine:arm
/NODEFAULTLIB
/ENTRY:main
test.obj

By default Visual Studio doesn't allow generating native ARM binary, and the restriction was from a MSBuild property named WindowsSDKDesktopARMSupport, by setting this property to true I could target ARM native without an issue.

Another problem is that Windows SDK doesn't have the ARM version of import libraries, which means we don't have files like gdi32.lib and shell32.lib. The solution would be creating one either by writing a DEF file, or creating a stub module. Since we can get the ARM version of DLLs from Windows RT, it is easy to dump the export directory and create DEF file automatically, as long as the DLLs we use is not exporting mangled name (otherwise I would prefer to use stub module approach).

This is what I got while running my very first hello.exe on Windows RT :)

For pure managed code programming, the .NET runtime in Surface RT comes with the standard C# compiler:

class Hello
{
  static void Main()
  {
  }
}

C:\Users\Reiley\Desktop>"%WINDIR%\Microsoft.NET\Framework\v4.0.30319\csc.exe" /noconfig /debug+ /platform:anycpu hello.cs
Microsoft (R) Visual C# Compiler version 4.0.30319.17929 
for Microsoft (R) .NET Framework 4.5
Copyright (C) Microsoft Corporation. All rights reserved.

And this time I got something worse:

After changing the compiler flag to target ARM instead of AnyCPU, it became better and I was again greeted with the "Windows cannot verify the digital signature ..." dialog.

C:\Users\Reiley\Desktop>"%WINDIR%\Microsoft.NET\Framework\v4.0.30319\csc.exe" /noconfig /debug+ /platform:arm hello.cs

Debugging

The x86 and amd64 version of WinDBG both support various architectures including ARM Thumb-2, which means you can open dump files from a PC. This is a good place to get started, and actually I copied notepad.exe from Surface to my PC and used cdb.exe -z notepad.exe to familiar myself with the ARM PE structure and disassembly.

There is no ARM version of WinDBG available for public download. Also ntsd.exe is no longer shipped as part of the Windows since Vista.

Visual Studio 2012 comes with a great debugger, together with a fantastic remote debugging agent. Jason Zander already explained how to setup remote debugging from his great article "What you need to know about developing for Windows on ARM". I'll just put a conclusion here:

Visual Studio 2012 doesn't have ARM version, in fact only x86 version is available.
Visual Studio 2012 supports remote kernel debugging, however there is no direct way to enable kernel debugging on Windows RT device.
Visual Studio 2012 comes with an ARM version of remote debugging agent, which makes it possible to do user mode debugging on nearly all processes. To unleash the power, run remote debugging agent (msvsmon) as a service under an administrator account.
User mode debugging on Windows RT is powerful enough that you can do whatever hack you like.

(to be continued...)

Postmortem Debugging - Better Late Than Never

Reiley Yang — Sun, 21 Oct 2012 15:52:00 GMT

If there is a consistent repro, I would definitely prefer Early Debugging. However in the real life postmortem debugging seems to be unavoidable.

There are three concepts I wish to clarify before digging into the details:

AeDebug is a set of registry keys which specify the behavior when unhandled exception happened in an user mode application.
- \\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
- \\HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug
By default AeDebug is configured to use drwtsn32.exe, which would capture a dump and terminate the application in problem.
Just-In-Time Debugging (a.k.a. JIT Debugging) is a feature provided by most debuggers (e.g. CDB, NTSD, WinDBG and Visual Studio Debugger), which allows the debugger to be launched and attached to the application in problem.

The JIT debugger shipped with Visual Studio is called vsjitdebugger.exe, which would pop up a window and let you decide the next step. Visual Studio stepped further by allowing JIT debugging for scripts.

Needless to mention, JIT Debugging is normally built on top of AeDebug.
Postmortem Debugging is an overloaded term which could mean debugging a dump, or JIT debugging.

Since I will cover JIT debugging in another article, I would prefer referring dump file debugging as Postmortem Debugging.

Okay, now let's go back to the topic, what would you do after receiving a dump file?

Understand the source of the dump file - under which condition was the dump file generated. Once you've confirmed the dump is coming from a trusted source, try to find out when and where the dump file was taken.

0:001> .time
Debug session time: Mon Dec 3 17:36:58.997 2012 (UTC - 8:00)
System Uptime: 2 days 23:31:41.638
Process Uptime: 0 days 0:00:14.156
Kernel time: 0 days 0:00:00.015
User time: 0 days 0:00:00.000

0:001> vertarget
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64 Product: LanManNt, suite: Enterprise TerminalServer SingleUserTS
kernel32.dll version: 6.1.7601.17514 (win7sp1_rtm.101119-1850)
Machine Name:
Debug session time: Mon Dec 3 18:37:21.103 2012 (UTC - 8:00)
System Uptime: 3 days 0:32:03.743
Process Uptime: 0 days 1:00:36.261
Kernel time: 0 days 0:00:00.015
User time: 0 days 0:00:00.000

0:000> .lastevent
Last event: 14d0.1874: Break instruction exception - code 80000003 (first chance)
Check the dump file type - mini dump or full dump, kernel dump or user mode dump, whether the dump contains an exception record. Normally WinDBG would display the dump type when you open a dump file, here we'll use the command learned in Undocumented WinDBG.

0:001> .dumpdebug
----- User Mini Dump Analysis
MINIDUMP_HEADER:
Version         A793 (6804)
NumberOfStreams 14
Flags           9164
                0004 MiniDumpWithHandleData
                0020 MiniDumpWithUnloadedModules
                0040 MiniDumpWithIndirectlyReferencedMemory
                0100 MiniDumpWithProcessThreadData
                1000 MiniDumpWithThreadInfo
                8000 MiniDumpWithFullAuxiliaryState

If it's a user mode dump, additional information needs to be retrieved from the dump.

What is the command line, and whether the process is a generic host such like dllhost.exe, svchost.exe taskhost.exe and w3wp.exe.
Understand the bitness - whether it is a 64bit process or 32bit process. It would be tricky while debugging a 64bit dump of WOW32 process.
Whether CLR is involved, and what is the CLR version (note there could be more than one CLR hosted).

(to be continued...)

Windows 8 and conhost.exe

Reiley Yang — Thu, 13 Sep 2012 14:01:00 GMT

While debugging a console application on Windows 8, I noticed the console application is trying to create a process in the very beginning:

windbg.exe -xe ld:ntdll.dll -c "bm ntdll!*CreateProcess*; g; k" cmd.exe

CommandLine: cmd.exe
ModLoad: 000007ff`01d60000 000007ff`01f1e000   ntdll.dll
ntdll!RtlUserThreadStart:
000007ff`01d7c3d0 4883ec48        sub     rsp,48h
Processing initial command 'bm ntdll!*CreateProcess*; g; k'
0:000> bm ntdll!*CreateProcess*; g; k
  1: 000007ff`01d90f60 @!"ntdll!RtlCreateProcessParametersEx"
  2: 000007ff`01d63070 @!"ntdll!NtCreateProcessEx"
breakpoint 2 redefined
  2: 000007ff`01d63070 @!"ntdll!ZwCreateProcessEx"
  3: 000007ff`01e1bf74 @!"ntdll!RtlCreateProcessReflection"
  4: 000007ff`01da8bb4 @!"ntdll!RtlpCreateProcessRegistryInfo"
  5: 000007ff`01e1ceac @!"ntdll!RtlCreateProcessParameters"
  6: 000007ff`01d63651 @!"ntdll!ZwCreateProcess"
breakpoint 6 redefined
  6: 000007ff`01d63651 @!"ntdll!NtCreateProcess"
Breakpoint 1 hit
Child-SP          RetAddr           Call Site
000000bf`8268e558 000007fe`feea02a4 ntdll!RtlCreateProcessParametersEx
000000bf`8268e560 000007fe`feea00be KERNELBASE!ConsoleLaunchServerProcess+0x60
000000bf`8268e5f0 000007fe`fee95d40 KERNELBASE!ConsoleAllocate+0xf6
000000bf`8268e8c0 000007fe`fee7f6db KERNELBASE!ConsoleInitialize+0x1d1
000000bf`8268e950 000007fe`fee7230d KERNELBASE!KernelBaseBaseDllInitialize+0x4dd
000000bf`8268ec20 000007ff`01d6b9be KERNELBASE!KernelBaseDllInitialize+0xd
000000bf`8268ec50 000007ff`01d8b3fc ntdll!LdrpCallInitRoutine+0x3e
000000bf`8268eca0 000007ff`01d8a88b ntdll!LdrpInitializeNode+0x192
000000bf`8268eda0 000007ff`01d8e74e ntdll!LdrpInitializeGraph+0x6f
000000bf`8268ede0 000007ff`01d8c322 ntdll!LdrpInitializeGraph+0x8d
000000bf`8268ee20 000007ff`01d8cc02 ntdll!LdrpPrepareModuleForExecution+0x1a5
000000bf`8268ee70 000007ff`01d8337b ntdll!LdrpLoadDll+0x344
000000bf`8268f0a0 000007ff`01d9264f ntdll!LdrLoadDll+0xa7
000000bf`8268f120 000007ff`01d91826 ntdll!LdrpInitializeProcess+0x1664
000000bf`8268f420 000007ff`01d7c1ae ntdll!_LdrpInitialize+0x1565e
000000bf`8268f490 00000000`00000000 ntdll!LdrInitializeThunk+0xe


0:000> dc rbx
000000bf`8268e660  00000000 00000000 00000000 00000000  ................
000000bf`8268e670  003f005c 005c003f 003a0043 0057005c  \.?.?.\.C.:.\.W.
000000bf`8268e680  004e0049 004f0044 00530057 0073005c  I.N.D.O.W.S.\.s.
000000bf`8268e690  00730079 00650074 0033006d 005c0032  y.s.t.e.m.3.2.\.
000000bf`8268e6a0  006f0063 0068006e 0073006f 002e0074  c.o.n.h.o.s.t...
000000bf`8268e6b0  00780065 00200065 00780030 00660066  e.x.e. .0.x.f.f.
000000bf`8268e6c0  00660066 00660066 00660066 00000000  f.f.f.f.f.f.....
000000bf`8268e6d0  8268e960 000000bf 00000008 00000000  `.h.............

This means conhost.exe process on Windows 8 will be created by the console application itself, instead of the CSRSS. And conhost.exe would always have the native bitness (on Windows 8 64bit version, only 64bit version of conhost.exe is available).

Now debug into conhost.exe using .childdbg, it's pretty clear that conhost.exe is in charge of drawing the console window, handling user inputs and communicate with the console application:

0  Id: 124c.d34 Suspend: 1 Teb: 000007f6`3311b000 Unfrozen
Child-SP          RetAddr           Call Site
00000094`85aefb38 000007f6`33b91146 ntdll!NtWaitForSingleObject+0xa
00000094`85aefb40 000007ff`00c9167e conhost!ConsoleIoThread+0xda
00000094`85aefd80 000007ff`01d7c3f1 KERNEL32!BaseThreadInitThunk+0x1a
00000094`85aefdb0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

#  1  Id: 124c.1428 Suspend: 1 Teb: 000007f6`3311e000 Unfrozen
Child-SP          RetAddr           Call Site
00000094`85b6fd28 000007ff`0140171e conhost!ConsoleWindowProc
00000094`85b6fd30 000007ff`014014d7 USER32!UserCallWinProcCheckWow+0x13a
00000094`85b6fdf0 000007f6`33b92fcc USER32!DispatchMessageWorker+0x1a7
00000094`85b6fe70 000007ff`00c9167e conhost!ConsoleInputThread+0xd2
00000094`85b6fed0 000007ff`01d7c3f1 KERNEL32!BaseThreadInitThunk+0x1a
00000094`85b6ff00 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

And cmd.exe itself doesn't draw the console window at all:

0  Id: 1aec.5ec Suspend: 1 Teb: 000007f7`b280d000 Unfrozen
Child-SP          RetAddr           Call Site
00000008`50fff5b8 000007fe`fee8f17c ntdll!NtDeviceIoControlFile+0xa
00000008`50fff5c0 000007fe`fef0bb29 KERNELBASE!ConsoleCallServerGeneric+0x118
00000008`50fff710 000007fe`fef0b986 KERNELBASE!ReadConsoleInternal+0x131
00000008`50fff850 000007f7`b3621025 KERNELBASE!ReadConsoleW+0x1a
00000008`50fff890 000007f7`b362bd3e cmd!ReadBufFromConsole+0x111
00000008`50fff960 000007f7`b3604aae cmd!_chkstk+0x3820
00000008`50fffae0 000007f7`b36042e4 cmd!Lex+0x4be
00000008`50fffb50 000007f7`b362d560 cmd!Parser+0x128
00000008`50fffba0 000007f7`b361b721 cmd!_chkstk+0x5032
00000008`50fffc00 000007ff`00c9167e cmd!mystrchr+0x27d
00000008`50fffc40 000007ff`01d7c3f1 KERNEL32!BaseThreadInitThunk+0x1a
00000008`50fffc70 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

The interesting thing is that if we use Spy++, it would report that the console window is associated with the main thread of cmd.exe process! I believe this is a hack in the underlying implementation of GetWindowThreadProcessId for backward compatibility. Also, Spy++ cannot be used to inspect conhost.exe message loop.

Due to the side effects of IFEO Debugger, console application would fail to start if IFEO Debugger is enabled for conhost.exe.

The following call stack showed conhost.exe just created a normal window from Console Input Thread:

USER32!CreateWindowExW
conhost!CreateWindowsWindow+0x105
conhost!InitWindowsSubsystem+0x69
conhost!ConsoleInputThread+0x22
KERNEL32!BaseThreadInitThunk+0x1a
ntdll!RtlUserThreadStart+0x1d

0:001> du @rdx
000007f6`33b9d460  "ConsoleWindowClass"

0:001> du @r8
00000025`f7dc37c0  "C:\WINDOWS\SYSTEM32\cmd.exe"

When cmd.exe exits, the Console I/O Thread would be notified:

ntdll!NtTerminateProcess+0xa
ntdll!RtlExitUserProcess+0xb6
conhost!ConsoleIoThread+0xac4
KERNEL32!BaseThreadInitThunk+0x1a
ntdll!RtlUserThreadStart+0x1d

(to be continued...)

Visualize Assembly using DGML

Reiley Yang — Sun, 19 Aug 2012 15:54:00 GMT

Starting from Visual Studio 2010 Ultimate there is a cool feature called DGML (Directed Graph Markup Language).

I wrote a small script to convert the disassembled code from WinDBG into a DGML.

In order to use it, simply type the following commands under a debug session:

.shell -o LoadLibraryA.dgml -ci "uf kernel32!LoadLibraryA" cscript.exe /nologo dasm2dgml.js

A DGML file will be generated with the given name, and here is what it looks like:

Here is the source code:

var EBB = [];

var hypertext=function(s){
  var r=[],L=s.length;
  for(var i=0;i<L;i++){
    var c=s.charAt(i);
    switch(c){
      case '"':r.push('&quot;');break;
      case '&':r.push('&amp;');break;
      case '<':r.push('&lt;');break;
      case '>':r.push('&gt;');break;
      default:r.push(c);}}
  return r.join('');
};

var map=function(f,v){var L=v.length,r=[];for(var i=0;i<L;i++)r.push(f(v[i]));return r;};

(function(){
  var blk;

  var CExtendedBasicBlock = function(name, previous, next){
    this.Address = '';
    this.Code = [];
    this.Name = name;
    this.Previous = previous;
    this.Next = next;
  };

  while(true)
  {
    if(WScript.StdIn.AtEndOfStream)
      break;
    var strSourceLine = WScript.StdIn.ReadLine().replace(/(^\s+)|(\s+$)/g, '');
    if(!strSourceLine)
      continue;
    if(strSourceLine.match(/.*:$/))
    {
      blk = new CExtendedBasicBlock(strSourceLine.slice(0, -1));
      EBB.push(blk);
    }
    else
    {
      blk.Address = blk.Address || strSourceLine.match(/^[^\s]+/)[0];
      blk.Code.push(strSourceLine.replace(/[^\s]*\s+/, '').replace(/[^\s]*\s+/, ''));
    }
  }
})();

EBB = EBB.sort(function(x, y){ return x.Address == y.Address ? 0 : x.Address > y.Address ? 1 : -1; });
for(var i = 1; i < EBB.length; i++)
{
  EBB[i].Previous = EBB[i - 1];
  EBB[i].Previous.Next = EBB[i];
}

WScript.Echo('<DirectedGraph Background="#FFFFFF" GraphDirection="TopToBottom" xmlns="http://schemas.microsoft.com/vs/2009/dgml">');
WScript.Echo('  <Nodes>');
map(function(blk){
  var content = hypertext(blk.Name + ' (' + blk.Address + ')') + '&#xD;&#xA;';
  map(function(instruction){
    content += '&#xD;&#xA;' + hypertext(instruction);
  }, blk.Code);
  WScript.Echo('    <Node Id="' + hypertext(blk.Name) + '" Label="' + content + '" />');
}, EBB);
WScript.Echo('  </Nodes>');
WScript.Echo('  <Links>');
map(function(blk){
  map(function(instruction){
    map(function(x){
      var idx = instruction.indexOf(x.Name);
      idx = idx >= 0 ? instruction.charAt(idx + x.Name.length) : -1;
      if(idx == '' || idx == ' ')
        WScript.Echo('    <Link Source="' + hypertext(blk.Name) + '" Target="' + hypertext(x.Name) + '" />');
    }, EBB);
  }, blk.Code);
  if(blk.Next && !(blk.Code[blk.Code.length - 1].match(/^[^\s]+/)[0] in {jmp: 0, ret: 0}))
    WScript.Echo('    <Link Category="FallThrough" Source="' + hypertext(blk.Name) + '" Target="' + hypertext(blk.Next.Name) + '" />');
}, EBB);
WScript.Echo('  </Links>');
WScript.Echo('  <Styles>');
WScript.Echo('    <Style TargetType="Node">');
WScript.Echo('      <Setter Property="FontFamily" Value="Consolas" />');
WScript.Echo('      <Setter Property="FontSize" Value="11" />');
WScript.Echo('      <Setter Property="Background" Value="White" />');
WScript.Echo('      <Setter Property="NodeRadius" Value="2" />');
WScript.Echo('    </Style>');
WScript.Echo('    <Style TargetType="Link">');
WScript.Echo('        <Condition Expression="HasCategory(\'FallThrough\')" />');
WScript.Echo('        <Setter Property="Background" Value="Red" />');
WScript.Echo('        <Setter Property="Stroke" Value="Red" />');
WScript.Echo('    </Style>');
WScript.Echo('  </Styles>');
WScript.Echo('</DirectedGraph>');

Notes:

This script cannot generate 100% accurate control flow diagram, you will have to do further analysis (e.g. jmp eax).
I haven't got a chance to test under WOA (ARM32), so I leave it as a homework for our readers.

Enjoy:)

Using Function Evaluation in WinDBG

Reiley Yang — Sat, 18 Aug 2012 16:26:00 GMT

People who develop debuggers would know in theory you cannot have a perfect disassembler (especially for x86) and stepper (especially for Step Over). People who develop commercial debuggers would know Function Evaluation (a.k.a. funceval) is a big challenge while implementing an Expression Evaluator. And people who develop the Visual Studio Debugger would face other difficulties - Interop Debugging, Edit & Continue.

In this article, I'm not going to explain the bloody details of funceval, I just demonstrate how to use funceval in WinDBG and how powerful it is.

Previously we mentioned the .call command in Microsoft Binary Technologies, at that time we were not able to invoke the function since we don't have private symbols - funceval requires private symbol since debugger needs to understand the calling convention, which is stripped out in public symbol.

While I cannot use private symbols writting articles for this blog (private symbol is Microsoft privacy, also debugging without private symbol is much more fun), the way I'd take is to create a proxy DLL:

#include <Windows.h>

VOID WINAPI SetLastError(DWORD dwErrCode){}

Now compile the code into a DLL, with PDB file generated:

cl.exe funceval.cpp /D UNICODE /Fd /GS- /LD /Od /Zi /link /NOENTRY /NODEFAULTLIB /RELEASE /SUBSYSTEM:CONSOLE

In order to use the proxy DLL, we will use the following approach:

Launch a debug session.
Allocate memory from debugee process.
Inject the proxy DLL into the allocated memory (note that we skipped PE relocation).
Load private symbol of the proxy DLL.
Use WinDBG .call command to kick off funceval from proxy DLL.
Change the IP register to the real address we want to execute.
Start evaluating.

Here is the automation script, enjoy!

$$ cdb.exe -xe cpr -c "$$>a< .\funceval.txt" notepad.exe

.echo [Launch Script]

$$ change the following value to the size of funceval.dll
r $t1 = 0n1536

bp @$exentry; g

.echo [Allocate Memory]
.foreach ( token { .dvalloc @$t1 } ) {
	aS alias token
	.block {
		.if ($spat("${alias}", "[0-9a-f]+")) {
			r $t2 = 0x${alias}
		}
	}
	ad /q alias
}

.printf "[Load Helper DLL(base address = %p, size = %p)]\n", @$t2, @$t1
.readmem funceval.dll @$t2 (@$t1+@$t2-1)

.block {
	.sympath .
}

$$.symopt+ 0x40

.reload /s /f funceval.dll=$t2

$$.symopt- 0x40

.echo [Function Evaluation]
.call /s funceval!SetLastError kernel32!SetLastError(7777)

g

!gle

.dvfree @$t2 0

And here is the output from my machine:

[Allocate Memory]
[Load Helper DLL(base address = 00020000, size = 00000600)]
Reading 600 bytes.
[Function Evaluation]
Thread is set up for call, 'g' will execute.
WARNING: This can have serious side-effects,
including deadlocks and corruption of the debuggee.
LastErrorValue: (Win32) 0x1e61 (7777) - <Unable to get error code text>
LastStatusValue: (NTSTATUS) 0 - STATUS_WAIT_0
Freed 0 bytes starting at 00020000

A Debugging Approach to Application Verifier

Reiley Yang — Fri, 17 Aug 2012 15:29:00 GMT

Application Verifier, also known as AppVerifier, is a dynamic instrumentation tool for user mode applications. It is free available from SDK/PSDK, with a set of GUI applications and DLL extensions, plus a good document.

Let's begin by adding the most famous application - notepad.exe - from the appverif.exe GUI, and launch notepad.exe from WinDBG:

windbg.exe notepad.exe

ModLoad: 00620000 00650000   notepad.exe
ModLoad: 77c00000 77d80000   ntdll.dll
Page heap: pid 0xE10: page heap enabled with flags 0x3.
AVRF: notepad.exe: pid 0xE10: flags 0x80643027: application verifier enabled
ModLoad: 10350000 103b0000   C:\Windows\syswow64\verifier.dll
Page heap: pid 0xE10: page heap enabled with flags 0x3.
AVRF: notepad.exe: pid 0xE10: flags 0x80643027: application verifier enabled
ModLoad: 5cca0000 5cccb000   C:\Windows\SysWOW64\vrfcore.dll
ModLoad: 0f820000 0f878000   C:\Windows\SysWOW64\vfbasics.dll
ModLoad: 75330000 75440000   C:\Windows\syswow64\kernel32.dll
ModLoad: 75c40000 75c86000   C:\Windows\syswow64\KERNELBASE.dll
ModLoad: 76ee0000 76f80000   C:\Windows\syswow64\ADVAPI32.dll
ModLoad: 75fd0000 7607c000   C:\Windows\syswow64\msvcrt.dll

Like we've mentioned in A Debugging Approach to IFEO, the loader code in NTDLL knows how to initialize application verifier.

windbg.exe -xe cpr notepad.exe

0:000> sxeld verifier
0:000> g
Page heap: pid 0x1DBC: page heap enabled with flags 0x3.
AVRF: notepad.exe: pid 0x1DBC: flags 0x80643027: application verifier enabled
ModLoad: 105f0000 10650000   C:\Windows\syswow64\verifier.dll
eax=00000000 ebx=77d07e00 ecx=00000000 edx=00000000 esi=7efdd000 edi=00000000
eip=77c1fc42 esp=0018f3a8 ebp=0018f790 iopl=0         nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b             efl=00000246
ntdll!ZwMapViewOfSection+0x12:
77c1fc42 83c404          add     esp,4
0:000> k
ChildEBP RetAddr
0018f3a8 77ca6fa3 ntdll!ZwMapViewOfSection+0x12
0018f790 77ca7c29 ntdll!AvrfMiniLoadDll+0x3d1
0018f7c4 77ca1075 ntdll!AVrfInitializeVerifier+0x252
0018f7fc 77c80759 ntdll!LdrpInitializeApplicationVerifierPackage+0xab
0018f878 77c45383 ntdll!LdrpInitializeExecutionOptions+0x222
0018fa08 77c452d6 ntdll!LdrpInitializeProcess+0x261
0018fa58 77c39e79 ntdll!_LdrpInitialize+0x78
0018fa68 00000000 ntdll!LdrInitializeThunk+0x10

By reading the disassembled code, it's obvious that ntdll!RtlOpenImageFileOptionsKey is used to retrieve the IFEO related information. NTDLL would read from IFEO to see if the application is registered, and whether application verifier is enabled in GlobalFlag (GFLAG). If GFLAG & 0x100 is non-zero, NTDLL would load verifier.dll from %windir%\system32 or %windir%\syswow64, depending on the target bitness.

0:000> sxeld
0:000> g
Page heap: pid 0x1DBC: page heap enabled with flags 0x3.
AVRF: notepad.exe: pid 0x1DBC: flags 0x80643027: application verifier enabled
ModLoad: 0f6f0000 0f71b000   C:\Windows\SysWOW64\vrfcore.dll
eax=00000000 ebx=00000000 ecx=0018f600 edx=0018f601 esi=7efdd000 edi=0018f628
eip=77c1fc42 esp=0018f4fc ebp=0018f550 iopl=0         nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b             efl=00000246
ntdll!ZwMapViewOfSection+0x12:
77c1fc42 83c404          add     esp,4
0:000> k
ChildEBP RetAddr
0018f4fc 77c3beec ntdll!ZwMapViewOfSection+0x12
0018f550 77c3c578 ntdll!LdrpMapViewOfSection+0xc7
0018f644 77c3c3a9 ntdll!LdrpFindOrMapDll+0x333
0018f7c4 77c3c4d5 ntdll!LdrpLoadDll+0x2b2
0018f7fc 77ca746f ntdll!LdrLoadDll+0xaa
0018f850 77ca7aaa ntdll!AVrfpLoadAndInitializeProvider+0x6f
0018f874 77c8117c ntdll!AVrfInitializeVerifier+0xd3
0018fa08 77c452d6 ntdll!LdrpInitializeProcess+0xfba
0018fa58 77c39e79 ntdll!_LdrpInitialize+0x78
0018fa68 00000000 ntdll!LdrInitializeThunk+0x10

NTDLL would further check if IFEO has a REG_SZ value named VerifierDlls. If VerifierDlls is found, it's value will be splitted into DLL names, and these DLLs would be loaded into the target process one by one.

0:000> dt ntdll!IMAGE_DOS_HEADER 0f6f0000
   +0x000 e_magic          : 0x5a4d
   +0x002 e_cblp           : 0x90
   +0x004 e_cp             : 3
   +0x006 e_crlc           : 0
   +0x008 e_cparhdr        : 4
   +0x00a e_minalloc       : 0
   +0x00c e_maxalloc       : 0xffff
   +0x00e e_ss             : 0
   +0x010 e_sp             : 0xb8
   +0x012 e_csum           : 0
   +0x014 e_ip             : 0
   +0x016 e_cs             : 0
   +0x018 e_lfarlc         : 0x40
   +0x01a e_ovno           : 0
   +0x01c e_res            : [4] 0
   +0x024 e_oemid          : 0
   +0x026 e_oeminfo        : 0
   +0x028 e_res2           : [10] 0
   +0x03c e_lfanew         : 0n240

0:000> dt ntdll!_IMAGE_NT_HEADERS OptionalHeader.AddressOfEntryPoint 0f6f0000+0n240
+0x018 OptionalHeader :
+0x010 AddressOfEntryPoint : 0x2c86

0:000> ln 0f6f0000+0x2c86
(0f6f2c86) vrfcore!DllMain | (0f642ca7) vrfcore!VerifierOpenLayerProperties
Exact matches:
vrfcore!DllMain = <no type information>

The above steps can be automated using script:

$$ cdb.exe -xe cpr -c "$$>a< .\appverif.txt" notepad.exe

.echo [Launch Script]

sxeld vrfcore; g; sxdld

$$ get vrfcore.dll base address
r $t1 = vrfcore

.if @$ptrsize == 8 {
	aS IMAGE_NT_HEADERS _IMAGE_NT_HEADERS64
} .else {
	aS IMAGE_NT_HEADERS _IMAGE_NT_HEADERS
}

$$ get OEP offset
.block {
	r $t2 = @@c++(((ntdll!${IMAGE_NT_HEADERS}*)(@$t1 + ((ntdll!_IMAGE_DOS_HEADER*)@$t1)->e_lfanew))->OptionalHeader.AddressOfEntryPoint)
}

$$ break at OEP
bp @$t1 + @$t2; g; bc 0

.echo [Hit OEP]
k

.echo [Arguments]
dd esp L4

Now we've successfully located the OEP (Original Entry Point, we mentioned that in Data Breakpoints) for vrfcore.dll, set a breakpoint.

When we hit the breakpoint on vrfcore!DllMain, take a look at the top frame and it showed the second argument passed in is 4:

DllMain(HINSTANCE hinstDLL = 0f6f0000, DWORD fdwReason= 4, LPVOID lpvReserved)

It looks like fdwReason = 4 is undocumented on MSDN:

DLL_PROCESS_DETACH = 0
DLL_PROCESS_ATTACH = 1
DLL_THREAD_ATTACH = 2
DLL_THREAD_DETACH = 3

By looking at the disassembled code, the following instructions looks suspecious:

vsvrfcore!_DllMain:
    mov     edi, edi
    push    ebp
    mov     ebp, esp
    mov     eax, dword ptr [ebp+0Ch]
    push    ebx
    push    esi
    xor     esi, esi
    push    edi
    xor     edi, edi
    inc     esi
    sub     eax, edi
    je      vrfcore!_DllMain+0x426

vrfcore!_DllMain+0x18:
    dec     eax
    je      vrfcore!_DllMain+0x2aa

vrfcore!_DllMain+0x1f:
    dec     eax
    je      vrfcore!_DllMain+0x29b

vrfcore!_DllMain+0x26:
    dec     eax
    je      vrfcore!_DllMain+0x28c

vrfcore!_DllMain+0x2d:
    dec     eax
    jne     vrfcore!_DllMain+0x283

vrfcore!_DllMain+0x34:
    mov     ebx, dword ptr [ebp+10h]
    cmp     ebx, edi
    jne     vrfcore!_DllMain+0x79

vrfcore!_DllMain+0x131:
   mov     edi, offset vrfcore!VfCoreProvider
    mov     dword ptr [ebx], edi
    call    vrfcore!VfCoreProviderInitialize

From the highlighted code we can see when fdwReason is 4, the following assignment would happen:

*lpvReserved = (LPVOID)(&vrfcore!VfCoreProvider)

By looking into the Win2003R2 DDK headers, we can find out the layout defintion for Verifier Provider Descript. So it's time to write a small provider now.

#define WIN32_LEAN_AND_MEAN
#include <Windows.h>

// Borrowed from Win2003R2 DDK

#define DLL_PROCESS_VERIFIER 4

typedef VOID (NTAPI * RTL_VERIFIER_DLL_LOAD_CALLBACK) (PWSTR DllName, PVOID DllBase, SIZE_T DllSize, PVOID Reserved);
typedef VOID (NTAPI * RTL_VERIFIER_DLL_UNLOAD_CALLBACK) (PWSTR DllName, PVOID DllBase, SIZE_T DllSize, PVOID Reserved);
typedef VOID (NTAPI * RTL_VERIFIER_NTDLLHEAPFREE_CALLBACK) (PVOID AllocationBase, SIZE_T AllocationSize);

typedef struct _RTL_VERIFIER_THUNK_DESCRIPTOR {
  PCHAR ThunkName;
  PVOID ThunkOldAddress;
  PVOID ThunkNewAddress;
} RTL_VERIFIER_THUNK_DESCRIPTOR, *PRTL_VERIFIER_THUNK_DESCRIPTOR;

typedef struct _RTL_VERIFIER_DLL_DESCRIPTOR {
  PWCHAR DllName;
  DWORD DllFlags;
  PVOID DllAddress;
  PRTL_VERIFIER_THUNK_DESCRIPTOR DllThunks;
} RTL_VERIFIER_DLL_DESCRIPTOR, *PRTL_VERIFIER_DLL_DESCRIPTOR;

typedef struct _RTL_VERIFIER_PROVIDER_DESCRIPTOR {
  DWORD Length;
  PRTL_VERIFIER_DLL_DESCRIPTOR ProviderDlls;
  RTL_VERIFIER_DLL_LOAD_CALLBACK ProviderDllLoadCallback;
  RTL_VERIFIER_DLL_UNLOAD_CALLBACK ProviderDllUnloadCallback;
  PWSTR VerifierImage;
  DWORD VerifierFlags;
  DWORD VerifierDebug;
  PVOID RtlpGetStackTraceAddress;
  PVOID RtlpDebugPageHeapCreate;
  PVOID RtlpDebugPageHeapDestroy;
  RTL_VERIFIER_NTDLLHEAPFREE_CALLBACK ProviderNtdllHeapFreeCallback;
} RTL_VERIFIER_PROVIDER_DESCRIPTOR, *PRTL_VERIFIER_PROVIDER_DESCRIPTOR;

// ntdll!DbgPrint
typedef ULONG (__cdecl* PFN_DbgPrint)(PCH, ...);
PFN_DbgPrint DbgPrint;

// Here we go
typedef BOOL (WINAPI* PFN_CloseHandle)(HANDLE);
BOOL WINAPI ThunkCloseHandle(HANDLE hObject);

static RTL_VERIFIER_THUNK_DESCRIPTOR aThunks[] = {{"CloseHandle", NULL, ThunkCloseHandle}, {}};
static RTL_VERIFIER_DLL_DESCRIPTOR aDlls[] = {{L"kernel32.dll", 0, NULL, aThunks}, {}};
static RTL_VERIFIER_PROVIDER_DESCRIPTOR vpd = {sizeof(RTL_VERIFIER_PROVIDER_DESCRIPTOR), aDlls};

BOOL WINAPI ThunkCloseHandle(HANDLE hObject)
{
  BOOL fRetVal = ((PFN_CloseHandle)(aThunks[0].ThunkOldAddress))(hObject);
  DbgPrint("CloseHandle(%p) = %s\n", hObject, fRetVal ? "TRUE" : "FALSE");
  return fRetVal;
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, PRTL_VERIFIER_PROVIDER_DESCRIPTOR* pVPD)
{
  switch(fdwReason)
  {
  case DLL_PROCESS_ATTACH:
    ::DisableThreadLibraryCalls(hinstDLL);
    break;
  case DLL_PROCESS_DETACH:
    break;
  case DLL_PROCESS_VERIFIER:
    DbgPrint = (PFN_DbgPrint)::GetProcAddress(::GetModuleHandle(TEXT("NTDLL")), "DbgPrint");
    DbgPrint("CommandLine: %s\n", ::GetCommandLineA());
    *pVPD = &vpd;
    break;
  default:
    ::DebugBreak(); // loader lock, be careful!!!
  }
  return TRUE;
}

To compile the source code, use the following command line:

cl.exe avhook.cpp /D UNICODE /GS- /LD /Od /link /ENTRY:DllMain /NODEFAULTLIB /RELEASE /SUBSYSTEM:CONSOLE kernel32.lib

Copy the generated avhook.dll DLL to %windir%\system32 or %windir%\syswow64 folder, depending on the bitness, and import the IFEO entry into registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe]
"VerifierDlls"="avhook.dll"
"GlobalFlag"="0x100"
"VerifierFlags"=dword:80000000

Launch notepad.exe from debugger:

windbg.exe notepad.exe

And here is what we got:

Executable search path is:
ModLoad: 00160000 00190000   notepad.exe
ModLoad: 77070000 771f0000   ntdll.dll
Page heap: pid 0x158C: page heap enabled with flags 0x2.
AVRF: notepad.exe: pid 0x158C: flags 0x48004: application verifier enabled
ModLoad: 714a0000 71500000   C:\Windows\syswow64\verifier.dll Page heap: pid 0x158C: page heap enabled with flags 0x2.
AVRF: notepad.exe: pid 0x158C: flags 0x48004: application verifier enabled
ModLoad: 715c0000 715c5000   C:\Windows\SysWOW64\hook.dll 
...

CloseHandle(00000320) = TRUE
CloseHandle(0000032C) = TRUE
CloseHandle(00000330) = TRUE
CloseHandle(0000034C) = TRUE
CloseHandle(00000328) = TRUE
CloseHandle(000001C8) = TRUE

As you could see, our provider DLL is working as expected :)