Chris Jackson's Semantic Consonance : Application Verifier

The Case of the SUA Missing Log File

Chris Jackson — Thu, 04 Jun 2009 07:16:31 GMT

Since I’m using Mark’s tools, I figure I may as well steal his blog title scheme…

I had a customer come to me with a question on Standard User Analyzer (SUA), looking for an explanation for why it was coming back with the following error:

Failed to load log file C:\Users\…\AppData\Local\Temp\sua
No (valid) log file is found.

I asked him to try opening it up in Application Verifier, which he was able to do successfully.

So, now we knew that the problem was somewhere between collecting the data and displaying it – we’d narrowed down the surface area rather significantly. What happens in that time? Well, SUA is kind enough to tell you. First, it clears existing logs:

Executing: cmd.exe /c "del /q "C:\Users\…\AppData\Local\Temp\sua""
Returned : 0

Then, we export the logs we just created:

Executing: "C:\Program Files (x86)\Microsoft Application Compatibility Toolkit 5\Standard User Analyzer\SUAnalyzerSrv.exe" exportlogs "C:\Users\…\AppData\Local\Temp\sua" "(symbol file directory)"
Returned : 0

Finally, we view it, but this was the step which was failing. We could browse to the temp directory it was using and discover that it was, indeed, clear, so now we know that the command to export logs was our most likely suspect. But it was returning 0, which presumably meant success, so we had very little to go on.

Fortunately, I was able to find a repro relatively quickly. And, when in doubt, use Process Monitor.

I didn’t even have to go any further than the process tree. I found the call to SUAnalyzerSrv.exe, and it made a call to appverif.exe – Application Verifier. Here was the arguments it was passing:

appverif.exe -export log -for AppVerifier Bug Generator.exe -with To=C:\Users\…\AppData\Local\Temp\sua\AppVerifier Bug Generator.exe.0.xml Log=0 Symbols=(symbol file directory)

It’s when you see this that you probably notice something: the name of the binary … has a space in it.

I renamed the binary to remove the spaces, and it worked. No problems importing. So, I filed a bug against SUA, and it’s going to be fixed for the next release. In the interim, if SUA isn’t working as well as you’d like, well, the EXTREMELY hacky workaround may be to rename the binary…

Configuring Application Verifier as a Testing Tool Take 2: 99.44% Less Wrong

Chris Jackson — Fri, 27 Feb 2009 18:55:53 GMT

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%\syswow64\appverif.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%\syswow64\appverif.exe -enable COM Exceptions Handles Heaps Leak Locks Memory RPC Threadpool TLS -for AppVerifierDemo.exe

%windir%\syswow64\appverif.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%\syswow64\appverif.exe -configure 0x650 -for AppVerifierDemo.exe -with ErrorReport=0x181
%windir%\syswow64\appverif.exe -configure 0x300 0x301 0x302 0x303 0x304 0x305 -for AppVerifierDemo.exe -with ErrorReport=0x181
%windir%\syswow64\appverif.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%\syswow64\appverif.exe -configure 0x900 0x901 0x902 0x903 0x904 0x905 -for AppVerifierDemo.exe -with ErrorReport=0x181
%windir%\syswow64\appverif.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%\syswow64\appverif.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%\syswow64\appverif.exe -configure 0x500 -for AppVerifierDemo.exe -with ErrorReport=0x181
%windir%\syswow64\appverif.exe -configure 0x700 0x701 0x702 0x703 0x707 0x705 0x706 0x707 0x708 0x709 0x70A 0x70B 0x40C -for AppVerifierDemo.exe -with ErrorReport=0x181
%windir%\syswow64\appverif.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%\syswow64\appverif.exe -export log -for AppVerifierDemo.exe -with To=%userprofile%\desktop\AppVerifierDemo.exe.xml Log=0

And finally, let’s disable testing after our test pass is done:

%windir%\syswow64\appverif.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.

Standard User Analyzer Refuses to Run with Application Verifier 4.0 (and Application Verifier 3.x is Gone!)

Chris Jackson — Wed, 04 Feb 2009 21:01:00 GMT

Updated March 16, 2009: Somebody updated these links with the 4.0 version (which kind of defeats the purpose of having these links so I’m not sure what they were thinking) but they’re back to the 3.x version now.

Hey, there’s a new version of Application Verifier in town, and guess what? Standard User Analyzer doesn’t like it. ACT 5.0.3 (the latest publicly available version) is hard coded to look for versions 3.2 through 3.5, so the brand new version 4.0 kind of leaves this tool in a lurch.

It’s also a mystery to me why the #1 web hit on live.com for Application Verifier leads to http://www.microsoft.com/downloads/details.aspx?FamilyID=bd02c19c-1250-433c-8c1b-2619bd93b3a2&DisplayLang=en, which is a, “We are sorry, the page you requested cannot be found” page, which helpfully has search results from the same search engine, which helpfully has a #1 web hit of the same unhelpful page. Seriously? Did we just not pay attention to the fact that we should have kept this page and forwarded, since people don’t want to have to guess the GUID for the new version? A search for Application Verifier 4.0 brings up the desired download as the #2 hit, so all is not lost (just most).

But the fact that you can eventually find this incredibly useful and important tool if you try hard enough still doesn’t help fans of Standard User Analyzer (which are many). So, until we release ACT 5.5 (which support Application Verifier 4.0), we posted the 3.x versions again in a super-secret hidden location so you can still download them from us instead of from a random source. Unfortunately, we didn’t include fwlinks in the product so we could just update these links and you wouldn’t have to read this here, an omission we have already fixed.

So, here’s where you can get the 3.x versions of application verifier:

http://msdl.microsoft.com/download/symbols/debuggers/Private/ApplicationVerifier.ia64.msi

http://msdl.microsoft.com/download/symbols/debuggers/Private/ApplicationVerifier.amd64.msi

http://msdl.microsoft.com/download/symbols/debuggers/Private/ApplicationVerifier.x86.msi

Note that you really shouldn’t use Application Verifier 3.x on Windows 7 – you’ll want to use Application Verifier 4.x on it, which means you’ll end up waiting for ACT 5.5 to use SUA on Windows 7.