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.
Since I was discussing the Windows 7 Problem Steps Recorder yesterday, it makes sense to address the most common question I get after demonstrating this feature:
Can I use it on Windows Vista / Windows XP / Windows something else?
Well, there’s nothing quite like trying it to find out! So, I copied the binary over to a Windows Vista machine, and gave it a go. And, alas, it didn’t work.
Which of course got me thinking – why not?
My first inclination was that perhaps there was a dependency on some unique feature of Windows 7, so I did some poking around to see if I could find it. But then, during a conversation with my friends Justin and Uday today, Justin turned me on to something I was unaware of: an entry in the WinPE header that determines if we’ll try to run a binary.
You can spot it using PEBrowse Professional: 0x28 bytes into the Optional Header, you find an entry for Major Operating System Version == 0x0006, and 0x2A bytes into the Optional Header, you find an entry for Minor Operating System Version == 0x0001.
And it turns out that this prevents you from running down-level. (The same would be true of, say Notepad.) This isn’t anything proprietary to us – you could do the same. Nobody really talks about it, because the error message you get isn’t … helpful … so I can’t imagine why anybody would want to subject their users to that.
But at least I got to the bottom of it.
One of the features of Windows 7 that consistently gets rave reviews from the IT Pros I demonstrate it to is the Problem Steps Recorder. But as I look at it, you have a rather strange set of requirements, involving walking users through how to start the thing, where to save it to, and how to send what it collects back to you.
What if you could automate some of that?
It was at this point that I noticed a tool that already did that – the Send Feedback link on my desktop. It lets you fire up the Problem Step Recorder when filing a new issue! So, I naturally got curious – what is it doing?
“When in doubt, use Process Monitor.”
And it turns out you only have to look at the very first entry (the one for process creation) – psr.exe accepts command line arguments! Here’s what our bug reporting tool uses:
"C:\Windows\system32\psr.exe" /output "C:\Users\cjacks\AppData\Local\Temp\WER130B.tmp.ft\IssueSteps.zip" /maxsc 25 /exitonsave 1
So, it looks like I can fire up the tool from my own app, system32 is in the path so I don’t need to hard code, and I can store my zip file someplace my launching tool can find, and grab it later on.
I can think of all kinds of uses for this…
With the release of the Windows 7 beta, there has been a lot of speculation about an accompanying version of the Application Compatibility Toolkit. Because the release of a version of ACT so frequently accompanies the release of an OS (or a significant service pack, such as Windows XP SP1), we’ve generated this perception in the community that you have to have the version of ACT that is matched up with that particular version of Windows. (We see this a lot with people who are just now deploying Windows XP SP2 – they start looking around for older versions of ACT, which are no longer available.)
ACT 5.5 is scheduled to be ready by around April. (I’ve also done a piece for TechNet Magazine with my friend Chris Corio that goes deep into the internals of ACT which should be out at around the same time – stay tuned for that.) If you plan to start getting ready for a Windows 7 deployment, do you need to wait for it?
I don’t think you do.
But, rather than me just throwing out an opinion, let me walk through the process of an application compatibility project, point out what you could do today with ACT 5.0.3 (the currently available version), and then point out what you would get in addition if you were to wait.
You need an inventory of what software you have in order to drive your project. ACT 5.0 will give you an excellent inventory of what you have, so you can get started today figuring out what you have in your ecosystem. In fact, I recommend it, unless…
There is a compelling new feature in ACT 5.5 that may be worth the wait: the ability to “tag” a DCP package. If you have the ability to target deployment of your DCPs, and you’d like to have the applications in your inventory come back reflecting where they came from, then this may be worth the wait.
ACT 5.5 will include new deprecations in the deprecation agent – specifically, the Windows Mail deprecations. If you see Outlook Express / Windows Mail displaying UI in your organization, then this may be important. But, to be honest, I don’t expect this to have a significant impact on many enterprises at all, so unless you’re particularly worried about this, it may not be worth waiting for. (Obviously it’s useful once it’s out, but do you really want to set yourself back a couple of months to get this if you’d rather get started today?)
It kind of depends on how much it bugs you to see “Windows Vista” in the report category as to whether or not you’re comfortable using it.
The compatibility data will be from Windows Vista and not from Windows 7, but not only are we not breaking that many more things, it’s not as if that data was terribly good to start with (even with Windows Vista, going to windows.com/compatibility was your better option).
And, of course, if you dump your inventory into Excel to analyze, then 5.0 is fine.
ACT 5.5 will display Windows 7 as an option in the report listing, so that will satisfy your sense of aesthetics. In addition, because the list of operating systems is starting to get kind of big, and you’re likely to only be migrating to one at a time, you will be able to filter them and only display the one you intend to deploy. That simplifies the UI a bit.
If you are worried about the data you send up to the ACT web service, ACT 5.5 is going to add on some functionality to help. 5.0 would always send the unique Application ID up – but if you unselected it we wouldn’t send any of your evaluation data. ACT 5.5 won’t even send up the ID (as a result, you won’t be able to see any community data for this app) and the tool gives you direct visibility into the exact data that you are sending up. For folks who are concerned about this, you may want to wait for this feature before you sync.
ACT 5.5 will also be able to support syncing with the Windows Compatibility Center – so no more manually looking things up at windows.com/compatibility! My understanding is that this may not be fully ready to go when the product ships, but it will be able to support it once the service is ready to go. I think that’s going to be huge.
Note that this doesn’t mean you can’t collect your inventory now – I haven’t personally tested the database upgrade scenario, but I have been loading up my sample database with the log files from an ACT 5.0 DCP deployment, and have had no problems doing so. My guess is that we’ll elegantly handle a database upgrade from 5.0 as well (I just don’t want to promise something I haven’t tried myself).
SUA is relatively unchanged from the ACT 5.0 version. One big change: you need AppVerifier 4.0+ on Windows 7, and only the ACT 5.5 version works with AppVerifier 4.0+. So, you’d just have to do your testing on Windows Vista or earlier.
IECTT supports IE8 today, so you don’t have to wait for anything to start investigating your web applications!
Does anybody use the setup analysis tool? It remains, and it’s as uninteresting today as it was for Windows Vista. This could be the last time we see this tool.
Compatibility Administrator is relatively unchanged, and you can use it today on Windows 7 without hesitation.
If you want to test with SUA on Windows 7 itself, you’ll have to wait. But for getting started to get your apps ready for a more secure environment today, you’ll get the same functionality down-level.
Last I heard, LUA Buglight also has a version check (alas, in the driver, so you can’t shim it) that keeps it from running on Windows 7, but current builds work fine on Windows 7. Not sure when Aaron plans to release an update.
Have we filled all of the gaps with ACT 5.5? Certainly not. I’d love to do more to help people rationalize apps. I’d love to have a smooth integration story (heck, I’d take a rough one if I could just get anything). I’d like a better 64-bit story (that’s on deck). I’d like more focus on the actual process than the technology. There’s always something else I want. But there is some good stuff coming (I’ll never be satisfied anyway).
In conclusion, the ACT 5.5 story falls very much in line with the rest of the Windows 7 application compatibility story. You can get started today and not incur too much risk of a tool or feature coming along later that is killer. The tags for DCPs may be a killer feature (they’re certainly a highly requested one), but otherwise you can get started today, and the work you do with the tools you have will translate to results in the future.
If you get started with your inventory and your rationalization, then you can just expect more data to come along later to help you out. In the interim, you can at least be identifying the projects that require a lot of work, and get started on them now. It’s simply a lot smarter to get any fixes you may need (to play nicely with the new security posture begun with Windows Vista and continuing with Windows 7) by working them in to the natural development and deployment cycle of your software today, rather than it is to try to squeeze them all in at the same time only when you begin the deployment of an operating system later.
I hope this little review is helpful for formulating your tools strategy if a migration to Windows 7 is in your future…
Updated: Added co-presenter info, and corrected 2 typos.
The 2009 conference season has begun, launched with an internal Microsoft conference: TechReady 8. So, while not everyone can be there, it’s fairly representative of what there is to come at the public conferences happening later in the year. Clearly, I want to learn everything I can from the internal one so we can really deliver some great stuff at external conferences.
Not that internal folks deserve any less, just that we can take more risks. And take risks I did. It turns out that, if you show a photo of the COO of your own company immediately after a photo of Darth Vader to a bunch of people who report through him, they pause a moment before they laugh…
So, what am I presenting this season?
CLI318 What's New in Application Compatibility for Windows 7
CLI400 Writing Compatible Applications for Windows Vista and Windows 7 (with Aaron Margosis)
CLI401 Mitigating Application Issues Using Shims
CLI402 Debugging Application Compatibility Issues (with Gov Maharaj)
CLICT306 Q&A with Chris Jackson and Aaron Margosis
Now, let’s look at the scores that people provide for this conference:
Q1 The speaker was knowledgeable about the subject matter.
Q2 The speaker's presentation skills helped me better understand the material.
Q3 The content was effective in achieving the stated learning objectives.
Q4 The demonstration(s) were effective.
Q5 This session builds skills improving how I sell, market, and/or provide services to our customers and partners.
Q6 The knowledge/skills I gained are relevant to my role.
Q7 This readiness solution was worth the investment of my time.
Q8 I will recommend this readiness solution to others.
Q9 Overall, I was satisfied with this Session/Chalk Talk.
Q10 Content Level: Please rank the level of technical information actually delivered.
Q11 Please provide additional constructive comments, suggestions, feedback.
QAvg Average for all questions combined
Let’s take a look at my ranking compared to every other session. This year, there were 734 breakout and chalk-talk sessions. How did I stack rank on these sessions?
Now let’s look at the comments:
CLI318
Great content, great speaker. Great job Chris
This kind of session are the most useful for CSS guys, I wish there was more of them.
The session was somewhat chaotic. I know the speaker can do better. Found it hard to understand all.
I would suggest to rename the session and the description. The initial expectations were more oriented in understanding how the OS evolves ... but the session when more into demoing how to program to leverage new OS features ... which is fine ... but need another name for the session Been a .NET programmer I was able to understand the demos, but I guess some infrastructure people were not able to gain as much knowledge as they expected
PLEASE UPLOAD TO ACADEMY MOBILE. IT'S A MUCH BETTER OPTION THAN VOYAGER
Great speaker!
Great presentation!
CLI400
Very useful
Session too unstructured - I hate "death by powerpoint" as much as anyone, but a few slides would have helped the flow and would re-inforce the key points. Also, too often some important knowledge was assumed without good reason - i.e. one new Vista feature was used to explain another without checking the attendees were aware of it. For example,Integrity Levels were used to explain some UIPI, but then it turned out the audience weren't too familiar with them, so had to backtrack.
This is simply the BEST SESSION OF TR8! Awesome is the only word- ability to deliver all we need without PPT is just great!
GREAT INFO! After the session I was up giving a suggestion about making this available as a WorkshopPLUS to our customers. The ADC (Application Development Consultant) should be able to levarage your content as a WorkshopPLUS event through Premier Support. My recommendation would be for you to hook up with Premier Services offering leads in making this happen.
CLI401
One of the best sessions I've attended so far.
Excelent presentation ... keep up the good job ... I would really like to see HOL on this topic ... I think it is very important to ensure the deployment
CLI402
This session should be a model
This was over my head, my fault. Should have read the description more carefully.
Great stuff, wonderful to see a core debugging session @ TR8
it would be nice to have some one-page hands-out that describes how the application are debugged and what's the learning points from that debugging session. This can be used as a "cheat sheet" by the field when they perform application compatibility work.
Content was over my head
Good session. I wish more sessions were technical like this.
thanks
This session was just excellent! Chris and Gov clearly stated all the big implications involved in the compatibility subject in Windows. Good Job, guys!
Chris did an excellent job presenting - very polished speaker. Gov also did a good job speaking and was entertaining. Both were very knowledgeable of the subject matter, and the session made me aware of the differences of how the appcompat team approaches problems compared to those of us in GES. Very useful session and content!
CLICT306
Analysis
The scores kind of mapped up to my initial impressions. Overall, I thought it went well and was a lot of fun, but I didn’t “nail” any of my sessions, so no #1 session for me this go-around. Not even top 10’s. But they were all top-25, and there were a number of highlights.
I need to finish figuring out the Windows 7 app compat story. This one has been stretching me a bit. You see, we’re really not breaking a lot more. So, the story is a lot the same as the Windows Vista story, with a few minor tweaks. With Windows Vista, you could ramble on for hours about all of the security features that broke stuff. For Windows 7, you have to get kind of obscure. So the conversation either diverges to hard core technical, or it rises up to strategic with a little technical flavoring. Either way, I clearly need to just pick one, because people didn’t walk away feeling empowered to actually get something done.
I really need to work on the developer story. Aaron and I whipped up some decent content, but it felt unstructured because it was. We were taking ideas and throwing them against the wall. Some of them stuck, others didn’t. We really needed to have this experience, I think, to do it right. But now that we’ve had it, it’s up to us to really nail it next time. One guy was calling for more PPT. I don’t think you need PPTs to organize, but you clearly need organization!
The debugging session needs to be clear what it is. Some people ended up feeling it was over their head. So, I renamed the session for TechEd (assuming it gets accepted) to “Not for the Faint of Heart: Hard Core App Compat Debugging” so expectations can be more clear.
It’s a blast presenting with Aaron and Gov. I always love working with Aaron – I had no idea what it’d be like working with Gov. Awesome. We played off of each other well. Aaron and I have a very Odd Couple-esque on-stage relationship which is fun. Plus he’s so damn smart. Gov is just authentic hard-core to the bone who can debug on a stage much like Eddie Van Halen can play guitar. All I really had to do was narrate. He was constantly laying down a solid rhythm track, and watching him solo is a sight to behold.
People like the hard stuff. Every time I have a crazy-go-nuts deep session, it just really jives with some folks. Now if I could just get my explanatory abilities to the same level as Mark Russinovich…
Shims are still relevant. In the 2008 season, I had two sessions. I combined them into one, and it’s still getting good reviews and comments. So, looks like this one is still interesting and helpful.
As always, I want to make sure the conference content helps you do your job better, so if I’m missing a category of learning you wish you could get at TechEd or some other conference, then make sure to let me know.
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.