When I talk to folks who are extraordinary engineers, but who are struggling to extend their impact, the #1 recommendation I give is to find your voice and communicate. And just keep communicating. There is no substitute for practice.
And, it turns out that the sort of folks who really excel at app compat can sometimes struggle with this, as there are far more introverts than extroverts in the troubleshooting and debugging realm.
There are a couple of notable exceptions, which I wanted to call attention to, because they’ve really found their voice and are broadcasting loud and clear.
I met Gov back in 2006, and he (along with Robert Paige) quickly demonstrated that not only was I not as smart as I thought, but indeed may be one of the dumber people around (certainly in that hallway in Building 27). Now, Gov has a background in teaching, so he is no stranger to talking. But when we first met I didn’t see him doing this as much. I’ve always thought he was phenomenally smart, patient, and interesting to listen to, so I started volunteering him every time there was a speaking opportunity. (I think this was the first time we were on video together.) It seems as if he likes it – because now he has his own freaking show:
The great thing about this show is that the real Gov really comes through. The room is dark, just like his office. If, instead of having a monitor behind them, he had 5 monitors in front of him (4 containing hex, and the 5th containing some science fiction show – is it Stargate? – I forget), then it’s not that dissimilar to having a real conversation with him. Except he has far, far more empty soda cans on his desk. In fact, it’s incredibly strange to watch him sitting at a clean desk…
I honestly can’t remember when I first met Andrew virtually – we coexisted on various technical email aliases for a long time and gradually built this mutual respect for one another. Earlier this year, he started writing fairly consistently for MSDN Magazine and sharing his passion for automating difficult processes, taking a little-known but powerful concept of extending tools such as the Debugging Tools for Windows in deliciously geeky but still approachable ways. If you are interested in really stretching your debugging skills, or just understanding the debugger platform better, then they are absolutely worth the read:
What’s interesting from a historical perspective is that we originally thought that dbghlp.dll was the critical component we were shipping, and that cdb / ntsd / windbg were supposed to just be demos of what people could do with the platform, and then there would be healthy capitalistic competition for who could build the best debugger on top of this. Well, it turns out that people would rather that the debugger be free for a given platform, and mostly people aren’t interested in buying debuggers (though there are some, which fill in some whitespace areas for the sdk / ddk provided tools). But extensibility was always at the core of the platform, and though debugging at this level is mostly a dark art practiced by very nerdy people, the strength of the provided tools and the platform I still believe is one of the massive competitive advantages that Windows holds over other platforms.
What is your strength / passion? Do you like to talk? Do you like to write organized articles? Do you like to write interactively on forums? No matter your medium, it all improves with practice. And there are folks who are shining pillars of how that practice can pay off in terms of massively magnifying their impact. If you see / hear / read something and think to yourself “I could totally do that, probably even better than that person” you are likely to actually be correct. Why not do that in 2012?
There have been a number of efforts we’ve been going through lately to promote users running modern versions of Internet Explorer. We have been marketing and advertising since release of course, and over the summer we added a prominent advertisement. Then, we recently announced that we plan to start doing automatic upgrades, in line with the approach taken by other browsers.
However, it has long been important to us that we leave the owner of the PC in control of their PC, and if you are an organization that means that your administrators should be the ones in control. We’re not trying to subvert an intentional choice, our goal is to simply default to the better choice (which is to be more secure and support modern standards) for those who would rather not be troubled to answer yet another hard question from their computer.
So, if you are running Windows 7, you may not have validated your readiness for IE9 yet, so you don’t want an auto-upgrade. We, of course, will respect the IE9 blocker toolkit – so you can go ahead and apply that. However, when we announced the updates, it happened to come on December 15. Anyone working in the retail sector knows full well that the holidays is when all of technology freezes – not only no IE upgrades, not even a blocker kit! That has simmered down since the holidays passed, but there is still a sense that you’re being forced to install something to stop the install of something else – and the fact that we call it a toolkit makes it sound complicated. So, I wanted to take a look and see what was in that toolkit, to see just how scary it was.
The first thing that surprised me was that it contained an ADM file. Since it’s for IE9, the blocker is only necessary on Windows Vista and above, which replaces adm files with admx files. Why we’d put in a legacy format I cannot explain, so I just ignored that and went over to the cmd file – I just didn’t have the patience to convert and wouldn’t blame you if you didn’t either.
So, what does the cmd file do? Well, it’s 69 lines of text, but at a glance it seemed more complicated than perhaps it needed to be. First of all, it turned @echo off, but then proceeded to echo a lot of output which nobody would ever see – I didn’t see the point of that, so I pulled those out. I found a REM and pulled that out as well. Once I’d cleaned that up, I could see that it had branches for usage, blocking, and unblocking. So, I wanted to focus on the blocking scenario first. It turns out to be a single registry key:
HKLM\SOFTWARE\Microsoft\Internet Explorer\Setup\9.0
Add a DWORD value DoNotAllowIE90=1
That’s it. How does it unblock? It just deletes that registry key.
This was discussed in TechNet Magazine back in April of 2011, but in the emphasis on explaining the various options provided, I’ve still had some customers who just saw that there was a whole kit, with several components, and didn’t dig much deeper before getting worried that it was too complex. In the end, it’s just a registry key. Personally, I think setting a single registry key sounds less scary than a toolkit, and I can’t name a single IT Pro who can’t deploy a registry key easily enough.
Moving people off of older browsers onto newer ones is something we have been pushing hard for at Microsoft. The latest version of IE is significantly more secure than older ones, and way more interoperable. (Who really wants to develop 2 websites when they really only want one – one for some crusty old version of IE, and another for everything else?) However, historically, upgrading the browser had a very pronounced install experience – it felt like a really big deal, and was pretty scary. My mom, who by now has been trained not to install stuff as her default reaction, isn’t going to be aggressively looking for an install. She would get left behind on such an install.
So, to help reduce that friction, we’ve announced that we’re going to help keep people up to date automatically, to remove that install experience.Details are here: IE to Start Automatic Upgrades across Windows XP, Windows Vista, and Windows 7.
Now, my area of concern is the enterprise, where I also want you to have a modern browser, but I want you to have the chance to validate that you won’t have productivity failure when you do. So, we provide tools to block the install of Internet Explorer 9, Internet Explorer 8, or Internet Explorer 7 until you are ready. (Please, don’t forget to get ready – particularly if you are blocking IE7!) This will block the automatic upgrade, as well as the Windows Update suggestions.
What this will not stop, however, is web advertisements. And because we care about IE adoption, it turns out we advertise rather a lot. Users running older browsers, if they head over to microsoft.com/ie, will find this:
So, even though we stop users from automatically having an upgrade, we’re still putting the idea in their heads. And there is an advertising campaign which I’ve recently heard a couple of customer comments on: the web slice for the IE add-on center.
Here’s what it looks like if you are up-to-date:
But, if you are running an older version of the browser, it will suggest upgrading to the new one:
The feedback I’ve been hearing from the couple of customers who have reached out is that they want to block their users from seeing these advertisements and choosing to upgrade. How do they do that?
First, to point out where we see this – this is a default web slice, so the folks who notice it are those who run a lot of clean machines, so it’s far more visible to those in IT who look at clean builds than it is to end users who have had some time to customize.
It turns out that it’s super easy to block the impact of advertisements for IE9 and stop that upgrade:
Make your users non-administrators.
Not only is it easy, it’s the only effective way to do it. Even the blocker toolkit won’t stop a determined administrator of the computer. It’s inherently self-contradictory to ask how to limit a set of users to whom you have granted unlimited power. I worked with one customer who was sure that everyone was running IE6 and that nothing else would work. But, since they had local admins, some investigation led us to discover that they had an entire continent running an updated version of the browser, and that despite this they were still in business on that continent!
Which, of course, leads to plan #2:
Let ‘em.
Hey, if they’re admins anyway, you can be sure that there is all kinds of stuff on there that you haven’t explicitly approved of. (In my travels, I’ve come across one and only one software inventory which did not contain “World of Warcraft.” I’m just sayin’…) If they call helpdesk, just update the script to check the version of the browser, and ask them to downgrade if it’s not your standard and they want support. Otherwise, consider it free testing. What do you think happened to the customer’s perception of the risk of moving to the latest browser after they discovered that an entire continent already was? It went way, way down. If they are admins, they can do what they want, and no group policy is going to stop them. (Have you ever tried to block a policy from doing something? It takes under a minute – if you are an admin.) Pretending you are in control of local admins is not the same as actually being in control. If you need to actually be in control, see the first bullet above – making users non-admins.
Of course, some customers would prefer more options, and IE is, as usual, extremely friendly to the administrator. Another thing you could do:
Turn off favorites bar
Yep – if you make the favorites bar go away, then the web slices go away also. (It’s off by default in IE9 anyway, so perhaps it’s UI training?)
You could also block the URL, but that seems a tad drastic to me. You could also go after whacking the file - after all, it's just a shortcut called Web Slice Gallery sitting in the Favorites Bar subdirectory of the user's Favorites folder. A bit primitive, but it would get the job done.
In the end, it’s just an advertisement, but it’s a fairly visible one. The administrator will always be in control of that upgrade decision. If I can help you with web site readiness, I’m happy to do so in order for you to move forward as well!
Developers, and the people responsible for the productivity of those developers, have long known that code reuse was something we should aspire to.
Don Box, in his seminal book Essential COM walks through the progression we made in the Windows world around code sharing. I strongly recommend reading through the entire work (which I won’t reproduce here), but I’ll summarize the first few pages:
Writing everything from scratch is too expensive
First we have to overcome developer resistance to code developed by somebody else (which remains a struggle sometimes). But we achieved this, and the C++ language made this easier. Now, we could share code as libraries which you could re-use by simply calling into the classes that provided the functionality you wanted. Great news! But eventually we ran into a little problem…
Having a unique copy of this code for every app consumes too many resources
There was a time when we didn’t have 1TB hard drives and 8GB of RAM in our computers – we had to be parsimonious with these resources, and having many copes of a particularly useful library meant that we weren’t using these resources as wisely as we could. So, along came dynamic linking, which allowed us to share the same copy from disk, as well as to leverage tricks in the memory manager to back multiple instances in application virtual memory with a single instance in computer physical memory. Great news! But then we run into a bit of a problem…
There is a lack of standardization at the binary level
Once you try to link against a dll compiled using a different development environment, you may run into important differences, such as differences in how name mangling is implemented. That makes it difficult to have truly universal components! Plus, while C++ supports syntactic encapsulation, it doesn’t support binary encapsulation, and your application must know everything about an object layout in order to instantiate a class. No problem – we can solve that by dividing interface from implementation (they are joined by C++) so the layouts won’t change.
Carrying on (reading the remainder of the story is left as an exercise to the reader – a very valuable exercise), Don discusses runtime polymorphism, object extensibility, and resource management, to eventually engineer COM.
So, why I am talking about COM? Because I’m seeing something very parallel happening right now in the world of web applications…
Developers are finally embracing this fact, and starting to reuse more than ever. We see this when people use weblog software to communicate, rather than writing HTML. We see this when people buy software which generates ecommerce sites for them. But, most analogously, we see it when developers opt for reusable libraries others have created to save themselves a lot of time re-implementing the basics. So, rather than write everything from scratch, more and more developers are using libraries such as jQuery. Great news! But eventually we ran into a little problem…
No, we didn’t run out of RAM or hard drive space (we’re in the cloud, baby!), but something else happened…
Having a unique copy of this code for every app introduced too much security and compatibility risk
If you recall back in 2004, you may remember the bug in GDI+ which affected a lot of applications. Now, had this been linking against a single copy, we could have just patched the operating system. But, alas, GDI+ is redistributable, so not only did we have to patch the OS version, but every application which chose to redistribute GDI+ had to ship its own updates. How many of those are there? Nobody knows for sure! By redistributing it, you know that you have it, and that it has a compatible version to your application, but you also take on complete responsibility for managing somebody else’s code as part of managing your application!
Alas, this is exactly the state we are in for web applications. If you choose to redistribute a library, such as jQuery, you are also choosing to take responsibility for keeping it updated. It turns out that there are a number of bug fixes you would probably benefit from. More importantly, browser support keeps changing. As new browsers are released, new bugs are surfaced and fixed.
The customers I work with are enterprise customers, and as a general rule enterprise customers love to standardize on things. If you standardize on an older version of jQuery, you’re limiting your ability to perform a browser upgrade without applications failing on the new browser. (If you swap out jQuery, you also have the potential for the application to fail because of jQuery incompatibility, though that probability appears much lower in my experience.) Even if there isn’t a mandated standardization effort, there is almost never a programmatic, organizational effort to track and update implementations of jQuery, and therefore this comes up regularly as app compat issues with block IE9 upgrades
How will we solve this one? I have no doubt that we will, given how systematic the potential problem is and the importance to developers and the industry in solving it. I suspect there will be several steps along the way, we’ll eventually come up with an elegant solution that at least one person can actually understand, and some even bigger change in technology will disrupt that work and we’ll be on to the next big thing. But, for now, you are accountable for managing this.
Are you aware that you are accountable, and are you managing it?
I wanted to document a bit of detail about managing the Program Compatibility Assistant, a bit of technology we added for Windows Vista and have been enhancing since that time – I figured it was probably time that we came out with an update for Windows 7.
What motivated this was a series of conversations where a number of people were recommending that the well-managed enterprise should turn the feature off in its entirety. This is a recommendation that I do not generally concur with (though there certainly may be very specialized scenarios where this is a good recommendation). Rather, I prefer to tune it when there is a problem. For this reason, I also wanted to call attention to the fact that there is a completely separate area of group policy (for reasons I am completely unable to explain) which provides individual knobs for many of the PCA scenarios implemented in Windows 7. If you are having problems with a particular scenario, then it’s better to turn off that one specific scenario than to throw out the baby with the bathwater. With that in mind, below as I describe the various scenarios of group policy I will also include that scenario’s group policy switch when it has one, along with reasons why you might want to disable detection for that scenario.
But, before we begin, a brief word about PCA. The idea here is to try to reach the long tail of the Windows application ecosystem. Keep in mind, though we have a fantastic testing team and significant manual and automated tests, we’re still testing software on the order of 103. Beta testing helps more, but beta testers aren’t that much more happy with application failure than any other user. So, we are looking to automate some of the work done by the app compat team.
What are we looking for today, and how can you configure it?
In this scenario, we look to see if you are detected as an installer, using UAC installer detection. If so, we compare the Uninstall registry key both before and after the installer is run. If nothing new appears, we guess that you might have failed, and display a PCA prompt. If you accept the fix, we apply the WINXPSP2 layer.
Detect application install failures disables this check, though it’s usually fairly benign. We used to have a lot of trouble with this one, as we still ran it even if you had a UAC manifest indicating asInvoker (a fairly good indication you are not an installer) and tried to install a VISTARTM layer, but based on your feedback I successfully campaigned to get this removed in a February 2010 Windows Update. It doesn’t really affect standard users, who aren’t able to install software anyway.
In this scenario, we just track the ETW event for STATUS_ELEVATION_REQUIRED (0xC000042C). We’re pretty much always right on this one, as the fix is always to apply the ELEVATECREATEPROCESS shim, so we just go ahead and do it. (I have no idea why we still bother to show you a dialog box. Apparently somebody didn’t read the memo.)
Detect applications unable to launch installers under UAC disables this check, though I can’t think of a reason why you’d want to. Yes, it results in a UAC prompt, but your alternative is an error – at least the prompt tells you what’s going on.
This scenario just implements a check in ole32 against a hard-code list of deprecated DLLs. When we find one, we give the user the chance to check for a solution online.
Detect application failures caused by deprecated COM objects disables this check, and I’m kind of on the fence for this one with standard users. Yes, it points them to a solution that enables them to potentially find an installer they can’t use, but at least your help-desk call comes with a solution, and not just an non-debugged failure. I would consider leaving this one on, I just haven’t heard any reports of it being problematic and it has the potential to solve some issues that normally requires nerds spending time with depends.exe.
This scenario implements a simple check (in ntdll) for deprecated DLLs, again going against a hard-coded list. Once again, we’re fairly accurate here, and the solution is to give you a web link which might assist you in debugging.
Detect application failures caused by deprecated Windows DLLs or COM objects disables this check, and again I’d consider leaving this one on unless you encounter a specific problem with it. Again, I’ve not heard of such a scenario, but that doesn’t mean it doesn’t exist.
This scenario looks for applications which are not detected as setups by UAC setup detection, but which try to create a new folder in Program Files (which we detect using UAC virtualization events – so UAC virtualization needs to be enabled to satisfy this scenario). Back in Windows Vista, we also required you to try to drop a dll or an exe into the folder you create, but that is no longer the case in Windows 7. If we detect this, we give the user the option to apply both VISTASETUP and RUNASADMIN to the application.
Detect application installers that need to be run as administrator disables this check, which you may want to do for standard users. If the user picks the wrong option as a standard user, they make themselves unable to launch the application again, which would be rather suboptimal for false positives. Since there’s no real benefit here, and potential downside, it’s the one scenario I recommend disabling most frequently.
This scenario doesn’t even really have a heuristic. Basically, if you are a control panel applet, and you don’t have a manifest, we ask every single time, “hey, how did that go?” If you say that it went poorly, we apply RUNASADMIN.
This scenario doesn’t have a group policy controlling it. Back in the Vista days I would see it from time to time, but I haven’t seen one in several years now. What I used to do when I found them in an organization was to add an entry into the shim database which makes the correct choice for the user.
This scenario is pretty much the opposite of install failures, though it has the more reliable launch point (the add/remove control panel execution rather than a setup heuristic) not detecting changes to the Uninstall registry key. If you do, we apply the VISTARTM layer (if you have a UAC manifest) or the WINXPSP2 layer (if you don’t).
This scenario also doesn’t have a group policy controlling it, but in my experience is benign and safe to leave enabled.
Since we don’t allow you to load unsigned drivers on 64-bit Windows, but some folks try to sneak them in anyway by manually flipping the registry keys, we monitor changes to the registry key and disable them if they are added here.
Notify blocked drivers disables this check, but unless you are a driver developer there isn’t much sense in disabling this.
This is actually a fairly complex scenario. If you trigger the Installer Failure scenario, and the user chose to put you into compat mode, then we mark the shortcuts that installer created. Then, when you launch one of those shortcuts, after you exit, we asked if the application worked for you, and give you a chance to launch the Program Compatibility Troubleshooter. The reason here is that, if the installer needed VISTARTM or WINXPSP2 to install, then the application itself might also.
This scenario doesn’t have a group policy, but disabling the Installer Failure scenario would have the consequence of disabling this check also.
This is our nerdiest scenario. We made a chance in the windowing subsystem that changed how exceptions were handled within callback functions. When an exception is triggered in user mode, older versions of Windows would hit a challenge going over the user mode –> kernel mode –> user mode boundary. A native 64-bit application simply wasn’t able to propagate that exception back if it wasn’t handled before making that transition. So, if your thread creates a window, and that window throws an exception, you can’t handle that in the code that created the window and receive the exception. So, we had a choice: we could either crash the application when the exception was thrown, or just swallow it and hope for the best. For app compat reasons, we swallow it and hope for the best.
We changed this for Windows 7, as just swallowing exceptions is really not a terribly good idea from a debugging or application quality perspective, and allowed exceptions to come through for 64-bit processes on x64. So, if an application were throwing an exception before but had to transit kernel mode along the way, we were just swallowing it before. Now, we pass it back up the stack.
I’m sure you can see where this is going: applications which should have been crashing on earlier versions of the OS, according to their own code, were being handed a get-out-of-jail free card, and not crashing because they happened to transit through kernel mode. Now, they no longer have this card, and if they don’t handle the exception, the application will crash.
This scenario detects that an exception transited a user callback (ntdll!KiUserCallbackDispatcherContinue) and if this exception leads to the application crashing because it wasn’t handled, we revert to the earlier behavior by applying DISABLEUSERCALLBACKEXCEPTION.
This scenario doesn’t have a group policy, but we are very accurate and this is precisely the sort of thing that PCA ought to be fixing for you.
Are you seeing a trend here? The earlier PCA scenarios, which existed back in Vista days, are broad brush heuristics, primarily focused on the big hurdle of UAC and running as standard user. What we added for Windows 7 was much more targeted, higher accuracy, and the sort of thing you’d really kind of like going in the background fixing your stuff from bugs in corners of your applications you haven’t found yet. As more of these come in the future, you want to make sure you are opting in, which is why I always guide people towards leaving the feature enabled, and at most disabling troublesome scenarios if they indeed become troublesome.
I always like to take the opportunity to do a favor for a friend. And, if that favor is “put on a headset and talk geek for a while” well, that’s hardly work at all – in fact, I normally just call that “being awake”. So, in that spirit, when my friend Emily from ChangeBase asked if I would chat for a bit about IE9 with her and my friend Greg, how could I resist?
Here is our conversation:
Chris Jackson, The App Compat Guy, and Greg Lambert, Chief Technical Architect, ChangeBASE, talk Internet Explorer 9
It’s only been 3 months since I last reported in on ACT vendor assessments, and some changes we made to improve the match rate which you can expect to find when you sync and start looking for vendor data. Now that we’ve performed the update, I wanted to report back on how things have improved.
The good news is that the match rate on an ACT inventory is now more than double what it was back in April, when we began the latest initiative around improving that match rate. My hat goes off to the team who executed brilliantly against this objective – that’s going to end up saving a lot of time for people migrating away from Windows XP.
My friend Marc, who is a PM on the ACT team, went on to perform some additional analysis on match rate, to see if we can understand which factors contributed most to improving the success rate. Now, I had a hunch that simply being a company that operated outside of the US would be a factor, as anecdotally I found lower rates if I was working with a customer outside of the US, but I couldn’t prove that quantitatively. Unfortunately, we don’t have that attribute to data mine, and though he tried to approximate that by dividing those inventories that had at least one foreign language application in them, the outcome was utterly inconclusive.
What he did find, however, was a strong relationship between the match rate you can expect to find and the size of an inventory. Those with smaller, well managed application portfolios also had the side benefit of having a higher match rate! Here is how the data maps out (through August):
Hopefully, if you are using ACT, you have been able to benefit from the investments we made to improve the match rate and save yourself a bit of time. Perhaps now is also a good time to consider rationalizing away a number of your applications if your ACT inventory is bulging in the 100,000 range…
I had a question come up from a customer: so, IE9 JavaScript performance is faster, and IE9 has 4 different document modes – are there differences in JavaScript performance across the document modes?
Now, I kind of suspected that the answer would be yes, but I didn’t actually know any details – and as a general rule of thumb, I don’t like to just assume that what somebody else told me is true (or even that I am actually remembering correctly – I’m not getting any younger, you know) so I figured we would run a little experiment and see what happened.
I decided to use the SunSpider performance benchmark, which tests JavaScript performance. While there is a newer version available, that newer version doesn’t work with older rendering engines, so I had to run the older version. This is the specific test that I ran:
http://www.webkit.org/perf/sunspider-0.9/sunspider-driver.html
I then ran this test in each of the 4 rendering modes in IE9, and for good measure I also threw in a test of the latest Firefox and Chrome. These were the results of running the test in an uncontrolled environment, a single time, on my computer – I am not attempting to make a scientific statement about absolute performance, just to gain an understanding of whether there are differences which are large enough to matter.
Wow. The outcome seemed really clear to me: when in IE9 or IE8 standards mode, IE9 performance is very clearly competitive with other modern browsers. However, once you drop to the two oldest compatibility modes, performance drops by an order of magnitude – that’s a big deal!
Since Compatibility View is the default for the Local Intranet zone, I would therefore strongly consider a program of enforcing the inclusion of X-UA-Compatible headers to opt in to one of the modern document modes in order to maximize the performance of your enterprise web applications, which is precisely the advice I gave to my customer.
If your JavaScript performance is not what you’d hoped in IE9, perhaps you should press F12 and check your document mode…
For those of you attending TechEd Australia, if you are interested in application compatibility, there are two sessions you won’t want to miss tomorrow (September 1, 2011):
Troubleshooting Application Compatibility Issues with Windows Internet Explorer 9
When your website doesn’t work with a new browser, what do you do? In this demo-heavy session we explore the primary causes of application troubles, take a deep dive into the compatibility infrastructure in the browser, and give you helpful tips and tricks to accelerate your application compatibility troubleshooting and remediation.
Troubleshooting Application Compatibility Issues with Windows 7
In this demo-heavy session we examine a series of case studies for troubleshooting application compatibility issues with Windows 7. Using this approach, we show you more about how Windows 7 works and how to think about and resolve application compatibility problems based on real-world examples. In addition, we demonstrate the tools you would use to resolve these issues.
(Note that my session will have 100% more wombats in it than the typical TechEd session.)
Don’t have enough cash to attend TechEd Australia? Well, if you were really looking forward to the app compat content, I’ve got you covered. Tomorrow night (Monday, August 29), I’ll be speaking at the Brisbane Infrastructure Group up in (not surprisingly) Brisbane. The talk will go from 5:30 – 7:30pm, and will be as interactive as you can make it. It’s going to be held at the Microsoft office at 400 George Street.
For more details, or to register, see: The AppCompat Guy Talks (a.k.a. Chris Jackson). I hope to see some of you there!
OK, so it’s not as famous as e=mc2, but here is the rule I apply for when to test an application for app compat.
You should test your applications when:
cost failure × probability failure > cost testing
You should otherwise not bother to test your applications – just fix them reactively through your standard helpdesk processes. From a business perspective, it just doesn’t make sense to pay more to avoid a risk than it would to just march straight into it and have to pay that fine. I mean, if I offered you a “get out of traffic court free” card for $1000, and traffic tickets cost $100, how many would you buy from me?
In my ongoing efforts to clear out all of the low hanging fruit and leave behind all of the fun, gnarly, nerdy problems, my latest article on TechNet Magazine was just published. This one addresses Internet Explorer 9 application compatibility, and avoids much of the nerdy stuff I normally focus on to instead focus on having a great process and approach which gets us more efficiently to the fun debugging at the end of the yellow brick road. Feel free to send me feedback!
http://technet.microsoft.com/en-us/magazine/hh360991.aspx
I haven’t done a recap post since TechReady 9 for some reason, but I figured it was about time to take a step back and think about the state of app compat presentations, and how I could continue to make them better.
At TechReady 13, an internal Microsoft conference, I presented 7 breakout sessions, but only 6 of those received at least 10 survey responses. here are the scores:
In order to make the scores relative to competition, I rank ordered them and placed the rank order here – absolute scores aren’t terribly interesting, particularly given the severe skewness of scores at technical conferences. (The average score at TechReady is around 4.5, meaning that any person who rates you a 4 instead of a 5 is technically rating you below-average.)
Here are my conclusions, based on this data:
People think I know what I’m talking about
That’s good to hear – the top row is notably better, and thus people think I have some sense of what I’m talking about. I hope they’re right… I’m also doing well in terms of demos. Presentation skills is a little lower than I normally expect – I wonder what the underlying cause is there?
The case study refresh is helping scores come back up towards the top
The original app compat presentations were based on demo applications, and these have been around for a while. At the beginning of the year, I did a complete overhaul, and moved from having slides and demos to instead having a few introductory slides (since I still get about 1/4 of the audience new to the discipline), followed by a series of case studies. That’s right, real applications that we apply tried-and-true debugging processes to. That, in fact, was the entirety of the Debugging session, where my friends Trey and Andrew just went through studies of how to apply WPT and/or WinDBG to solve real customer problems.
IE is the harder one here, as I have been using live public websites, and as more and more people use IE9, more and more of these get fixed. I mean, that’s great from a web ecosystem point of view, but it does kill my demos. I spend the morning before the presentation going over everything to make sure it’s still broken that day, and I’m still crossing my fingers!
I still haven’t nailed the conversational format
Scores are coming up on my idea to have a great conversation between product engineering, the Microsoft field, partners, and customers. At TechEd 2011 North America, I had a customer panel, and scores weren’t so great. So, I reimagined the session, and instead had a product engineering panel, where I brought in Eric Lawrence (who is the PM Lead for Fundamentals for IE) and Adrian Bateman (who is the PM in charge of coordinating our HTML5 standards efforts across all of our products) and set about asking the hard questions that I receive from the field and from customers, and left lots of time for audience participation. I had some fun with it, doing it up like a talk show, commercials and all. Scores came up quite a bit, but it’s still the bottom of my session list. So, am I just not executing it right, or is the concept flawed?
Some people are insane
Despite having two of the finest escalation engineers I know doing live debugging – including troubleshooting a problem that Mark Russinovich hadn’t found! – I still had 2 (two) people rate the debugging session a 200-level session. Really? You think 75 minutes of pure demo with nothing but assembly language on the screen is marketing?
I need to figure out how to refresh
Typically, I only see people once a year. So, truth be told, most presenters have a set of sessions they deliver throughout a calendar year. I did my refresh in January, and figured it would last through 2012. I mean, creating a pile of sessions is HARD – and there isn’t enough time to do a pile of new sessions every couple of months plus do actual work. However, with today’s recordings at nearly every session and every conference available for free, I’m starting to get a lot of people complaining that they saw this content from the previous conference. So, given that it is already hard enough to do significant overhauls once a year, how do I do that every couple of months in order to meet this expectation, but still satisfy the people who have never seen me and need the introductory content (which is necessarily somewhat redundant)? I think this is going to be the hardest problem to solve for folks gunning for top slots. I’m already throwing in a few new case studies each time, but there is a lot of carry-over today.
One query that comes in quite a bit from the IT Pro community around IE9 is this: what happened to the zone indication from the status bar? Zone information, for both the Developer and the IT Pro, can be pretty important. It determines the security context the page runs in, as well as the application compatibility defaults.
I was pretty curious about this myself, so I chased down the answer from the development team.
In the initial development work, two themes were really coming to the forefront in IE9: performance and user experience. As performance work was taking place, somebody discovered that the zone display was not terribly well optimized – displaying that little icon and text, as it turned out, took about 40 million CPU cycles. Now, in the days of 2.5 GHz processors (what have in my vintage T61p), that’s only 0.016 seconds, so not the end of the world, but that adds up. We cut the display and got the performance back, but moved the information (which was still important) over to the properties page, accessible from a right-click on the page.
Could we have optimized that code so it was way faster? Of course we could have – it’s just code. But the time we spent writing code to optimize zone information display is time that we’re not making the JavaScript engine faster, or time that we’re not making Canvas faster, or time that we’re not making the platform more robust. While it might have been a good use of time, it wasn’t the best use of time, and shipping is about trade-offs.
We then came along and cleaned up the UI even more by hiding the status bar by default. This takes away still more of the browser chrome, leaving more room for the site, which is really what you launch your web browser to have a look at.
And this, of course, sort of nullifies the original performance argument – if the information isn’t shown until you ask for it, then the performance is no more an obstacle here than it is on the properties dialog. (And you could argue that the status bar, by removing all of the information from the status bar except for zoom that it really probably should be called the zoom bar now.) Could we have put everything back after making this decision? Of course we could have – again, it’s only code. But once again, that takes time – time not spent doing other things which arguably help the web more than building back up the status bar. Once again, we had to make a trade-off. Given perfect knowledge of how the UI would evolve, I imagine we would have left it as it was, but just hidden it. Alas, we lacked perfect knowledge.
So, by having two good intentions (make it fast and clean) we ended up having to retrain folks on where to find a bit of useful information. It’d be great if we could take that back, but now it makes sense to me how we got there, and hopefully this adds some perspective for you as well.
Hitting at the very top of my FAQ list is still, “hey, I just did a sync with the ACT Compatibility Exchange, and the match rate was (insert number between 2 and 6 percent here), and that makes me angry and/or sad. Please explain to me why you suck so much.”
First, let’s get the expectations straight. 2% to 6% is what we typically find in terms of vendor match, even today. So, if you’re hitting that number, then you’re doing pretty well. Why is that number so low? Well, there are a couple of reasons.
First, the vendor data we are reporting is based on vendor support for an application. If you don’t have vendor support, then you don’t show up in the database. For sound financial reasons, it behooves vendors to say as little about support as possible. It’s like insurance. If you say you support it, then you have to take the call and work the case and fix the bug. All of those things cost money. So, you do it as seldom as you can. If you are building a niche product, and all of your customers are on an older version of Windows, you’d prefer to not bother to invest in a platform your customers are not using, and use that money to generate business value that helps you sell more products. At some point, though, enough of your customers are there that suddenly it starts to make sense to offer that support, which at that point might even be a competitive advantage. If you’re a larger or more important app, then you’d prefer to have your customers give you some more money (in the form of a new version) before you give them new support, if you can possibly talk them into it. So, if you’re using a slightly older version, it won’t map up to a support statement, even if there is a newer supported version, because you’re not using the one which would match.
Second, we have a significant long tail problem. There are an awful lot of apps out there. Simply trying to get your arms around the scope of the problem is non-trivial. While I’ve seen as many as 110,000 applications in use within a single organization, an average number is probably somewhere in the range of 3,000 to 5,000. Now, multiply that by the number of companies that there are. Let’s see – so, in the US, there are a bit over 24 million companies. Projecting that out to 195 countries, many with fewer companies but some with more, let’s say that’s a nice, even billion companies. Assuming a 30% overlap in applications between companies, that’s about 2.8 trillion applications. Totally a guestimate, so let’s assume that I’m off by an order of magnitude, and it’s only 280 billion pieces of software.
Long tail indeed. I don’t actually know the number, so I’m totally making this all up, but logically, you can see the point – there’s a lot of stuff out there.
OK, so, we have a hard job. Of course, in my view, those are the only jobs worth doing, because they’re the ones that change the world. So, we’re forging ahead anyway. What have we been up to lately?
First, we’ve been increasing the overall number of apps which we have data for. After a big data-collection push, we increased the total number of apps for which we have data by 16%. Focusing in on Windows 7 (which is what most people care about – the Windows Vista data [shockingly] isn’t nearly as popular), the total number of apps for which we have data there is being boosted by around 25%. Not 25% of all apps, mind you, but 25% higher than the number we had before. So, that should give you a higher hit rate to start with.
Second, we wanted to increase the perceived hit rate. Because, most irritating to many is the fact that it looks as if we are missing stupid, obvious stuff. The glaring omissions that always lead people to paste a screenshot into their email to me. Stuff like Office 2010, Silverlight 4, and Adobe Flash Player 10. (“Why aren’t these apps in there??!!”) Now, those are still hard to get perfect, since some are updated rather a lot (and version number goes into the calculation of the ACT application ID, so a version rev means a new appID), and Office in particular maps up to dozens of AppIDs for a single app. Our goal is to make sure we hit at least one of those, not necessarily all of them. So, if you see only one or two of the entries which represents Office 2010 showing up, consider that success, hide the rest with a filter, and move along for now. We’d like to clean it up, of course, but we’re more focused on getting the rest of the completely unidentified ones handled first. (Office 2010 is compatible with Windows 7, by the way, I promise – you don’t even need to sync to find that out.)
We are committed to continuing to make this better. If you have feedback, or more obvious stuff you think should be there, you can provide this feedback to us – the alias is actfeedback@microsoft.com.
Thank you for your support of ACT, and we look forward to working to help you save even more time locating the vendor data which helps you accelerate a migration. Because, we agree – even though we didn’t make the software, and thus can’t say anything about whether it works or not, if we can save you a few web searches on the vendor website, we think we both win. The higher that number goes, the happier we both are.
Well, the temperature reads 55 degrees, so I figure I can’t possibly be in Hotlanta, but, shockingly, indeed I am! It’s awesome to be here at TechEd North America 2011 and not be sweating! (Anyone remember TechEd in New Orleans last year? What was it, 451 degrees F? I’m pretty sure my paper was spontaneously erupting into flames.)
If you are an app compat nerd, I’ve got plenty of nerdy app compat goodness to sate your appetite for, well, geekiness. Here’s what’s on the agenda (skipping for now the labs I led today, since I don’t have a time machine handy):
Troubleshooting Application Compatibility Issues with Windows 7 Wednesday 18-May, 10:15am B101 In this session, we will be going geek on Windows 7 app compat issues, answering some FAQs, giving you the nerdiest explanation of shims I can come up with, and going through a series of real world case studies of how we solve application compatibility issues with enterprise apps at real customers just like you. There will be case after case illustrating the troubleshooting process I use. And, oh yes, because it’s a 400-level session, there will be assembly language. Because, if you don’t see assembly language in a 400-level session, demand your money back.
IE9 in the Enterprise Thursday 19-May, 8:30am B309 This is my least-technical session (it’s 200-level – I don’t do many of those!) but it’s going to be awesome anyway. Here, we’re going to give you a respite from the Redmond Alternate Reality Vortex to talk to real customers and discuss their experiences deploying IE8 and IE9. Come and join in on our panel discussion, because interaction is encouraged. Fasten your seatbelts, because it’s The App Compat Guy Show. We make learning about IE fun!
Troubleshooting Application Compatibility Issues with Internet Explorer 9 Thursday 19-May, 1:00pm B103 Last, but not least, we’ll do a nerdy session on IE app compat, focusing less on canned demo apps and more on real world applications, where we will apply a tried-and-true troubleshooting process to understand why web sites have compatibility issues, and what you can do about it when they do. We’ll walk through a number of examples of troubleshooting real-world websites just like yours. Now, since it’s only a 300-level session, you know there won’t be any assembly language. But there will be good clean debugging fun anyway.
I hope to see some of you at my sessions! Feel free to come up and say hi and let me know if there is more we could be doing to accelerate your compatibility testing – I’m always listening.
Oh – and don’t forget to check out my buddy Aaron’s sessions if you’re here!
One of the things I notice quite a bit with the customers I work with is that they have this tendency to mitigate the risk of applications breaking by changing as little of the platform as they can.
One of the areas where this strategy is challenged is when security updates aren’t distinguishable from application updates. Such is the case, frequently, with Java. Like all other aspects of the platform, people love to hard code version checks into applications, and the fail if you don’t get precisely what you expected. So, you end up freezing in a version within a Java platform series.
This is problematic for several reasons.
The first is security. Here’s what the Microsoft Malware Protection Center has to say: Have you checked the Java?
The second is, surprisingly, compatibility: Error in Internet Explorer 9: "We were unable to return you to <your webpage>, Internet Explorer has stopped trying to restore this website. It appears that the website continues to have a problem"
As it turns out, some older versions of Java don’t run well with IE9. I won’t go into all of the gory details, but I’ll just sum it up by saying that it is (to me) a completely forgivable error: the developers chose to do something which probably would have been OK with straight C++, but which is against the rules with COM. Since COM is one of the most subtle and complex platforms ever created (as anecdotally indicated by the number of subtle bugs I come across) I’m willing to let that slide, they fixed it really quickly, but it does mean that you have to get a new one.
So, if you are planning an upgrade to IE9 (which I recommend), then you’ll also want to plan an upgrade to Java as well (which I already recommended, but now you have two reasons). You may surface a number of issues with hard coding, but for security reasons, it’s really important to remove those obstacles anyway.
I’ve never had a particular interest in being an actor, but if I ever did end up acting for whatever reason, I have a strategy which I’m pretty sure is going to work: I’m going to be Samuel L. Jackson instead of Chris Jackson. Now, I’m not going to do any mad scientist genetic experiments or anything, I’m just going to say I’m Samuel L. Jackson, and then start making movies.
It’s this very strategy which I see some enterprise customers doing.
Today (yes, it’s Saturday – surprise, I’m a geek on weekends too) I had an email dialog that went something like this:
Hey, app compat guy, I’m trying to write an MSI file to Program Files from a standard user account. Can I do that just by changing the ACL?
Well, from the perspective of the operating system, an MSI is just a file, so yes – if you give yourself permission to do a particular task, you are indeed able to begin doing that task. That’s what we call a tautology.
Ah, fantastic. Because they really think it’s inconvenient in general that standard users can’t write to program files, so changing the ACLs sounds like the ticket. Oh, also, how do standard users then go about running those MSIs?
Wait … what?
Yes, I should always think to ask the intent rather than answering the specific question, because the customer was on a trajectory to open up ACLs across Program Files and was then seeking to figure out how to run MSIs as well.
So, basically the customer wanted to have their users be Local Administrators, but they wanted to call them Standard Users.
Another example: I had a customer who was using the Power Users group. They wanted to get rid of Power Users, but because they didn’t want to address their application compatibility issues, they were going to have to give Standard Users all of the same permissions that Power Users once had.
Again – an example where you want to have users have elevated permissions, but pretend that it’s OK because it has a better name.
The fact that the highest privilege group you belong to happens to be called Users (and have the well-known SID S-1-5-32-545) does not matter at all if you give that group the same permissions that local administrators or power users used to have. Calling the group Users does not give you any of the security benefits of running with true standard user permissions. Calling the group Users does not give you the cost savings of running with true standard user permissions. In fact, it’s precisely the opposite. Because you are, in essence, lying about the true nature of your users, not only do you not get these benefits, you THINK that you do because of the name, and then you don’t fix it! And then people get all kinds of confused when they don’t realize any of the benefits of the security posture they think they have.
I advocate moving a significant percentage of users in the typical enterprise to true standard users. There are all kinds of tools which are new to Windows 7 since Windows XP, which means you don’t need all of the XP tricks of opening ACLs (which makes you not quite a true standard user) any longer. But I also appreciate that, because resolving those issues does take time and expertise, you may have to get there gradually rather than in one big bang. But my recommendation, if you can’t get there completely, is to just be honest about what your users truly are. If some still need administrator rights for a while, that’s OK – but then I would just call them that. Don’t call them standard users, but then give standard users all of the power normally reserved for administrators.
Just having the right name is not enough. For, even if I call myself Samuel L. Jackson, people won’t come to the theater to watch me. They won’t buy my DVDs. And I will never, ever sound cool when I say, “Enough is enough. I have had it with these motherf* snakes on this motherf* plane!”
Every now and then, I run into a customer situation where the ACT data collection agent causes an application on the desktop to stop working correctly. This happens because the compatibility evaluators in ACT use shims to collect this data, and some applications do not behave correctly when shimmed.
In the past, I have just recommended that the customer don’t use compatibility evaluators in that case, in order to avoid that challenge. They can still collect inventory (that doesn’t affect applications like compatibility evaluators would), and the data from compatibility evaluators, while potentially helpful, isn’t so valuable that it’s worth losing productivity.
But apparently, somewhere along the line, we added a feature which lets you exclude applications which don’t work with the compatibility evaluators:
Troubleshooting Application Failures When Running Data Collection Packages
I wasn’t even aware that we had added this feature! (I felt a little better when I later discovered that the Program Manager for ACT similarly wasn’t aware that we added this feature.)
For those of you who are attending MMS 2011 in Las Vegas next week, I have a couple of sessions I will be presenting there:
Internet Explorer 9 in the Enterprise Friday, March 25 10:00 am Lagoon L
In this session, we will be providing an overview of Internet Explorer 9 for the Enterprise. We’ll summarize the experiences of the TAP customers who have already deployed thousands of seats of IE9, and focus heavily on app compat (the #1 challenge in moving browser platforms). Is IE9 right for you? Come and find out! Will it be nerdy? Definitely.
Windows Deployment Live Game Show Friday, March 25 11:30 am Lagoon J
This is always a fun session! We take the top deployment and app compat experts in the world, put them in front of an audience, and then try to stump them with questions so hard that no sane person would ever get them right. Then, they see how many of them we get right. If you want to close out MMS by watching geeks squirm, then this is your session. I’ve won at the past 2 conferences (TechEd Europe and TechReady 12) – it’s about time someone stepped up and put me in my place…
Hope to see some of you there!
We recently announced that Internet Explorer 9 will be available starting Monday, March 14. Naturally, if you are a geek (which, statistically speaking, is true for a fairly large percentage of folks who happen to be reading my blog), you are asking yourself, “where are all of the nerdy details about changes which might affect my applications?”
Well, chances are that most of your applications will do OK if you leave them in one of the compatibility modes (Quirks, IE7, or IE8), which you can do easily enough using the X-UA-Compatible header/tag. In fact, the success rate we’ve had with that with pilot deployments in our enterprise TAP program has been phenomenally high. But what if you have an existing application where you are choosing to invest in an update, perhaps to leverage some of the great new capabilities in HTML5?
The place to start is the Internet Explorer 9 Compatibility Cookbook.
Getting customers off of Internet Explorer 6 (IE6) is certainly one of the priorities within Microsoft – how many other products have countdowns to its demise? But who would have thought that one of the biggest challenges for app compat that keeps people on IE6 is actually a bug fix and not new code or rules?
What’s the bug? In IE6, a DOCTYPE declaration is only ever read if it is the first line of code in the markup. Now, DOCTYPE is what switches you from quirks mode (the default) to standards mode, and the standards say that it does not have to be first. We can’t very well have the standards mode switch not itself be standards compliant, so we kind of had to fix that. But here’s what happens. Let’s say you have markup that starts like this:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head>…
Looks perfectly good, right? In fact, I copied and pasted it from here. But, on IE6, what happens is that we ignore the DOCTYPE and we render it in Quirks mode. Quirks mode has a completely different box model, and renders entirely different from standards mode, even IE6 standards mode.
What I usually find with pages that start like this is that IE8 standards, or even IE7 standards isn’t what breaks them – the pages don’t even lay out correctly using IE6 standards. No, the problem is that the web pages are Quirks dependent, not IE6 dependent – and we still have a Quirks mode!
Of course, there’s no super easy way to jump back to Quirks mode, but you do at least have a few options.
First, if you are modifying the source code, you can just remove that DOCTYPE and get quirks in every version of IE, because you are no longer dependent on the IE6 DOCTYPE bug to land in Quirks mode. If I do that, I also like to tag that website with X-UA-Compatible IE=5 to leave metadata indicating that this outcome was intentional.
If you can’t touch the source code, then you can instead just modify the web server to output the X-UA-Compatible header specifying IE=5.
If you are in the unfortunate position of not being able to touch the server or the page, then there is a hotfix available to allow you to configure web sites to run in Quirks mode via group policy, available here:
A webpage is not displayed correctly when you browse the webpage by using Internet Explorer 8 Standards mode or Compatibility View in Internet Explorer 7
Whatever path you choose, there is often a quick way to get some of your applications working more quickly and less expensively. Not that I recommend Quirks mode as something desirable, but updating to support the latest standards takes time and money – ideally you can choose to support the latest standards for applications you introduce, without being forced to reinvest in your entire existing application estate, where the business return for this investment may never materialize.
One of the most common questions I get while working with enterprise customers is: should I leave Compatibility View turned on for the Local Intranet zone?
We have an awful lot of guidance that seems to be pushing for standards, standards, standards everywhere, and this has a tendency to get customers a little scared – will this compatibility mode go away at some point, and am I just delaying the inevitable? I don’t want to finish a migration, and then have to go back and do it all again.
There are two forces at work, and my recommendation is ensuring you consider both when developing your strategy.
First, there is business value in adopting standards. Think about it – how many college hires do you know coming out with deep IE6 experience? If you are developing externally facing websites, you can’t afford to ignore modern, standards-based browsers – so my internal web developers must have a different skillset from my external web developers. There are benefits to leaving the past behind, including more efficient markup, less code branching, etc.
At the same time, do you really want to go back and revisit every single one of your web applications each time that you move your browser? Compatibility with your existing web properties is, after all, one of the core value propositions of Internet Explorer. Having to uplift your entire application estate each and every time standard change is an expensive and time consuming proposition, and while adopting the latest standards in general is a good principle to follow, adopting it for each and every application may not have a business case to justify that investment. You shouldn’t have to touch every single app every time you want a new browser, even if the standards changed.
So, my recommendation when moving forward to a new browser is the following:
Start with your policies configured to make the majority of your applications work without touching them
The default configuration for both IE8 and IE9 is to place the Local Intranet zone into IE7 compatibility, and this typically makes sense. More of your apps work out of the box this way, which means you can choose to invest in standards for the applications where there is business value in doing so, and not have to do so for all of them because you have no other option.
Tag your sites each time you touch them
Defining your heuristics to place more web sites into a more compatible mode is certainly a good starting point, but why should we have to guess at all? You’ll want to eliminate the guesswork, particularly as the compatibility infrastructure grows to support compatibility with more previous browsers. If you tell IE which rendering mode works best for you, then we can take on some of the burden of keeping that compatible.
Tag each of your websites, if you are touching them anyway, with the X-UA-Compatible header.
This metadata provides evidence for future versions of the browser as to what they could do in order to keep your application working better.
It is also important to know about this because, if you default to IE7 compatibility mode for all of your internal web sites, this is the one and only way to opt a site into more current implementations of standards! If you want to play with the significantly more HTML 4.01 compliance in the IE8 rendering mode, then you need to tag your internal site. If you want to leverage the full power of HTML 5 in IE9, then you’ll need to tag your internal site.
Providing metadata that gives evidence around your design – breadcrumbs, if you will – is always a good idea.
Implement standards for new apps and significant enhancements
Having compatibility with IE7 as the default is great for most existing application portfolios, but you don’t want to keep building dependencies on dated standards and implementations thereof, do you? I recommend putting a quality bar in place for new apps, or significant updates to existing apps, to require that they adopt at least IE8-level support of established standards, and possibly IE9-level support of emerging standards, so that your application estate moves forward – gradually, organically, and manageably.
The periodic drop of a new browser could result in an expensive manifestation of punctuated equilibrium, but by leveraging the compatibility infrastructure of Internet Explorer 8 and Internet Explorer 9, the enterprise can tame these periodic bursts of investment and better approach the phyletic gradualism that provides more predictable IT management costs. It is important to keep moving forward, embrace standards, and welcome interoperability – at a pace your business can afford.
From time to time, I get an email about Standard User Analyzer that includes a screenshot or a MessageBox text copy (you do know you can control-c a MessageBox and paste just the text, right?) that looks something like this:
Failed to load log file c:\Users\<user name>\AppData\Local\Temp\1\sua: No (valid) log file is found.
It typically is reported by people running Windows Server 2008 or Windows Server 2008 R2. What’s going on?
It turns out that it’s caused by a group policy setting enabled for Terminal Services: Do not use temporary folders per session.
Now, “session” is an unfortunately overloaded term in Windows. There is an LSA Logon Session, and there is a Remote Desktop Session (formerly known as Terminal Services Session). When you log on as a protected administrator (a member of the local administrators group with UAC enabled), you generate two LSA Logon Sessions – one for your filtered token, and one for your full token. However, you live in one Remote Desktop Session. So, it’s legitimately a bug that we’re popping over to a different temp directory for one of your tokens.
However, it’s a bug we’re not going to close at the moment, for application compatibility reasons. This bug has existed since Windows Vista, and those who have come across it have implemented workarounds – workarounds it turns out we break if we fix the bug.
App compat is one of those weird realms for engineers. If we fix bugs, we break apps, and people are unhappy. If we don’t fix bugs, then we still have bugs, and people are unhappy. That’s why we come up with features like SwitchBack and Shims – so new apps can get bug fixes, but old apps continue to get bugs. But it’s hard to always do that perfectly, particularly mid-stream.
So, what do you do to get SUA running? It turns out that you have a couple of workarounds:
Hopefully that gets some of you back up and removing admin dependencies.
Preemptive snarky comment: You can also just use LUA Buglight as a workaround. :-)
If you want to master app compat debugging, then I really only know of one approach: practice. Find things that are broken, and then find out why. If you have to look too far for something broken, then you must be significantly luckier than I am!
Now, I prefer to listen to Mötley Crüe when I debug (or drive somewhere, or sit somewhere, or walk somewhere, or…), so it seemed only fitting that I would debug something for a member of Crüe while listening to Crüe.
Now, a while back, Nikki Sixx updated his http://www.nikkisixx.net/ website. And, of course, the first thing I noticed is that it doesn’t render correctly on IE9 when in IE9 Standards mode. It renders fine, however, in IE8 or IE7 standards mode, and it also renders fine in Firefox, Chrome, Opera, and Safari. So, I figured it must be something with the new rendering engine, and went about with the assumption that our code was broken.
I first took a look with the developer tools, and spotted straight away the following error message in the Console tab:
SEC7113: CSS was ignored due to mime type mismatch
Interesting – so, perhaps it’s not a bug in IE9? I’m still a bit leery, because the fact that it works with every other engine seems to indicate something wrong with the one failing engine. So, I had a look with the new Network tab to see what I could find out about the MIME type. Here is what I found:
Content-Type text/css, charset: UTF-8
OK, so it is a CSS file, and it’s specifying a content type. So, I’m now perplexed as to what I am seeing. Of course, I’m not as conversant with the new developer tools, so I took a look with my old friend Fiddler just to make sure the headers are completely raw, and found this:
HTTP/1.1 200 OK Server: Apache/2.2.11 (Fedora) X-Powered-By: PHP/5.3.2 Last-Modified: Tue, 07 Dec 2010 19:19:31 GMT ETag: 7d2160439e3d0b054b09b638c9516e70-gzip Pragma: Content-Length: 92090 Content-Type: text/css, charset: UTF-8 Cache-Control: max-age=600 Date: Tue, 28 Dec 2010 18:04:33 GMT Connection: keep-alive Vary: Accept-Encoding
Now, this all looks fine to my uneducated eye – it looks as if we are specifying a content-type, and it appears to me that it is the correct one. But that’s the key – I’m not completely conversant in the specifications! So, let’s learn the specifications…
If you take a look here, you can see precisely what you should have for the content type, and it’s in the format:
Content-Type := type "/" subtype *[";" parameter]
Wait a minute … the specification has a semicolon and the content had a comma – it looks like this web page is actually at fault, and every other rendering engine (including ours) was just being forgiving! Wow, IE9 appears to not be shouldering the blame here! (Though admittedly we are being a little picky, given that in the past we were letting that slide.)
Of course, just to make sure, let’s test things out. First I found the request and response in Fiddler. Then, on www.nikkisixx.net/20621/global.css, I chose to right-click, Save, Response, Entire response… and placed a copy of the response on my desktop. Then, I went in to the file, and replaced that comma with a semicolon. Finally, using the auto-responder from Fiddler, I fed this modified response to test out the fix.
Voila – when the header is modified to comply with specifications, it works! IE9 is vindicated, and I have a fix for the web page which involves a single character to make it compliant with standards. Now that the heavy lifting of debugging is finished, the only remaining challenge is to find the person who owns this page and point them to the fix, and then we can go on with the show.
Updated 29-December-2010
Daniel15 (http://dan.cx) points out correctly that I didn’t go quite far enough down that spec. While the semicolon instead of a comma is all it takes to get it working, it isn’t far enough to get it up to spec. Specifically, it shouldn’t be using a colon after charset. The spec indicates:
parameter := attribute "=" value
That should be an equal sign instead. So, to be more correct the header value should be:
Content-Type: text/css; charset=UTF-8
Thanks, Daniel! And, as John points out, this is a header, so the fix would be something configured on the server and not something the designer would have submitted.