I was reading through some documentation on Sysinternals Process Explorer the other day, and one bit that caught my attention was some detail on the .NET tab. So, I pulled up my trusty managed StockViewer application, and went to go and look at that tab.
Only…
…it wasn’t there.
Fascinating.
So I found another managed code process on my system, and tried to look at it’s tab – the excellent Switcher application.
No joy.
OK, so after telling Mark he didn’t know how to write programs (don’t try this at home) it was time to pull out the debugger. With a little help, because I did ask Mark how he was checking to see whether he should be putting the .NET tab on there. He said he was using both perfmon APIs and the ICorPublish APIs.
So, off to the MSDN documentation to start brewing up a hypothesis, and to be honest it just seemed most likely that the ICorPublish APIs would be the culprit, since they were called per process and perfmon itself was working so those APIs were probably going to be working too. Just a hunch.
I browsed through the APIs, and fortunately there were only two. Of those two, one seemed the most likely to be called for this, so I set a breakpoint on it.
bp mscordbi!CorpubPublish::GetProcess.
Sure enough, it was hit. Good guess.
Of course, this bp was hit rather a lot (I had quite a few processes running at the time), so I didn’t want to have to stop and inspect every call. I wanted to stop and inspect the call when it was looking specifically at the process I expected was managed (Stock Viewer) but procexp didn’t think was managed. So, off to Task Manager (sorry, procexp, but you were frozen at a breakpoint in my debugger) to pull the PID for Stock Viewer, which I then translated to hex for the debugger. Voila – breakpoint set.
1:001> bl
1 e 00000642`ff91302c 0001 (0001) 1:**** mscordbi!CorpubPublish::GetProcess "j @rdx=0x16EC '' ; 'gc' "
I hit this breakpoint, and then stepped out of the function. I then inspected rax to see the return code, and found it was 0x80070057. the 8 already indicates bad news, so I was expecting an error message. It was COR_E_ARGUMENT. Now, that wasn’t particularly helpful this time, since there was only one argument (the pid), so the question is – why didn’t it like to answer this question about this process? It would take some additional stepping through.
So, I did some call tracing, and found that GetProcess was calling through some internal APIs, and one of the interfaces was returning 0x80131c30. It appeared to be another COM call, so it could be a failure hresult, but the utility I use to look up error messages wasn’t telling me anything. The error number was not found.
Along the way, Mark had reached out to another Technical Fellow, so at this point I’m thinking to myself, “holy crap, there had better actually be a bug here and not user error” – and this other Technical Fellow pointed me in the direction of Thomas, a Senior Development Lead for the CLR. And what a useful connection this was. He deciphered the error: it’s returned if there is a bitness difference between the caller and the target.
Aha.
Both of the managed apps happened to be specifically flagged as x86 apps. So, to do a quick check that this was the only thing wrong, I only needed to create an AnyCPU managed application, and see if ProcExp would display a .NET tab for it. Indeed it does!
So, mystery solved. ProcExp can’t (today) peer into .NET information for managed processes that are 32-bit on 64-bit Windows (the default compiler setting is to create AnyCPU binaries). The wheels are already churning to figure out how to close up this edge case. I just got unlucky with the two managed apps I happened to be running.
There are a number of efforts going on to help organize application compatibility for Windows 7, in or ongoing effort to improve in this space. Now, the technical information remains fairly stable, but there are a number of different ways to organize that information based on the perspective with which you are approaching that problem.
In fact, that’s probably the hardest part of talking about application compatibility – it crosses pretty much every discipline in IT, from management down the individual contributor. Even within individual contributors, it’s divided between the IT Professional and the Developer audiences.
(As a side note, in nearly every audience I speak to where there are representatives of both disciplines, they tend to completely sort based on discipline. All of the IT Pros will sit on one side of the room, all of the developers sit on the other. You almost never find a situation where people are naturally distributed. And we wonder why communication between these teams, while critical, doesn’t happen as often as we would like – I know I am guilt of that myself!)
So, we’re trying to organize and sort the information and knowledge for you as best we can. Here are just a few ways we have organized things to help out:
Windows XP to Windows 7 Migration Guidance
http://technet.microsoft.com/en-us/windows/ee150430.aspx – this is one way to map out information by the process itself. It’s fairly high level (no kernel debugging tips here) and more geared towards the IT Professional (hence the Technet home). Instead of a big list, there is a flowchart navigation system. Click on the stage in the flowchart you are sitting at, and it lists out resources, with pros and cons, of the tools which are there to help you through that state! Quite a clever navigation scheme.
Application Compatibility Factory
OK, this is one that’s confusing. I know I pick on folks in the marketing discipline from time to time, but that’s only because I think they can act in ways that are as unengineer-like as possible. Sometimes that’s good, sometimes that’s … confusing. This is one of those confusing times.
We took an existing program and brand – Application Compatibility Factory. The name made sense – it used a (predominantly offshore) factory model, optimized for churning through bulk. The program for Windows Vista consisted of around 6 global system integrators.
We then re-used the power of that brand on a whole new model. No, really! It doesn’t look anything like the old model – heck, it isn’t even a factory model, despite having the word Factory occupy 1/3 of the words in the name. No longer is ACF the “stroke a 7 figure check and make a big chunk of work disappear” – it’s now a program that delivers 1-week Proof of Concept engagements.
Here’s basically what happens: a partner (or even Microsoft Consulting Services) comes in to your organization and begins the process of taking a software inventory. (Depending on how many desktops you have, they may not be able to finish, but they’ll be sure to let you know how you can finish up.) Next, they get you started on the process of rationalizing that inventory, so you can focus only on those applications that you specifically want to support on your shiny new operating system, and not everything someone managed to successfully install at some point in time after you handed them a computer. Finally, they do a bit of proof of concept work around remediating applications – likely not making much of a dent in that work, but at least showing you the general approach to that problem and giving you both knowledge and hope.
In the end, the same partner will also be very likely to slide a proposal across the table to help you finish that work, and it’s here that they’re likely to include the factory model. But factories have almost nothing to do with the actual free engagement.
Oh yeah, did I mention the free part? So, if you’re still getting started, this is a great way to leverage the investments we’re making in application compatibility and minimize your risk.
To get started, in the USA you can send email to usappcom@microsoft.com. You can also find information here: http://technet.microsoft.com/en-us/windows/bb510132.aspx. This has a list of the ACF partners in many different countries. Yes, even you, Belgium.
This is all great, but I write code
We’ve got you covered. We recently added an FAQ section to our forums at http://social.msdn.microsoft.com/Forums/en-US/windowscompatibility/threads – you can find it at http://social.msdn.microsoft.com/Forums/en-US/windowscompatibility/thread/7d585c05-0b61-45e7-b554-740382ffb7cc. This forum is a great place to get your specific questions answered.
This is just a taste of some of the organizational work we’re investing in. Keep on letting us know how we can do better! Because it’s bad enough that this stuff is hard technically, it shouldn’t be hard to find what you need!
A little while back, those of us who explain application compatibility for a living and try to help people get their arms around it ran up against those who implement it in the product on the scale of … the whole earth.
Those of us who explain things for a living really prefer (really, really prefer) when the system is internally consistent, because that makes it easier to explain.
Those who build systems really work to make the investments they can, with finite resources, to fix the greatest percentage of applications they can.
And sometimes those goals are not in alignment.
Case in point: remember back in April when i was talking about how we added the new AdditiveRunAsHighest shim to our operating system layers? Well, it turns out that we didn’t touch quite all of them. The following layers have AdditiveRunAsHighest applied:
The following layers do not have it applied:
What’s the rhyme or reason here? Well, you can start to tease out some logical ones. First, most people don’t use compatibility modes on server apps. (They may use them on a server, such as when you use terminal services apps, but if you have a high-throughput server application, shimming it up and running it unsupported is probably not high on your list of acceptable mitigations. So, remove Server 2003 and Server 2008. Next, if it worked on Windows Vista, it has already seen UAC, so we don’t really need to have it there. But … what about NT4 and Windows 2000? If those were included, couldn’t we just say, “ever client operating system prior to Windows Vista includes this shim”?
Yes, we could.
And wouldn’t the same arguments that made sense for the other ones make sense here?
Yes, they would.
So, what gives?
Well, in the game of probability (fix the most apps), internal consistency was not the focus. Fixing the largest number of apps was. And there simply were not enough apps that needed the Windows NT 4 and Windows 2000 modes to bring it on the radar that they needed them too. And those of us who do explain these things for a living didn’t notice it until July, when the bug bar was way too high to get this fix in (since it doesn’t actually block you from getting things done, it just makes it harder to explain why the system behaves the way it does).
So, instead of a nice, logical rule, you have a list to memorize. 95, 98, and XP get AdditiveRunAsHighest. Everything else does not. Sorry for making you memorize a list – I’d much rather you were memorizing rules that you could logically explain, but so it goes.
My job takes me around the world talking to both Developers and IT Professionals in order to resolve compatibility bugs with Windows 7 and Windows Vista. But you know what, I’m just one guy – so chances are I’m probably not going to have a chance to look at every piece of software that has ever been written for Windows (because after doing this for several years, I’m beginning to believe that every piece of software that has ever been written for Windows is still being used somewhere – yes, even including that Hello World program you wrote in college, they’re using that at Fabrikam Corp. for some reason).
We have long been experimenting with ways to scale out our ability to reach people and help them out getting software working on the current version of Windows, and (like application compatibility itself) there is no one silver bullet.
But here is one really good idea someone had: let’s take a bunch of the smartest people in the world (Escalation Engineers and Premiere Field Engineers), create a forum, and then bribe people to participate with … get this … a Microsoft branded shirt. That’s right – it turns out that even people who already have 5,000 Microsoft branded shirts in their closets will work for free if you increase their collection to 5,001. There’s something about SWAG that makes geeks’ hearts melt.
So, we created forums for developers:
http://social.msdn.microsoft.com/Forums/en-US/windowscompatibility/
and for IT Professionals:
http://social.technet.microsoft.com/Forums/en-US/w7itproappcompat/threads
(and for partner ISVs:
https://partner.microsoft.com/US/40014662)
If you post your application compatibility questions there, some crazy smart guy or gal will take a look at your question and help you out. Now, it’s not paid support with an SLA (though we’ll help you out with app compat questions there too – feel free to leverage that), but it’s the same people with the same huge brains. (OK, so I’m jealous of the size of their brains. What can I say.) And it’s free. As in beer.
Oh yeah, and eventually they did start giving utilization credit for that too. In addition to the free shirt. I thought it was way cooler when it was just a shirt, but maybe that’s just me. I know I got my shirt already.
Well, now that we have shipped Windows 7, and General Availability (GA) is right around the corner, I wanted to spend a brief bit of time taking a look at how our landscape will be changing for the RTM release.
First, the big question that everyone is asking is, “when are you releasing ACT 6.0?” That’s probably because of the branding inside of ACT 5.5 (http://www.microsoft.com/downloads/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E-492DD6DA2971&displaylang=en), since it explicitly says Windows 7 RC in the reports. ACT 5.5 is ready to go for your Windows 7 migrations (in fact, that’s what it was designed for). For those of you who are bothered by the “RC” moniker, well, that’s an easy one. It’s a server-side change, and we’ll be removing RC from the name around GA. So, hopefully that will defuse that one.
Are we working on an ACT 6.0? Yes, sometime in early 2010. But you don’t need to wait for it – it’ll just be adding some new features. I haven’t seen anything so far that I’d consider a “must have” for starting my deployment, though I am excited that some of the bugs I opened that annoy me the most already have fixes checked in! :-)
What about the Windows Vista Compatibility Center (http://www.microsoft.com/windows/compatibility/) – is there going to be a Windows 7 Compatibility Center? Again, I’d be looking for this around GA. Since the day we RTM’d, we’ve had teams working furiously to get as many support statements for Windows 7 as possible (which is what this list is based off of). So that is well underway.
In case you weren’t aware, we are releasing this information as a downloadable list around once a month (the latest version was from July 9) so you don’t have to look up applications one by one if you have a big pile of them. You can find that here: http://www.microsoft.com/downloads/details.aspx?FamilyID=9df23606-7276-4ce2-8993-143e101ddbcd&displaylang=en
We’ve had teams around the world reaching out to every ISV we can in order to get applications compatible with Windows 7 in time for RTM, and this work continues. But, side by side, we’ve also been trying to track which applications are supported on Windows 7 (because the fact that it does work isn’t as helpful if you don’t know that information), and you should start seeing that in October. It’s been a long hard run (and many of us have collected more than our fair share of frequent flier miles along the way) but it’s finally all coming together.