First posted to MSDN on Feb, 27 2009
A long time ago (2 years ago – that’s like the Paleolithic era of computers – weren’t we all running TI-99/4As back then?)
I put together a post about running Application Verifier as a tester
.
There were a couple of things I would do differently with this post today. In fact, I’m about to do them differently.
First, I would remove the redundancy. If you have a look, you’ll see that I end up enabling the same tests multiple times. Why? I’m not sure.
Next, you may discover on the latest versions of Application Verifier that there’s a bug in my script. My test configuration calls all specify -with ErrorReport=0. It turns out that this is supposed to say “ignore this” but it happens to still (erroneously) log events in previous versions of Windows and Application Verifier. Well, now it doesn’t. So, I wrote a dependency on a bug. Good job, me. (That’s what I get for stealing my AppVerifier configuration script from SUA instead of actually doing my homework.)
Finally, it ignored the fact that there are 64-bit computers out there. You need to match up the bitness of Application Verifier to the bitness of the application you are trying to test (no, not the operating system – the 64-bit Application Verifier package gives you both).
If you are running x86 (32-bit), then you simply need to specify appverif.exe, since it’s in system32 (which is probably in your path). If you are running an x64 operating system and want to monitor a 64-bit application, then you simply need to specify appverif.exe, because that will resolve to system32 where the 64-bit version lives. But if you are running an x64 operating system and want to monitor a 32-bit application (what I normally do) you have to get to the 32-bit version of appverif.exe. What I do for that today is specify %windir%syswow64appverif.exe to launch the correct version. I’m not sure if there is a better way to do that? I just know you want to make sure you’re calling the 32-bit version when testing a 32-bit app.
So, rather than leave it wrong, I figured I’d correct it. If you want to configure Application Verifier for use in automated test scripts, here are some scripts that should be (to the best of my knowledge) actually correct.
First, let’s turn on monitoring and configure tests to record data but not break into a debugger:
%windir%syswow64appverif.exe -enable COM Exceptions Handles Heaps Leak Locks Memory RPC Threadpool TLS -for AppVerifierDemo.exe
%windir%syswow64appverif.exe -configure 0x400 0x401 0x402 0x403 0x404 0x405 0x406 0x407 0x408 0x409 0x40A 0x40B 0x40C 0x40D 0x40E 0x40F 0x410 -for AppVerifierDemo.exe -with ErrorReport=0x181
%windir%syswow64appverif.exe -configure 0x650 -for AppVerifierDemo.exe -with ErrorReport=0x181
%windir%syswow64appverif.exe -configure 0x300 0x301 0x302 0x303 0x304 0x305 -for AppVerifierDemo.exe -with ErrorReport=0x181
%windir%syswow64appverif.exe -configure 0x001 0x002 0x003 0x004 0x005 0x006 0x007 0x008 0x009 0x00A 0x00B 0x00C 0x00D 0x00E 0x00F 0x010 0x011 0x012 0x013 0x014 -for AppVerifierDemo.exe -with ErrorReport=0x181
%windir%syswow64appverif.exe -configure 0x900 0x901 0x902 0x903 0x904 0x905 -for AppVerifierDemo.exe -with ErrorReport=0x181
%windir%syswow64appverif.exe -configure 0x200 0x201 0x202 0x203 0x204 0x205 0x206 0x207 0x208 0x209 0x210 0x211 0x212 0x213 0x214 0x215 -for AppVerifierDemo.exe -with ErrorReport=0x181
%windir%syswow64appverif.exe -configure 0x600 0x601 0x602 0x603 0x604 0x605 0x606 0x607 0x608 0x609 0x60A 0x60B 0x60C 0x60D 0x60E 0x60F 0x610 0x611 0x612 0x613 0x614 0x615 0x616 0x617 0x618 0x619 0x61A 0x61B 0x61C 0x61D 0x61E -for AppVerifierDemo.exe -with ErrorReport=0x181
%windir%syswow64appverif.exe -configure 0x500 -for AppVerifierDemo.exe -with ErrorReport=0x181
%windir%syswow64appverif.exe -configure 0x700 0x701 0x702 0x703 0x707 0x705 0x706 0x707 0x708 0x709 0x70A 0x70B 0x40C -for AppVerifierDemo.exe -with ErrorReport=0x181
%windir%syswow64appverif.exe -configure 0x350 0x351 0x352 -for AppVerifierDemo.exe -with ErrorReport=0x181
With this configuration, you can now run your tests, and generate logs. When you’re done with the execution, you can pull off the logs and store them someplace convenient, so let’s create a script to do that:
%windir%syswow64appverif.exe -export log -for AppVerifierDemo.exe -with To=%userprofile%desktopAppVerifierDemo.exe.xml Log=0
And finally, let’s disable testing after our test pass is done:
%windir%syswow64appverif.exe -disable * -for AppVerifierDemo.exe
Hopefully having some guidance around scripting application verifier is helpful (particularly now that it’s more correct)! Oh, and obviously you’ll replace the dummy application name I have here (AppVerifierDemo.exe) with the name of the application you’re trying to test.
