Despite the fact that mainstream support for Windows 2000 has ended in 2005 and the system is well on its way to retirement, Windows 2000 is still in wide use today. As such, it remains being an important target platform for many software packages.
The fact that cfix has not provided support for Windows 2000 was thus unfortunate – after all, if Windows 2000 is among the target platforms of your software, you should be able to run your tests on this platform.
Continue »
Most code that uses Structured Exception Handling does this with the help of the compiler, e.g. by using try/except/__finally. Still, it is possible to do everything by hand, i.e. to provide your own exception handlers and set up the exception registration records manually. However, as this entire topic is not documented very well, doing so opens room for all kind of surprises…
Although more than 10 years old, the best article on this topic still seems to be Matt Pirtrek’s A Crash Course on the Depths of Win32™ Structured Exception Handling, which I assume you have read.
Continue »
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 »
While the RTL Heap performs all heap operation in an interlocked manner by default, it can be requested not to serialize operations by passing the HEAP_NO_SERIALIZE flag to HeapCreate or HeapAlloc. In this case, the caller is in charge to provide proper synchronization.
As it turns out, things change when Application Verifier heap checks are enabled for this process. To check heap operations, Application Verifier intercepts certain operations. Presumably to protect its own internal data structures, at some points, Avrf enters a critical section, as shown in this stack trace:
Continue »
I am happy to announce that the unit testing framework cfix I have developed over the past weeks and months is now available on Sourceforge as a first release candidate. It is licensed under the GPL, both binaries and source code are available.
Background cfix is a framework for authoring and running xUnit-like testcases written in C or C++. The aim of the tool is to provide a development experience very similar to frameworks such as JUnit or NUnit.
Continue »
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.
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 »
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 »
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 »
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 »
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 »
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 »
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 »
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 »
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 »
cfix 1.0.1 adds support for Windows 2000
