« Back to home

Effective Leak Detection with the Debug CRT and Application Verifier

Programming memory leaks in C or C++ is easy. Even careful programming often cannot avoid the little mistakes that finally end up in your program having a memory leak. Thankfully, however, there are plenty of helpful tools that assist in finding leaks as early as possible. One especially helpful tool for leak detection is the debug CRT. Although the leak detection facilities provided by the debug CRT are not as far-reaching as those of, say, UMDH, using the debug CRT is probably the most friction-less way of identifying leaks. Continue »

Effective Leak Detection with the Debug CRT and Application Verifier

Programming memory leaks in C or C++ is easy. Even careful programming often cannot avoid the little mistakes that finally end up in your program having a memory leak. Thankfully, however, there are plenty of helpful tools that assist in finding leaks as early as possible. One especially helpful tool for leak detection is the debug CRT. Although the leak detection facilities provided by the debug CRT are not as far-reaching as those of, say, UMDH, using the debug CRT is probably the most friction-less way of identifying leaks. Continue »

AuxKlibGetImageExportDirectory and forwarders

Posted on

One of the newer additions to the DDK is the aux_klib library, which, among others, offers the routine AuxKlibGetImageExportDirectory. As its name suggests, AuxKlibGetImageExportDirectory offers a handy way to obtain a pointer to the export directory of a kernel module. There is, however, one issue that – at least in my opinion – renders AuxKlibGetImageExportDirectory pretty much useless in most scenarios: Dealing with forwaders. The primary motivation to call AuxKlibGetImageExportDirectory is to either enumerate the exports of a module or to find a specific export. Continue »

Walking the stack of the current thread

StackWalk64 provides a convenient and platform-independent way to walk the stack of a thread. Although useful and powerful indeed, it is definitively one of the less trivial to use functions. The additional fact that the MSDN documentation for StackWalk64 is rather light does not make things easier. There is, however, a decent article on CodeProject covering the usage of StackWalk64. Although you can walk the stack of any thread using StackWalk64, this post only deals with walking the current thread’s stack. Continue »

Creating and embedding message tables with the WDK/build.exe

  1. Create a message file Updating the SOURCES file Updating the rc file Although message tables play an important role in Windows, their tool support has always be somewhat limited – at least compared to string tables, for which Visual Studio even provides a graphical editor. When in comes to creating and embedding message tables into a binary built with the WDK, documentation is light.
Continue »

Application Verifier: Thread cannot own a critical section

Whereas most Verifier error messages are rather descriptive, this one is not really: VERIFIER STOP 00000200 : pid 0x2B4: Thread cannot own a critical section. 0000104C : Thread ID. 05274FDC : Critical section address. 09D88FE0 : Critical section debug information address. 010135D4 : Critical section initialization stack trace. Why should not this thread be allowed to own a critical section? What is Application Verifier trying to tell us? Luckily, the stack trace gives a hint: Continue »

How to use manifests with build.exe

As of Windows Vista, basically all applications require a manifest in order to at least declare UAC compliance. Visual Studio has builtin support for creating and embedding manifests, so when using VS to build applications, using manifests is straightforward. However, when building a user mode application with the WDK and build.exe, things are a little different. Looking at the WDK documentation, manifests remain unmentioned – both in the context of UAC and SXS. Continue »

Dangerous Detours, Wrap-Up

This concludes the little series about the limitations of Detours: Part 1: Introduction Part 2: Unexpected Behaviour Part 3: Messing execution flow Part 4: Undetouring Granted, the probability of experiencing any of the problems described in these posts is rather low. Whether these problems should be considered bugs of Detours or rather an inherent problem of the concept is not quite easy to judge – on the one hand, Detours indeed acts a little naive and especially the unhooking problem could have been easily avoided. Continue »

Dangerous Detours, Part 4: Undetouring

Having discussed what can go wrong when detouring a function, we will now take a closer look at undetouring. Again, there is a problem – in my opinion an even more severe than the ones discussed previously – that has not been addressed by the Detours library. Undetouring is a multi-step process and requires the user to follow a certain protocol. The basic idea is as follows: The caller creates a transaction, registers all threads that might have been affected by the detour and specifies which functions to unhook. Continue »

Dangerous Detours, Part 3: Messing execution flow

Last time I showed that as a result of its implementation strategy, Detours is unable to properly instrument certain kinds of functions. Unlike last time, where this merely led to unexpected debugging output, we will see how this can easily lead to a crash. Consider this code (error checking omitted): #include <stdio.h> #include <tchar.h> #include <windows.h> #include <detours.h> static PDETOUR_TRAMPOLINE Trampoline; __declspec(noinline) static void DoSomething() { wprintf( L"DoSomething\n" ); Sleep( 100 ); } // // This is the function we want to instrument. Continue »

Dangerous Detours, Part 2: Unexpected Behaviour

Last time I described how to ‘replace’ a function by another using Detours. The important point was that first, we did not care about the original function any more once it has been hooked and second, we used a hook specially crafted for one particular to-be-hooked function. This time we will make use of the trampoline in order to enable the hook function to call the original function. Furthermore, we do not want to create a separate hook function for every function we wish to hook but rather implement some kind of a generic hook – a hook function that is capable of hooking any possible function. Continue »

Dangerous Detours, Part 1: Introduction

Detours is a library that allows you to hook arbitrary functions by rewriting machine code. While a description of the exact implementation approach can be found in the corresponding paper as well as in numerous other sources, the basic idea is as follows: In the to-be-hooked function, disassemble the first instructions until you have read at least 5 bytes. As instructions are variable length on x86, we may end up having to read more than 5 bytes to reach the next instruction boundary. Continue »

Using Import Address Table hooking for testing

Posted on

For a procedure that is free of side effects, it is a relatively easy task to create a unit test that achieves sufficient code coverage by testing all (or at least all interesting) combinations of input data and verifying the computed results. If, however, the procedure is not free of side effects, the state (global variables, external data, etc.) modified by the procedure has to be taken into account. A solid testcase has to test both the effects of the state on the correctness of the procedure and the correctness of the procedure’s modifications on the state. Continue »

Launch elevated processes from the command line

Posted on

Every now and then you need to run an elevated command from the command line. If the application always requires elevation (i.e. the binary has been marked as requireAdministrator), the UAC prompt shows up – but in the case the application supports both non-elevated and elevated usage and you explicitly want it to run elevated, there is little support for you. I would have expected start.com to have been augmented by something like a /elevate-switch, but unfortunately, this is not the case and you are left with having to open a new elevated command prompt to continue. Continue »

A Regedit bug or what happens if API documentation is fuzzy

Posted on

Registry keys and values have a maximum length, as documented on MSDN. For example, the maximum permitted length of a key is 255 characters – interestingly enough, the question of whether this includes or excludes the NULL terminator is left unanswered. May it be due to this fuzzy documentation or not, Microsoft’s tools and API do not quite seem to agree on a common interpretation of maximum key length, which revealed this little bug in Regedit. Continue »

Error Codes: Win32 vs. HRESULT vs. NTSTATUS

Posted on

There are three common error code formats used throughout Windows. In the kernel and native part, NTSTATUS is used exclusively. The Win32 API uses its own error codes (they do not really have a name, so I will refer to them as Win32 error codes) and COM uses HRESULTs – though the separation is not always so sharp, e.g. the safe string functions (StringCch* and friends) also return HRESULTs although they do not belong to COM. Continue »

Install MSI with log from shell context menu

Posted on

When authoring MSI packages, you frequently need the installation to be logged. Instead of repeatedly opening a console to type in msiexec /l* install.log /i foobar.msi, these shell context menu items may speed this process up a little. They do the same as ‘Install’ and ‘Uninstall’ but log everything (/l) to PackageName.msi-install.log or PackageName.msi-uninstall.log, respectively. Here are the registry entries: Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Msi.Package\shell\LoggedInstall] @="&Logged Install" [HKEY_CLASSES_ROOT\Msi.Packageshell\LoggedInstall\command] @="msiexec.exe /l &quot;%1-install. Continue »

Type 1 CustomAction Load Failures

Posted on

When testing a custom action, it is usally practical to have the CA write some information to the installer log, so that you can verify that the CA has been called properly. But what if the installer log does not show up your information but instead the installation aborts and the log only states that the custom action returned 3 (ERROR_INSTALL_FAILURE)? There may be various reasons for this to happen, but the most common reason is probably that your DLL was unable to load because of unsatisfied dependencies. Continue »

Where to place RemoveExistingProducts in a major MSI upgrade

Posted on

When Windows Installer performs a major upgrade, the position of the RemoveExistingProducts action determines when the uninstall of the old product is performed. Despite efficiency, two factors dominate the decision What should happen if either the install or the uninstall fails? Should the new product ‘see’ registry entries/files/etc from the existing product or should the new product install ‘start from scratch’? The following table summarizes the four possible approaches. Continue »

Authoring multi-language MSI packages

Posted on

By default, Windows Installer packages are single-language only – no direct support for multi-language packages is currently provided. Creating a multi-lanuage installation package is thus a little more compex – the following provides a summary of the steps required: Create an english package Compile: candle -dLANG=1033 foo.wxs Link: light -out foo.msi -loc strings-en.wxl foo.wixobj Create the german (or whatever language) package Compile: candle -dLANG=1031 foo.wxs Link: light -out foo-de.msi -loc strings-de. Continue »