Chris Jackson's Semantic Consonance : Windows Vista

Using the uiAccess attribute of requestedExecutionLevel to Improve Applications Providing Remote Control of the Desktop

Chris Jackson — Fri, 16 Oct 2009 01:47:04 GMT

I’ve run into this exact same problem 3 times now in one week, so I figure that probably doesn’t bode well and I should attempt to do something about it.

With 3 different pieces of software (one of them ours), the remote control functionality is imperfectly implemented. Let’s see if this sounds familiar to anyone. You are the helpdesk. You attempt to connect to a user’s desktop. You have to elevate an application. When you do, you (the helpdesk who actually has the password) doesn’t see the UAC dialog – instead, the end user (who does not have the password) does. Even if you decide to give the user the password (it happens), you then can’t control or even see the elevated application.

Kind of makes it hard to be a helpdesk when that happens.

Here are the 3 solutions that I have seen to this problem:

Do nothing. That’s what our solution did. It just failed every time elevation was involved.
Install a service. That’s what company X did. It requires the user to know an admin password, and that’s a problem for my customers
Run the application elevated. That’s what company Y did. It requires the user to know an admin password (a problem with my customers), and also won’t allow you to interact with any windows running at System integrity level (so an incomplete solution)

Here’s what I wish all 3 had done:

Manifest with uiAccess = true

Now, most people don’t really understand what this is for, and the UAC manifest is typically just a copy/paste affair. But it pays for the remote desktop developer to pay attention to it. For any regular piece of software, you generally want to stay away from it – it’s dangerous, and sidesteps a significant security feature (UIPI). But if you are remoting the desktop, it’s precisely what you want – you need to be able to see everything!

It’s dangerous enough, in fact, that we won’t allow you to set it without digitally signing your application. By default, you also have to have it installed in a secure location (such as Program Files). You can set a group policy to not require a secure location, but there is no option to not require a signature.

However, once set up, it’s really powerful. You’ll be able to remote every possible kind of window – any integrity level at all. No more blank, unresponsive screens. Everything comes across, regardless of integrity level.

You’ll also be able to leverage the group policy that lets you prompt NOT on the secure desktop if you are a UIAccess application – that way you don’t have to lose the defense in depth of using the secure desktop for normal elevation, but you also avoid writing code to remote the secure desktop when your remote desktop application is running.

All in all, you are just full of win.

Now, it’s my job to fix up apps that are written suboptimally, so you may be wondering how I did getting these working?

Our application, rather conveniently, used an external manifest. All I had to do was open up the manifest in Notepad, and type four characters (t-r-u-e) in the uiAccess attribute. Done. Now it works great. (Of course, everyone who downloads it will download a new broken one, so they’ll have to text edit it too – clearly we want to work with the team that makes this to fix it on their end, but you aren’t stuck – you can fix it without depending on anyone else.)
Company x, the one that used a service (claiming of course that it was UACs fault that they had to do this)? I can’t fix it. They used an internal manifest, which has precedence over any external one I might lay down there. I could extract that manifest with mt.exe, edit it, and then re-inject it, but then I invalidate the digital signature. Remember that this is a non-optional requirement for a uiAccess app! So, there is nothing I can do. I’m trying to contact the vendor.
Company y, the one that elevates to admin – this one I didn’t have time to examine – they do a “just in time” install and uninstall, so I couldn’t explore the manifest, but since it’s so transitive it’d be hard for me to do much anyway that would last.

Anyone writing desktop remoting applications, please consider using this. And feel free to contact me if you have questions. I would be delighted to help you.

For the record, here is the corrected manifest for the one I was able to fix:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1'
manifestVersion='1.0'>
<assemblyIdentity
   version="1.0.0.0"
   processorArchitecture="X86"
   name="Microsoft.FixedUpApp.SupportConsole"
   type="win32"
/>
<description>Fixed Up App</description>
    <dependency>
      <dependentAssembly>
        <assemblyIdentity type='win32'
         name='Microsoft.Windows.Common-Controls'
         version='6.0.0.0'
         processorArchitecture='x86'
         publicKeyToken='6595b64144ccf1df'
         language='*'
        />
      </dependentAssembly>
    </dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker"
         uiAccess="true"/>
      </requestedPrivileges>
    </security>
</trustInfo>
</assembly>

Stock Viewer Shim Demo Application - Now Available in Japanese!

Chris Jackson — Wed, 24 Jun 2009 06:14:00 GMT

I have had the Stock Viewer Shim Demo application available for over a year now, and I'm delighted at how much impact it has had. I see people using this all the time! But previously it was available only in English. Well, no more - it has now been (mostly) localized to Japanese! Enjoy.

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

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

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

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

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

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

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

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

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

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

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

RunAs Radio: Chris Jackson Makes our Applications Compatible

Chris Jackson — Thu, 22 Jan 2009 06:28:49 GMT

I met the guys from RunAs Radio back in Barcelona, and a couple weeks ago I had a chance to sit down and chat with them. Check it out.

Helpdesk Elevation on Windows Vista and Windows 7

Chris Jackson — Thu, 08 Jan 2009 21:42:50 GMT

Since I was talking about configuring UAC on Windows Vista and Windows 7 a bit yesterday, I thought it made sense to bring up another policy whose actual use may not be obvious based on the name.

User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop

We talked about the secure desktop – but what is this UIAccess all about? Well, you can get details here:

http://msdn.microsoft.com/en-us/library/ms742884.aspx

But rather than going deep, let’s look at the manifest for msra.exe (Microsoft Remote Assistance):

sigcheck -m c:\windows\System32\msra.exe

sigcheck v1.54 - sigcheck
Copyright (C) 2004-2008 Mark Russinovich
Sysinternals - www.sysinternals.com

"c:\windows\system32\msra.exe":
        Verified:       Unsigned
        File date:      11:47 PM 12/12/2008
        Publisher:      Microsoft Corporation
        Description:    Windows Remote Assistance
        Product:        Microsoft« Windows« Operating System
        Version:        6.1.7000.0
        File version:   6.1.7000.0 (winmain_win7beta.081212-1400)
        Manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-micr
osoft-com:asm.v3" manifestVersion="1.0">
    <assemblyIdentity
        version="5.1.0.0"
        processorArchitecture="amd64"
        name="Microsoft.Windows.RemoteAssistance"
        type="win32"
    />

<description>Remote Assistance</description>

I think of this policy as the “give helpdesk the ability to elevate” policy.

(Obviously this only works if you don’t configure the policy to auto-deny elevation requests by standard users.)

The Windows 7 UAC Slider, and What You Can Do on Windows Vista Today

Chris Jackson — Wed, 07 Jan 2009 22:51:04 GMT

As I am focusing more and more on Windows 7, I find that blogging now begins with web searching, to make sure that what I’m talking about is already publicly disclosed and, as such, I’m not putting my job at risk. :-)

I want to go into a bit of detail on UAC configuration, what’s changing in Windows 7, and what’s available today. Because, in my experience, there are a lot of people who don’t fully understand how to configure UAC as it exists in Windows Vista – probably because we haven’t spent enough time talking about it.

PC Magazine (oh, how I’m going to miss the dead tree edition of that magazine) was kind enough to already show you what I want to talk about in it’s article here: http://www.pcmag.com/article2/0,2817,2335122,00.asp. So, let’s have a second look at the new UI for UAC in Windows 7, as it exists today (this is not a commitment that it will never change, that it’s a good idea, or that you won’t experience premature hair loss from viewing the picture – all the regular disclaimers for pre-release software apply):

Now, my friend Crispin would prefer a different UI metaphor than a slider – he’d like to see a pair of pants – the further down you pull the slider, the further down your pants are while you’re computing. I actually think that’s a really good analogy. Let’s look at each of these settings, talk about what you can (and can’t) do on Windows Vista today, and then add some commentary on the consequences of making that choice.

Always Notify Me

This is UAC configured the way you get it on Windows Vista today. This one should be very familiar.

Notify me only when programs try to make changes to my computer

This one is genuinely new for Windows 7, and essentially will auto-approve elevation when performing some actions to modify system state. I won’t get into the mechanics of exactly what we’re doing, because it’s neither final nor am I currently authoritative on all of the details behind the logic here. My goal here is to explain what you could do today, anyway.

Notify me only when programs try to make changes to my computer (do not dim my desktop)

Well, half of this (as discussed above) is new stuff, but the other half (the half in parentheses) is available for you on Windows Vista: not dimming the desktop. That’s something you can configure today. In group policy, under Windows Settings \ Security Settings \ Local Policies \ Security Options, you’ll find an entry called User Account Control: Switch to the secure desktop when prompting for elevation. Change that policy to disabled, and you have that half of the configuration.

Why do we default to switching to the secure desktop? Defense in depth. Message queues don’t have security descriptors. Of course, User Interface Privilege Isolation should help keep less trusted messages from getting to the approval dialog (consent.exe runs with System IL), but it’s even better to get to a separate desktop since the boundary of a window message is the desktop.

You see, today Windows doesn’t have what some call “Authentic User Gestures” – the ability to differentiate between a real user clicking a mouse button which gets translated into a window message to click the button, and an application sending a window message to pretend that somebody clicked it. To the receiving application, they both look exactly the same. So we build up mechanisms like this. While elevation is not technically a security boundary, it should at least do a reasonably good job of looking after you.

When do I see people configuring this policy? Well, there were some drivers early on that had a really hard time with the transition to the secure desktop (I haven’t seen this in a while). And otherwise, I see people configure this temporarily to make it easier to grab a screenshot of the dialog box. (Of course, if you want to make it look more realistic, you should change the theme to the basic theme first, since the secure desktop doesn’t have glass.

Never notify me

This is the off switch that you have in Windows Vista. This is bad for all the same reasons that it’s bad in Windows Vista.

So, what’s really new is the “windows settings” categorization. But wait, there’s more! This slider still doesn’t expose two settings which are very interesting to know about!

In the “Behavior of the elevation prompt for …” settings you have:

(For local administrators) Elevate without prompting

This is the setting for people who never, ever want to see a prompt, but don’t want to lose out on the value of UAC. You keep things like Internet Explorer in Protected Mode, AXIS for your standard users, UAC file and registry virtualization, and all kinds of other useful stuff – and, oh yeah, the fact that the overwhelming majority of software testing is done in the default configuration (enabled). If you’re hell-bent on disabling UAC, could I talk you into giving this setting a try?

(For standard users) Automatically deny elevation requests

This is the setting for people who disable UAC for their standard users because they don’t want them seeing a credential prompt, since their users won’t have credentials and, in the enterprise, that just means it’s going to cost more to run the helpdesk. You don’t have to disable UAC and lose all of its benefits, you just need to tweak this policy.

Personally, I’d like to see an additional notch in the slider that uses these settings – leaving UAC on but getting rid of all notifications. Perhaps even hiding to “off” switch a bit, because in my travels, this is the setting that gives the best overall experience for people who hate prompts passionately. But alas, it’s not my decision to make.

By the way, here is the e7 post on UAC: http://blogs.msdn.com/e7/archive/2008/10/08/user-account-control.aspx

What does the MoveIniToRegistry Shim Do?

Chris Jackson — Fri, 05 Dec 2008 23:11:30 GMT

I’m still catching up with requests to talk about stuff – here’s one that came in back in June (and just came again today from somebody else):

“MoveIniToRegistry clearly requires parameters, but there's no documentation defining what these are. (Presumably this fix will apply an IniFileMapping?)”

I haven’t doc’d this shim yet, so here’s the quick and dirty docs on it.

First of all, it doesn’t apply an IniFileMapping. That’d be kind of cool, but that’s something you’d want to do to an installer ideally, since you only need to do it once.

Instead, it intercepts calls to CreateFileA, OpenFile, WriteFile, and CloseHandle. You feed the shim with the name of the files you’re going for, and it ensures that writes happen to both the original file AND to the registry location.

That’s pretty important. The return value from the API is *not* changed by applying this shim. Rather, you still write to the original location, but you also write to a registry location.

For an example, let’s look at Barbie Sticker Designer. Now, this is a program I consider business critical, and I spend the majority of my working days using it. I find it to be a lot less stressful to use than Outlook. How is this shim configured? If we look at it using Compatibility Administrator, you can see the command line used:

%windir%\System.ini * SCRNSAVE.EXE HKEY_CURRENT_USER “Control Panel\Desktop” SCRNSAVE.EXE REG_SZ

The generic argument list is:

IniFile [IniSection] IniKeyName RegBaseKey RegKeyPath RegValue RegValueType

Hopefully that makes the purpose of this shim more clear. It’s still going to write to system.ini (and that writing will drive the return value of the API you are calling), but it’s also going to write the screensaver information to the registry, which is where the system actually looks these days. So, it’s not fixing a permissions issue, it’s fixing an implementation detail (we moved where screensaver configuration is). If we’ve moved something else from an INI to a registry key and don’t already have a fix for it, then you could use this to fix it up as well.

If you were hoping for an easy way to apply an IniFileMapping, well, sorry about that. That’s the problem with these shims – they sometimes have these incredibly tempting sounding names, yet in the end what they actually solve isn’t always what you expected them to solve. I’m trying to get things documented in the order of what’s most useful to you, but keep calling things out to me because I may not always know, and we’ll find out!

How to Set Directory Permissions at Install Time using an MSI Created Using Windows Installer XML (WIX)

Chris Jackson — Thu, 04 Dec 2008 23:03:11 GMT

Here is a topic I have been saying “I’ll get to it” for a while now…

We’ve talked a lot about UAC here, and I have really stressed the point that standard users shouldn’t be able to affect other users or the machine itself, and if you want to violate that rule then you need to do so explicitly.

The one area that I’ve received some questions on is what to do about shared user data. You should be using c:\programdata (not hard coded, of course!) to put your shared user data into, and then explicitly setting the ACL. You’ll need elevated permissions to set that ACL, so you should be doing so at install time.

Now, here’s the part that makes people nuts (and rightly so!) – we then never bother to tell you how you can set that at install time! At best, we’ll give you some hints. Want to know something interesting? You’d probably be surprised at how many people don’t know how to do this themselves, but nonetheless will happily tell you that it’s what you ought to be doing.

I think that’s kind of rude, so I figured I’d actually spend some time poking around so that when I tell you to do it, I could then answer the follow-up question of, “OK then, how?”.

Of course, installers could be anything, and I don’t know all of the tools (not by a long shot). I’ve never been a packager. I had to pick something, though, so I picked what I thought was best – an MSI. If you’re writing arbitrary code (or a custom action) you can just use the Windows APIs directly to set up the security descriptor. But you actually get OK (note I didn’t say “great”, or even “good”) support from the Windows Installer framework.

But how should I build the MSI? I prefer WIX. One comment talks about using the Visual Studio Setup and Deployment Project. I recommend you do not pass go and do not collect $200 until you install WIX instead. It’s not quite as simple, but it actually exposes the power of the platform instead of simplifying it by not letting you actually use the whole thing.

So, here’s the XML I wrote for WIX to create a folder (which I have to do explicitly since I made an empty one) and set the ACL to allow the Everyone group full control of this folder:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="1cf0f45f-3a04-4878-becc-6f6b4331bfb6" Name="InstallerDirectoryPermissions" Language="1033" Version="1.0.0.0" Manufacturer="InstallerDirectoryPermissions" UpgradeCode="f9a6c7b0-6ed9-4b46-9db1-653eeb568236">
    <Package InstallerVersion="200" Compressed="yes" />
    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="CommonAppDataFolder">
        <Directory Id="MySharedFolderId" Name="MySharedFolder">
          <Component Id="SharedFolderComponent" Guid="84A264EF-2BC5-41e3-8124-2CA10C2805DB">
            <CreateFolder Directory="MySharedFolderId">
              <Permission User="Everyone" GenericAll="yes" />
            </CreateFolder>
          </Component>
        </Directory>
      </Directory>
    </Directory>
    <Feature Id="FolderPermissions" Title="InstallerDirectoryPermissions" Level="1">
      <ComponentRef Id="SharedFolderComponent" />
    </Feature>
</Product>
</Wix>

If you compile this to create an MSI, and then edit it with Orca, you’ll see the entries in the Directory, CreateFolder, and LockPermissions tables that make all of this magic happen.

Now, remember how I said that the support was just OK? Well, have a look at what we put into the Permissions entry (which ends up in the LockPermissions table) – it’s just plain English. Well, you’re the one responsible for localizing this. From the docs:

“User - The column that identifies the localized name of the user for which permissions are to be set.”

Why did I choose the Everyone group? Because it’s special cased: “The common user names ‘Everyone’ and ‘Administrators’ may be entered in English and are mapped to well-known SIDs.” (Please note: I don’t speak any other languages, so I don’t have any localized versions of Windows installed – feel free to correct me if you do and I have misinterpreted this!)

But if you just wanted to target users, or domain users, or some other group, and you support multiple languages, you’ll want to do that work inside of a custom action (“A custom action is required to enter the localized name of any other user or group.”). Unless, of course, you already have that value in a property, such as the LogonUser property.

Hopefully this helps you sort out how to do it, instead of us just telling you to “go look it up.” Because you probably have enough to do already.

Shimming Applications on Windows Vista 64-Bit

Chris Jackson — Mon, 01 Dec 2008 19:47:38 GMT

The same question came up two times in 26 minutes (on the same discussion list, no less), so I figured I’d answer it once here as that seems a reasonable indicator that others may have the same question.

What is the deal with shimming on Windows Vista 64-bit?

Well, it turns out it’s a bit of a mixed story, so let’s go through it.

First, Compatibility Administrator itself runs just fine on x64. It’s a 32-bit app, so it’s running on WOW64, but that’s OK. You can run the tool to create custom shim databases to run on either x86 or x64.

Now, let’s talk about the shim engine. It’s installed on x64, and it supports shimming both 32-bit and 64-bit binaries. So far, so good.

But once we start talking about the custom shim databases you can create today using Compatibility Administrator, the story is not complete today.

You see, the custom shim databases you create (whether you create them on x86 or x64) will only shim 32-bit applications. So, while the platform supports shimming 64-bit applications, the tools don’t give you the ability to do so.

So, if you have a native 64-bit application that isn’t working on Windows Vista, then you are unable to use shims today in order to mitigate the problems you discover.

I haven’t come across any problems with native code doing this, but I have come across problems with managed code. There just isn’t much native code that is compiled for 64-bit (and what is available tends to be fairly recent). Managed code, however, defaults to compiling for “any CPU” – which means that the JIT compiler will compile native 64-bit code for managed code when it’s running on 64-bit. So, you can fix it on x86, but not on x64, even though the same app runs on both.

Well, that’s not very cool. That just might discourage you from moving to x64 if you have a broken managed code application, eh?

Well, there are two solutions for that. Obviously you could recompile the application and change the compiler flags to target 32-bit only (but if you’re doing that, you may as well fix the bugs!). If you can’t recompile, however, you’re not stuck. Just use corflags.exe to set the 32BIT flag, and you’ll be on your way.

By the way, if you really want to get under the covers, you can. The underlying cause is that the XML we generate doesn’t have the (optional) OS_PLATFORM attribute. Try it yourself – if you look in Process Monitor, you’ll see that compatadmin creates an XML file in appdata\local\temp. Of course, it deletes this file when it’s done, so you’ll want to catch it before we’re done with it – a quick glance at the stack tells you that you’ve got msxml3.dll in the stack when you’re creating this, so if you bm on msxml3!* and start stepping until the call to CloseFile, you can go into the temp directory and pull out the XML to see for yourself.

Why don’t elevated applications receive environment variables set by non-elevated calling process?

Chris Jackson — Wed, 29 Oct 2008 19:00:36 GMT

I had a conversation with a customer (via email) the other day, and I wanted to to into a bit of detail here explaining what is going on.

Essentially, the customer was attempting to pass information to another application while launching it using environment variables, and it wasn’t working. Of course, it used to work, and it was confusing that it didn’t. Particularly since this failure seems to contradict the following statement directly from the SDK: “By default, a child process inherits a copy of the environment block of the parent process.”

The launching process was not elevated, but the target process was.

I recommended using command lines instead, but wanted to illustrate what is happening here. To see it for yourself, you can create the following two programs:

elevation_launcher.cpp

#include <windows.h>
#include <shellapi.h>

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd) {

    UNREFERENCED_PARAMETER(hInstance);
    UNREFERENCED_PARAMETER(hPrevInstance);
    UNREFERENCED_PARAMETER(lpCmdLine);
    UNREFERENCED_PARAMETER(nShowCmd);

    // Configure the process to launch
    SHELLEXECUTEINFO sei = { sizeof(SHELLEXECUTEINFO) };
    sei.lpFile = TEXT("Elevation Target.exe");
    sei.nShow = SW_SHOWNORMAL;

// Attempt to pass data using environment variables
SetEnvironmentVariable(TEXT("FromParent"), TEXT("Passed using environment variable"));

    // Attempt to pass data using the command line
    TCHAR szCommandLine[] = TEXT("\"Passed using command line\"");
    sei.lpParameters = szCommandLine;

    // Launch the child app
    if (!ShellExecuteEx(&sei)) {
        DWORD dwStatus = GetLastError();
        // ... handle the error
    } else {
        // ... handle the success
    }
    return 0;
}

elevation_target.cpp

#include <windows.h>

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd) {

    UNREFERENCED_PARAMETER(hInstance);
    UNREFERENCED_PARAMETER(hPrevInstance);
    UNREFERENCED_PARAMETER(lpCmdLine);
    UNREFERENCED_PARAMETER(nShowCmd);

    // Retrieve and display the parameter passed using environment variables
    PTSTR pszValue = NULL;
    DWORD dwResult = GetEnvironmentVariable(TEXT("FromParent"), pszValue, 0);
    if (dwResult != 0) {
        DWORD size = dwResult * sizeof(TCHAR);
        pszValue = (PTSTR)malloc(size);
        GetEnvironmentVariable(TEXT("FromParent"), pszValue, size);
        MessageBox(NULL, pszValue, TEXT("Environment Variable"), MB_OK | MB_ICONINFORMATION);
        free(pszValue);
    } else {
        MessageBox(NULL, TEXT("The environment variable was not found"), TEXT("Environment Variable"), MB_OK | MB_ICONERROR);
    }

    // Retrieve and display the parameter passed using the command line
    int nNumArgs;
    PWSTR *ppArgv = CommandLineToArgvW(GetCommandLine(), &nNumArgs);
    if (nNumArgs > 1) {
        MessageBox(NULL, ppArgv[1], TEXT("Command Line"), MB_OK | MB_ICONINFORMATION);
    } else {
        MessageBox(NULL, TEXT("The command line was not found"), TEXT("Command Line"), MB_OK | MB_ICONERROR);
    }
    HeapFree(GetProcessHeap(), 0, ppArgv);

return 0;

}

Now, if you manifest both files with an asInvoker reference, both pieces of data are sent to the child process – the environment variable, and the command line. However, if you manifest elevation_target as requireAdministrator, leaving elevation_launcher as asInvoker, you still get the command line, but you lose the environment variable.

Huh?

To understand what is going on, you have to understand that, when you elevate, the application, you aren’t actually the parent. Rather, the shell calls into the Application Information Service. This service calls consent.exe, which is what prompts for elevation. Assuming the request is approved, the service then uses the linked elevated token and calls CreateProcessAsUser using the linked token.

So, the Application Information Service is the parent of the elevated process, not the process that called ShellExecute(Ex). And the elevated process inherits that environment block.

Of course, it confuses things somewhat that we then reparent the process so it looks like the launching process is the actual parent if you look at the process tree using a tool such as Process Explorer.

Windows Application Compatibility Engagement

Chris Jackson — Wed, 22 Oct 2008 00:50:49 GMT

I’m apparently going for a record, trying to see if I can spend the entire month of October jet-lagged. So far, so good (just got back from Singapore)…

Anyway, I like free stuff ~~as much as~~ far more than the next guy. So, I figured I’d pass this one along – an initiative sponsored by my friend Fumie:

Windows Application Compatibility Engagement (ACE)

Concerned about application compatibility but don’t know what it takes?

Do your critical applications seem incompatible with Vista?

The Application Compatibility Engagement (ACE) program is a 2-3 day fully funded (FREE) on-site consultative engagement for customers who have 100+ PCs, who are considering Vista Deployment, and/or have issues with application compatibility. One of Microsoft’s ACE partners will go to your site and conduct a full assessment and develop concrete steps toward remediating any incompatible applications.

Click to the Microsoft Application Compatibility Engagement Site
Go immediately to Step 2 and fill out the form, OR
Email us with the following basic deployment information:

company name
contact name
contact phone/email
seats being deployed
number of 3rd party apps
number of in house apps
the ACE Partner (see step 2) you’d like to work with (or we can pick one for you)

A Microsoft representative will contact you to discuss your needs.
We’ll organize a conference call to discuss your environment, objectives, and assessment logistics, with the ACE partner, and set an assessment date.

Once you participate in ACE you would have an opportunity to participate in a Case Study and have it placed on microsoft.com.

The Windows SDK Breaks the New TR1 Extensions in Visual Studio 2008 SP1 (Until you Repair It, That Is)

Chris Jackson — Thu, 02 Oct 2008 01:21:59 GMT

One of the main uses for my blog is to share those little annoyances that I spend hours or days solving and spare you the “fun” of going through this yourself. So, even though this isn’t really about application compatibility, which has kind of become the main theme here, it will still hopefully help save somebody some time (thanks to search engines).

I recently picked up a new laptop (Lenovo T61p, FWIW) and got everything set up according to my typical usage scenarios. I was then going about building some code, and discovered that in the transition, several of my builds had broken.

Weird, I thought. We recently moved some MFC updates and the addition of TR1 extensions to C++ from a separate feature pack into Visual Studio 2008 SP1. I was getting all of the MFC extension bits. I was missing some of the TR1 extension bits. I indexed all of the header files, and they just plain weren’t there. The shared_ptr class, for example, lived in zero header files on my hard drive.

What happened?

The fix, of course, is to just re-install Visual Studio 2008 SP1. But what broke it?

It turns out that the Windows SDK lays down files not only in C:\Program Files\Microsoft SDKs\Windows\v6.1\Include, but takes the liberty of laying down (older) files in C:\Program Files\Microsoft Visual Studio 9.0\VC\include. Yep – it up and clobbered the SP1 header files and broke my builds.

So, if you install the Windows Vista SP1 / Windows Server 2008 SDK, you may want to re-install VS2008 SP1 afterwards…

CorrectFilePaths Has to Point to a Directory Which Exists

Chris Jackson — Wed, 01 Oct 2008 01:43:40 GMT

A question came up via comments. (I was going to say that it came up recently, but another glance reveals that it came up in, oh, June. I don’t think I can fairly call that recent…)

“…the fix seems only to work if the directory structure exists…”

This is true, and worth noting. If you point the fix to a directory which doesn’t exist, the shim won’t create the directory, it will just fail, in much the same way the application would fail if it were trying to create an application in a directory which didn’t exist (which, to Windows, appears to be exactly what happened). So, if you’re planning to shim an application and want to create a directory to store things, you should consider creating this directory at install time.

CompatAdmin How Do I Shim Thee? Let Me Count The Ways...

Chris Jackson — Wed, 10 Sep 2008 21:13:37 GMT

When you come across issues debugging applications, there are typically several ways to solve them. Today, I'm going to pick on our own stuff and throw a few different shims at it. Interestingly enough, what I'm going to be shimming up will be the tool I use to create shims: Compatibility Administrator. That's right - I'm going to shim up my shim tool.

What's the bug?

---------------------------
Compatibility Administrator
---------------------------
You do not have administrative rights. Some features might be disabled.
---------------------------
OK
---------------------------

Yeah - I don't enjoy warnings like that, and I certainly don't need them every time.

Solution #1: shim up CompatAdmin.exe with RunAsAdmin. That makes the MessageBox go away because it actually is an admin.

What else could we do? Well, we could figure out which functionality need admin rights. Sitting there using the product non-elevated, I counted two broken features. First, I can't right click and disable a shim. Second, I can't install a shim database.

I don't really need to disable things often, and it seemed to me that installing is something that could be factored out. In fact, a quick glance at Process Monitor tells me that installing a shim database already is factored out! CompatAdmin.exe just calls sdbinst.exe. Is it calling it using CreateProcess (which would require ElevateCreateProcess) or ShellExecute(Ex)? ShellExecute. Nice. So, in theory the think I need to do actually should work just fine, except the software is stopping me from doing it!

---------------------------
Compatibility Administrator
---------------------------
You need administrative rights to perform this operation.
---------------------------
OK
---------------------------

A big fat LUA Bug in our own stuff. It stops me from doing something that works because it doesn't believe it does. Nice work. Let's lie to it.

Solution #2: shim up CompatAdmin.exe with ForceAdminAccess. The dialogs go away, and I can still do what I actually want to do - right click install works just fine, and prompts me when I do that. I then end up running less code elevated, and being more secure. I can read existing databases without elevations. What a huge win! (Well, except not being able to turn shims off, which may be interesting from time to time, but for the vast majority of what I do, this is a great solution.)

Are we done yet, or is there another way to skin this problem?

Well, these are messageboxes. We can suppress them one last way.

Solution #3: shim up CompatAdmin.exe with IgnoreMessageBox (parameter You do not have administrative rights. Some features might be disabled.,Compatibility Administrator). We'll get that to stop annoying me! It still shows the MessageBox when I try to install a database (which is not helpful) but if I suppress that one also, then it just does nothing and says nothing, which is arguably not a very good outcome. But at least it's a touch less chatty. I'll chalk this up as the worst solution.

Personally, I've been using ForceAdminAccess lately. But I thought this was a fun app to show the options available, particularly since you need to shim CompatAdmin somehow to make it useful. (Yeah, I know - that's kind of ridiculous and we should fix it. The bug has been open for over a year - I just poked the team again.)

10 Minute Demos of Windows Vista Deployment Topics

Chris Jackson — Wed, 10 Sep 2008 05:11:38 GMT

I haven't seen these pop up yet - if you're looking for a quick demo of several of the tools available to assist in a Windows Vista deployment, you may enjoy the following 10 minute demos:

http://download.microsoft.com/download/D/6/9/D6943262-EF5A-4733-8247-9BF7A6FEF299/Application_Compatibility_Demo.wmv

http://download.microsoft.com/download/D/6/9/D6943262-EF5A-4733-8247-9BF7A6FEF299/Assessing_Hardware_Readiness.wmv

http://download.microsoft.com/download/D/6/9/D6943262-EF5A-4733-8247-9BF7A6FEF299/MDT_Install_and_Image_Creation.wmv

http://download.microsoft.com/download/D/6/9/D6943262-EF5A-4733-8247-9BF7A6FEF299/Migrating_User State.wmv

http://download.microsoft.com/download/D/6/9/D6943262-EF5A-4733-8247-9BF7A6FEF299/System_Center _Essentials.wmv