Improving Application Quality through AppVerifier
One of the really important tools to use to ensure that your applications have a high quality is AppVerifier. This blog is aimed at enhancing your interest in AppVerifier so that you spend time investigating it, learning about it, talking about it, sounding cool in front of your friends and finally, yes finally but most importantly, improving the quality of your apps.
But wait, before you download this tool (or before you close this browser window), why not take a few moments and answer the trivia below…
1. How do you access standard and well known folder paths (i.e. Windows, Windows\System32, Program Files etc?) Is there any API to use for it?
2. An interactive Win32 service can cause a serious _______________ hazard. (Hint: the answer’s not - fire). Why?
3. Is this pseudo-code snippet okay? If not, why?
EnterCriticalSection (&cs);
SendMessage (hWndOwnedByOtherThread, ...
...
...
LeaveCriticalSection (&cs);
4. Can the code inside a DLLs DllMain load another DLL using LoadLibrary? Is this recommended?
5. What happens when a thread calls ExitProcess when there are several other threads running?
Are we expected to know the answers to these? Probably not.Are we expected to prevent these and fix these? Absolutely!
Many of these become easy if you have AppVerifier. To learn more, a good starting point would be to install the tool and go through the help CHM. This link is also useful.
How does AppVerifier work? A high level explanation…
The link above gives useful info on how AppVerifier works. Let's add a little more detail...
Let us assume that we want to inspect an application called MyApp.exe. In MyApp.exe, let us assume that we want to monitor all file creation behavior. MyApp.exe is a PE (Portable Executable) image. It will contain a table known as an import address table (IAT). This table maintains an entry of all functions that are being imported by MyApp.exe. If MyApp.exe is using the CreateFile API, then an entry for CreateFile would exist in its IAT. The entry would be something like this:
Function being imported
Module
Relative virtual address of function
CreateFileW
Kernel32.dll
0x000107F0
This entry tells the loader that CreateFile is to be imported from kernel32.dll. CreateFile is found at address 0x000107F0 in kernel32.dll
Since AppVerifier wants to monitor all CreateFile calls, when MyApp.exe is started with AppVerifier enabled, the verifier engine of Appverifier modifies the IAT of MyApp.exe with its own function. So, after modification, the IAT of MyApp.exe looks like this:
Function being imported
Module
Relative virtual address of function
CreateFileW
AppVerifiers_special_dll.dll
0x000107E0
This is known as API hooking. So, any CreateFile call that should have gone to kernel32.dll gets routed to AppVerifiers_special_dll.dll instead. (Note: AppVerifiers_special_dll.dll is just a sample name)
The CreateFile in AppVerifiers_special_dll.dll could be implemented as follows
CreateFile ( ….)
{
// do some logging, conduct some tests on the inputs etc
// call the actual CreateFile found in kernel32.dll
// do some logging to monitor results
// return the return value of kernel32::CreateFile
}
This AppVerifiers_special_dll.dll is known as a Provider DLL. The good thing is that we can write our own provider DLLs and register them with AppVerifier. AppVerifier then calls our DLLs and we could do custom logging and inspection of any APIs that we are interested in.
How do I start?
One of the best ways to start with AppVerifier is to take an existing application from your project and run AppVerifier on it and go on fixing bugs. It can be a frustrating time at first, but I assure you that it is going to give you a high learning experience. (I remember a similar experience when I was starting off with .NET applications and learnt about FxCop. I took an old module from our project and ran FxCop only to find about 1000+ warnings!! It took me about a month of after-office-time to fix all the warnings, but boy! Did my understanding improve!!)
Finally... after you explore the GUI part of AppVerifier, you could learn about its command line usage. This gives you the advantage of building automation jobs that run AppVerifier. If these automation jobs are integrated with your product’s build cycles, then over a period of time, you could consistently be hitting high quality builds that produce high quality apps.
Technorati Tags: Xpe,Embedded,AppVerifier
Comments
Anonymous
February 04, 2009
PingBack from http://www.clickandsolve.com/?p=3623Anonymous
March 30, 2009
Youve got to be kidding me... OK, so I download AppVerifier to test against a couple programs and once I have the thing loaded and running, nothing else will even run. The only app that comes up (1 of 3) crashes almost right away with a message that there is a breakpoint set in the code. Its a small app, so I check ALL the code - not a single breakpoint ANYWHERE in the code, but of course it still wont run or do anything because AppVerifier continues to give me a message that isnt true. Funny thing, if I uninstall AppVerifier, EVERYTHING runs just fine. More quality garbage from Microsoft, and more proof that their motto should be "Where dont you want to go today?" I mean honestly, what is the point!?!?!Anonymous
March 30, 2009
Hi, Thanks for your post.
- Which OS were you using?
- What was the OS architecture (32 bit/64 bit)
- Could you please send me the link from where you downloaded appverifier. (just to be sure... we could investigate by using the same set of binaries)
- What happens when you run other apps with appverifier present? Do you get any error message? Or does it just fail silently? Thanks!