Pat's Application Compatibility Blog

Q: Why Doesn’t Drag-and-Drop work when my Application is Running Elevated? – A: Mandatory Integrity Control and UIPI

If you run notepad elevated (Right click | Run as Administrator), and you try and drag-and-drop a file from Windows Explorer, nothing happens. It looks like it is going to work because the pointer icon changes but the file doesn’t open. Weird, huh?

What’s Going On?

In the traditional NT Security model (prior to Vista), all processes on the same desktop ran with the same security token and had all the same privileges.  UAC changed this by allowing processes with different privilege levels on the same desktop.

Lower Privilege Processes Can’t Interfere with Higher Privilege Processes

In order to prevent potential elevation of privilege attacks, certain functionality needs to be blocked.  This is implemented through Mandatory Integrity Control (MIC).  All processes and all resources (files, registry, etc.) have an integrity level assigned. MIC prevents a standard user process from writing to a protected per machine location like Program Files or the HKLM registry hive. I won’t go too deep into MIC in this post but the following is a great resource if you want more info: Inside Windows Vista User Account Control.

User Interface Privilege Isolation (UIPI)

Okay, back to our drag and drop issue… A “sister” technology that works in conjunction with MIC is UIPI.  UIPI blocks Windows messages being sent from process with a lower MIC level to one running at a higher MIC level. Drag-and-drop is implemented via Windows messages.  Therefore, if you try and drag-and-drop a file from Windows Explorer (medium MIC) to Notepad running elevated (high MIC), the Windows messages are blocked and drag-and-drop doesn’t work.

You can use ChangeWindowsMessageFilterEx in your application to allow specified Windows messages to not be blocked. Unfortunately, this isn’t recommended as a safe solution for drag and drop due to the messages that drag and drop uses. 

Okay. Now What?

The best solution is to only use drag and drop between the same MIC levels. With UAC enabled, Windows Explorer will run at a medium MIC level.  Therefore, your application (Notepad in our example) needs to run at medium (or lower) MIC level.  The bottom line is that drag and drop from Windows Explorer will not work if your application is elevated.  If you find yourself in this situation, you may need to rethink your application design or not support drag-and-drop with UAC enabled.

Common Application Installer Issues on Windows 7 (and Vista)

There are some very common application installer issues developers run into due to UAC.  Most of the issues are easy to fix.  I’ll cover the most common issues in this post.

Per Machine Installers Need Admin Privileges

Unless you have a ClickOnce installer, your installer probably installs to a per machine location. The recommended location is Program Files which requires administrative privileges. Therefore, your installer will need to run elevated.  MSI based installers handle this automatically. Exe based installers require an application manifest with a run level=requireAdministrator.  If your exe installer is elevating without a manifest, this is due to the Installer Detection mitigation.  It is recommended you explicitly manifest the installer rather than relying on the mitigation.

My “Updater” Fails

Applications may “self update” or have a separate application that checks for update and applies the changes.  The updater periodically checks for an update. If an update is available, it downloads and applies the update. If the updater is running as a standard user under UAC, it will fail when trying to write to Program Files.

Possible solutions with consent dialog:

• Manifest the updater with a run level=requireAdministrator. This will cause the updater elevate when it executes.
• Launch the updater by elevating using ShellExecute.

Possible solutions without consent:

• Use User Account Control Patching (not supported on Server)
• Have an updater Windows service. Run the service with an account with administrator privileges.
• Use a scheduled task to perform the update check and installation. Configure the task to have administrator privileges.

My Installer Fails and Does a Rollback

I was talking with a developer who had been testing his app on Windows 7 and had very few issues.  I asked him if he had any UAC issues.  He said, “No, it works just fine under UAC. But we need to tell the user to disable UAC, install the app, then turn UAC back on.”  It turns out, he was having the following issue.

MSI Installers Have a user context and an admin context.  Custom actions can run in either context and default to the user context.  If your custom action is doing something that requires administrative privilege (e.g. register a COM component), it will fail and cause the installer to rollback.

Possible Solution:

You need to make the custom action run in the admin context. This is done by setting the noImpersonate bit for the custom action. Chris has a great post on this topic.

A quick test to verify if this is likely the issue is to right click the installer and select “Run as Administrator”.  If it succeeds, it’s probably this issue.

My Settings are Missing or in the Wrong Profile

I like running my machines as a Standard User (not a member of Administrators group).  If I need to install a program, I get prompted for an administrator account and the installer runs with the administrator account I choose. This works great for my home machines that my kids use. :-)

Frequently, this scenario is not tested for installers (see our testing document for a good list of tests). An issue can occur if settings are configured at the end of the install.  Since you are running the install as a different user, the settings are configured for the administrator account rather than the standard user account.

Possible Solution:

Per user configuration should happen during first run of the application by the user. This avoids this issue and does a better job supporting multiple users.

Common Problems with Checking OS Versions in Code

When a new OS is released, a high percentage of applications don’t install or don’t run because they check for a specific OS version.  The application or installer checks for a specific version number and exits if it isn’t what is expected. I’ve heard claims of up to 50% of incompatibility issues are due to a simple version checks.  So many applications check version that this influences how Microsoft increments version number.

Windows 7 = Windows 6.1

It’s true. If you look at the version number of Windows 7, it’s version 6.1.

This was done for application compatibility. Most of the time, developers only check the major version. So, if Microsoft knows that application compatibility is very good between releases, only the minor version number is incremented. This trick was also done from Windows 2000 (5.0) to Windows XP (5.1).

Windows Knows How to Lie

Let’s say you only want your application to install on XP. Your installer checks the OS version and exits if it’s not equal to 5.1.  There’s a compatibility feature that has been in Windows since Windows 2000 called “shims”. Shims “trick” API calls by acting like a legacy OS. The “version lie” shim returns whatever OS version you want. Therefore, the installer can be tricked and the application can be installed regardless of the version check.  The “version lie” shim can be implemented several different ways -- by the user via the Compatibility tab in properties, the built-in “shim database”, by enterprise administrators via the ACT Toolkit, and by the Program Compatibility Assistant.

Don’t Check Version

The best option for checking version is to not do it. Sometimes you may feel that you need to check version (especially if your boss tells you).  Checking version and blocking the installation or exiting won’t stop the user if they are determined.  In fact, if you just exit, the user has no idea what has gone wrong.

The following table outlines why you may be version checking and suggestions to avoid problems:

Version Checks and OS Upgrades

One of the unusual side affects of version checking deals with upgrade scenarios. Here’s where version checking can get you into trouble.

1. The application installs and runs just fine on an OS (e.g. 6.0).
2. The OS is upgraded (e.g. 6.1).
3. The application has a version check to exit if the OS is not equal to 6.0. Therefore, the application now exits on the newly upgraded OS.
4. The installer has a version check to exit if the OS is not equal to 6.0.  The user tries to uninstall the application. The uninstaller exits because the OS is 6.1 and the user cannot uninstall the application.

Uh oh…

If You Must… The Most Correct Way to Check Version

If you decide to check version. Make sure you think through changes in major and minor version numbers. If you check for Windows 7, check for Windows 7 and greater so you don’t break when then next OS is released. 

Here’s some sample code that checks for OS versions:

Using the “secret” Windows 7 Problem Steps Recorder to Create Step by Step Screenshot Documents

When I show this tool to developers or QA guys, their eyes light up with excitement. When you work in Application Compatibility, you spend a lot of time documenting problems ;-).  In this post, I’ll talk about some of the tricks and tools I use for documenting issues.

There’s a slick new tool called the Problem Steps Recorder that is included in Windows 7.  It’s intended for users to capture step by step actions and screenshots to illustrate a problem. It’s a great tool for its intended use. However, if you create a lot of documents with screenshots or need to document a procedure, this tool can save you a lot of time. 

Finding PSR

The biggest issue with PSR is finding it.  Since it’s intended as a troubleshooting tool, the tool is not directly exposed in the Start menu or Control Panel. When I demo PSR, my corny joke is “You need to use PSR to show people how to find PSR.”

Here are two ways to launch the tool:

1. Launch the executable by typing psr.exe from a command prompt or the search bar.
2. Type the keyword “record” in the search bar:
   

“Leveraging” the Output

After you record your steps, PSR saves the report in a zipped MHTML file. This is so you can easily send the report to someone via e-mail. Within the MHTML file, the screenshots are jpg files. Just right click and “Copy” the images from the report to paste into your own documentation. I’ve had mixed luck with trying to copy and paste a section of screenshots.  I prefer pasting a single screenshot into a Word document.  Try both to see what works for you.

Missing Screenshots

Before you create a nice long capture showing your Mom how to configure her mail client, there are a few common problems that may result in lost screenshots.

“No screenshots were saved for this problem step” issue

By default, PSR only saves the last 25 screenshots to help reduce the size of the capture file. If you will be capturing more than 25 screenshots, increase the “Number of recent screen captures to store” setting.

“There are windows on your desktop that are running as administrator” issue

PSR launches as a standard user and will warn that there are applications that are running elevated on the desktop.  If PSR is running as a standard user, it won’t be able to capture any screenshots or interactions with applications running elevated.  To fix this issue, follow the advice PSR gives you and run PSR elevated.

Don’t Forget about the Snipping Tool

For quick screenshots, I like the Snipping Tool (snippingtool.exe). It originally started as a PowerToy and has been included in all editions of OS beginning with Vista. It can capture window, rectangular, free form, and full screen snips. It’s quite handy.  I used it for the snips in this post.

Snip Tip:

You may have noticed I captured the Start menu in one of my screenshots.  This trick is outlined in the Snipping tool help. To capture a menu: Start the tool; Press Esc; Display the menu; Press Ctrl+Prnt Scrn and then use the snipping tool to capture the menu.

Capturing Dialog Box Text

Okay, this has nothing to do with PSR but I use this all the time when describing a problem, creating documentation, or searching for known errors. If you press Ctrl-C when a dialog box is active, the text is sent to the clipboard.  For example, if I press Ctrl-C when this dialog is active:

The clipboard contains the following:

---------------------------
Problem Steps Recorder Warning
---------------------------

There are windows on your desktop that are running as administrator.

If you want to record your interactions with them, you may have to run the Problem Steps Recorder as administrator as well.

You can do this by clicking on the shield button next to the time counter on the Problem Step Recorder UI. Please note that your current recording session will be discarded if you do so.
---------------------------
OK  
---------------------------

I hope this helps. Happy documenting…

Common Issues with 32-bit Applications Failing on 64-bit

In most cases, 32-bit applications execute with no issues on 64-bit thanks to WOW64. However, there are a few cases that you may need to make modifications to your application in order for it to work on 64-bit.  I’ll cover the common issues and possible solutions in this post.

64-bit OS Basics

Why does my .NET Application Compiled as “AnyCPU” fail with a BadImageFormatException on a 64-bit OS?

The last issue mentioned in the table above is a very common scenario with .NET applications on 64-bit.  I’m going to step through the specific issue in more detail.  In this scenario, the application is compiled as “AnyCPU”.  This is the default setting for a .NET project.  On 64-bit, the application will use the 64-bit runtime.  If a referenced library is compiled to target 32-bit only, it will not load into the 64-bit process. Therefore, you get an error similar to this:

BadImageFormatException was unhandled. Could not load file or assembly… An attempt was made to load a program with an incorrect format.

We solve this problem by matching the application “bitness” with the library. You need to make sure the application and all the dependent libraries target the same processor. e.g. “AnyCPU” or “x86”. If you have the option to recompile, make sure all your projects match. If you can’t recompile, you can use corflags.exe to change the header (See Chris’ post).

I hope this helps with getting your apps running on 64-bit.  As always, the AppCompat cookbooks are a good reference. Here are links to the 64-bit compatibility sections:  Application Compatibility: Windows Vista 64-Bit, Removal of Windows Registry Reflection

Tales of Application Compatibility Weirdness – Demystifying UAC Virtualization

We had a customer in the lab recently and they were quite certain their application was Windows 7 ready. To their surprise, it had several issues in certain situations.  In this post, I’ll talk about one of the situations they encountered as well as other stumbling blocks you might run into with UAC Virtualization.

Why Doesn’t my Program Work in Program Files?

For this particular application, the default install directory was a custom directory on the system drive (e.g. C:\MyApp).  The application performed as expected in this scenario. However, Microsoft recommends that applications be installed in Program Files. This is secured by default to reduce elevation of privilege attacks and is a known location for enterprise inventory tools. Also, installing to program files is a client logo requirement.

We changed the install location to Program Files and the application eventually failed. Why?

User Account Control = Standard User by Default

Program Files is considered a “per machine” install location.  It is protected by Mandatory Integrity Control and only allows users read and execute rights.  Under UAC, processes will run as a limited standard user and are denied write access to Program Files. The application was designed to store various data files in the install directory. It also stored data in the registry under under the protected HKLM\Software key as well. Here’s where it starts to get confusing… Most of the files and registry keys appeared to be able to write but others were not. 

Why?

UAC Virtualization to the Rescue (sort of)…

There is a mitigation that is included in Vista and Windows 7 called UAC Virtualization. This mitigation is intended for this exact scenario -- legacy applications that write to protected per-machine locations. If a legacy (non-manifested) application tries to write to a protected directory such as Program Files or certain keys in the HKLM hive, the “access denied” error is captured and the write is redirected to the user’s UAC virtual store. This allows legacy applications that store state in protected directories and registry locations to continue to work in most cases.

So, why did it fail?

Fuzzy Gray Area

UAC virtualization’s goal is to virtualize data. It doesn’t virtualize various executable files (exe, bat, dll, etc.). It doesn’t virtualize files that the user is explicitly denied write access. This is what occurred for the application and why it failed.

Mystery solved…

…but Wait. There’s More Weirdness!!!

The scenario of a few files not being virtualized is uncommon.  Here are a few more common issues that can really make you scratch your head.

Weirdness Due to Multiple Users

UAC Virtualization works by catching the access denied error writing to a “per machine” location and redirecting it to a “per user” location.  This solves the problem of writing the data but this can change the behavior of your application. For example, if a game application is designed to store a high score file to Program Files, every user will get his/her own copy of the high score file. This isn’t the correct behavior for a high score file. There should be one file for all users.

Weirdness Due to Running an Application Elevated

If you right click an application shortcut and select “Run as Administrator”, this runs the application with the full admin token. The application now has write access to protected locations. Therefore, UAC virtualization is disabled and it will read and write from the “per machine” location instead of the virtualized “per user” location. Now, you have a situation where the application is using completely different files or may not work at all.

Please, make it stop!

You may be saying “This is madness.”  Remember, this is a mitigation that greatly improved the ability to have legacy applications that weren’t designed to run as standard user to continue to work.  Without this mitigation, lots of existing applications that store state in “per machine” protected locations would fail with access denied errors.

Design for Standard User

Applications that target Vista or above should be designed to be run by standard users. This means that the application only writes data to “per user” locations in the file system or registry. Standard user was introduced in Windows XP. Vista introduced “standard user by default” with UAC. Running as standard user is here to stay but virtualization will eventually be removed in future OS releases.

Ideally, you want to design your application to only write to per user locations. Sometimes, that’s not possible or it doesn’t make sense. Here are a few suggestions on how you might change your application if it needs to store per machine data.

For files, you may want to write to the The programdata directory. It is intended for per machine configuration data.  Check out Chris’ post on options for writing configuration data.

For the registry, you may want to create your own key HKLM\Software\MyCompany\MyApp and then set the appropriate permissions at install time. Read more about registry virtualization here.

Manifest Your Application

Once you have your application ready to run as a standard user, you will want to disable the mitigation.  This is done by adding an application manifest with the “trustInfo” section to your application. For more information on manifesting your application, look at my post on manifests.

Answers to Several Application Manifest Mysteries and Questions

Recently, someone asked me this question in e-mail -- “How do I get my application to run elevated when someone launches it?”   Instinctively, I responded with a “You need to manifest it.”  I got a nice long e-mail in return. ;-) I quickly realized that application manifests appear simple but are quite confusing. Manifests are becoming very relevant as they control much more application behavior in Windows 7 and future OS’s. Any application that targets Vista or greater, should contain an application manifest.

Application Manifest Basics

• An application manifest controls execution behavior of a binary and is defined in XML.
• An application may or may not have an application manifest.
• Application manifests can be embedded into an executable or can be an external file.
• Application manifests have been around since XP. We keep extending them to control more behavior and tend to create new MSDN articles: XP introduced side by side assemblies, Vista added UAC behavior, Windows 7 added switchback and DPIAware. New sections are ignored on previous OS’s.
• In XP, external manifests have priority and over embedded manifests. In Vista and beyond, embedded manifests have priority over external manifests. For example, if you have an embedded manifest and and external manifest for an application – On XP, the external one will be used; on Vista and later, the embedded one will be used.
• On Vista and Windows 7, a manifested application with a trustInfo section will control what token will be used to start the process (standard user or admin). Also, all legacy mitigations will be disabled. This includes UAC Virtualization, Installer Detection, and the Program Compatibility Assistant.
• Windows Client Logo requires applications to be manifested.

Checking for an Embedded Manifest

You might be wondering if your exe’s have embedded manifest and what they look like.  My favorite tool to dump a manifest is sigcheck. Use the –m switch to dump the manifest.  E.g. sigcheck.exe –m myapp.exe

Example output of a manifest with only side by side behavior:

This executable is a native C++ program.

Example output of a manifest with UAC trustInfo section:

This executable is a .NET C# program.

If you are wondering what those three weird characters at the beginning of the manifest are, it is the byte order mark. I talk about it in this post.

External Manifests

An external manifest is a text file that contains the manifest XML.  The file must exist in the same directory as the executable and have the same name with a “.manifest” extension.  For example, if the name of your executable is MyApp.exe, your manifest file would be named “MyApp.exe.manifest”.

Remember, in Vista and beyond, embedded manifests have priority over external manifests. Therefore, if the executable already has an embedded manifest, the external manifest will be ignored.

Embedding a Manifest

There are two ways you can embed a manifest.  You can have the compiler embed it or you can embed it with the manifest tool (mt.exe) included in the Platform SDK.

Embedding at Compile / Build Time

Visual Studio 2008 has functionality to embed manifest for native and managed projects. 

For Visual Studio 2005, Catherine Heller has a great post on how to embed manifests in your build process.

Embedding using mt.exe

The manifest tool is a command line tool that lets you add or merge manifests to an executable.  For usage, check the MSDN article for the Manifest Tool.  Here’s an example for adding a manifest to an executable:

mt.exe -manifest MyApp.exe.manifest -outputresource:MyApp.exe;#1

You will be modifying the binary when you embed the manifest. If your exe was signed, this will invalidate the signature and it will need to be re-signed.

Planning for the Future

Windows 7 introduced “switchback” into the manifest by adding a <compatibility> section to the manifest.  This allows you to state what OS you support. So, if you insert the tag that you support Windows 7, you will get a handful of new behaviors.  Otherwise, your app will “switchback” to the Vista behavior.  The plan is to use this section to make better choices for compatibility behaviors in future OS’s.  When adding manifests to applications, consider adding the supportedOS tag.

Questions from the Developer Booth at TechEd Europe 2009

I had the opportunity to go to Berlin for TechEd Europe 2009.  I delivered a presentation on Application Compatibility and the rest of the time I hung out in the “Test your app on Win 7” and “Win 7 Developer drop in center”. I got some great questions from attendees.  I thought I’d blog some of the general Q&A. Thank you to all that stopped by the booth. I loved Berlin.  I hope I get to go back soon.

Q: Do I need to worry about anything in Windows 7 for web apps?

A: There are some IE8 changes that may affect web applications. The Internet Explorer 8 Readiness Toolkit is a very good reference.  The developer checklist is a good place to start.

Q: What do I need to worry about for existing installers on Windows 7?

A: The common problems that are encountered with existing installers are the same issues encountered in Vista:

• Version check criteria
• MSI custom actions

Ideally, you should not check for version if possible. Version checking tends to block applications that may install and run just fine on a newer OS.  If you need to check version, you should display a warning rather than exiting the installation. Version checking can also cause issues after an upgrade with uninstall. If you check version, the user may not be able to uninstall your application after an upgrade to the new OS.

MSI custom actions can run in a standard user context or the administrator. Sometimes the custom action is running in the wrong context.  Chris Jackson has a great post on the common issue with deferred custom actions.

Q: Where can I find info on developing on Windows 7?

A: The Windows 7 Developer Guide gives a good overview of new developer functionality.  If you are looking for presentations and code samples to get you started, check out the Windows 7 Developer Jumpstart Kit.

Q: I’m a .NET Developer. What’s the guidance for developing on Windows 7? Should I use the Code Pack or wait for .NET 4.0?

A: The short answer is: Use the Code Pack today but think of it as free code to include in your application that wraps the native Windows 7 API’s. In .NET 4.0, you will see some of the new Windows developer features available in WPF.  Yochay Kiriaty has recently outlined guidance on this topic.

Q: .NET 1.1 SP1 support for Windows 7?

A: As with all older products, be sure to check the support lifecycle for the product first. There isn’t an official statement of .NET 1.1 SP1 compatibility for Windows 7. However, because compatibility was a key goal between Vista and Windows 7, efforts were made to ensure .NET 1.1 SP1 works on Windows 7.

Q: Does <insert app name here> work on Windows 7?

A: The Compatibility Center is the best reference to get information on what applications have been reported to be compatible with Windows 7.

Windows 7 Application Compatibility Testing Guidance document

If you have an existing application, you may be wondering if it’s going to work on Windows 7.  If it works on Vista, you have a good shot at it working on Windows 7.

As a developer or a tester, you may be wondering if you have tested your application to uncover potential issues on the new OS. We’ve worked with a lot of ISV’s over the past few years and we’ve come up with a document that focuses on the common issue areas of application compatibility with testing scenarios.  The Windows 7 Application Compatibility Testing Guidance document can be downloaded from MSDN Code Gallery.

Displaying the UAC consent dialog on the desktop

I had written a draft of this post a while ago (last year).  I use Live Writer as my blog editor.  Between Live Writer and Intellimirror,this draft has survived multiple reloads of interim builds of Windows 7.  So, I think in some ways, it deserves to be resurrected and posted. :-)  Here’s the post with a Windows 7 update:

Frequently, we need to give presentations over Live Meeting.  When we demonstrate UAC, the consent dialog is displayed on the secured desktop.  Therefore, the Live Meeting participants don't see the UAC consent dialog.  To solve this, we use a policy setting to allow the dialog to be displayed on the user desktop. 

The reason I bring this up is that this same trick can be used if you have an automated functionality test that needs to click the consent dialog.

You can adjust this with a policy.  The local security policy (Run secpol.msc) is Local Policies | Security Options | User Account Control: Switch to the secure desktop when prompting for elevation.  Set this policy to "disabled" to allow the consent dialog to be presented on the user desktop.

On Windows 7, this setting is exposed through the UAC slider bar UI.  Just slide the knob to the next notch down from the default:

Chris talks all about the slider in his post.

Of course, running with this policy disabled opens up some risks and isn't recommended for normal operation.  For more information on the secure desktop and UAC consent can be found in the UACBlog in the User Account Control Prompts on the Secure Desktop post.

Developing Compatible Applications for Windows 7 webcast

I know I could talk all day about application compatibility topics and not cover everything that can be discussed.  Here’s a one hour webcast  I did that focuses on the top issues and most confusing topics for Application Compatibility.  I do some of my favorite demos showing UAC architecture, data redirection, services isolation, and mandatory integrity control.  The target audience is for developers and testers.

Here’s the webcast: Developing Compatible Applications for Windows 7

My main goal in this presentation is to talk about moving application from XP or Vista to Windows 7 and demystify some of common problems.  I also wanted to “plug” the Application Compatibility Cookbooks.  These documents are some of the best resources for understanding what breaking changes have occurred and how to mitigate them.

Make sure to reference both cookbooks. Most of the breaking changes are in the original XP to Vista cookbook.

Moving from XP-> Vista/2008 –> Win7: “Application Compatibility Cookbook”

Moving from Vista -> Win 7: “Windows 7 Application Quality Cookbook”

OEM Ready Test Case 1 Incorrectly Fails with a UTF-8 manifest

I haven't posted in a while.  I've been helping out with a couple other programs we have going on in the labs these days.  OEM Ready is a subset of Certified for Windows Vista targeted at applications that ship on new PC's.

If you are using the automation in the OEM Ready Certification Test Tool, you can get a false failure if your application has a UTF-8 embedded manifest that has the byte order mark (BOM) included.  Visual Studio 2008 includes the BOM if you use it to embed the manifest. 

The error in the log looks something like this:

Sigcheck is used by the test tool to dump the manifest.  Sigcheck outputs the BOM as garbage characters ().  This throws off the test tool and it gives an incorrect result.  This is a known bug with the tools and will be fixed.  For now, if you run into this problem, you can submit this test case as a pass.

Pat

Registering ATL Performance Counters on Vista and Server 2008

If you use the ATL Server performance counter libraries, you may run into a problem on Vista and WS08.  The ATL libraries don't play well with the updates to Windows Resource Protection.  WRP enforces restrictions on the registry to prevent corruption of performance counters.  ATL breaks these rules and tries to update the registry directly.

There is a workaround to the issue that is outlined in Q933241.

To avoid this problem, the recommended way to add counters is through the lodctr tool or the API LoadPerfCounterTextStrings.  See Adding Performance Counters.

If you are really ambitious, ATL Server code has been released as shared source.   I haven't looked at the code or the project but there may be an opportunity to change the way ATL loads perf counters in the future:  http://blogs.msdn.com/vcblog/archive/2007/01/19/atl-server-visual-c-shared-source-software.aspx

Pat

Windows Server 2008 Application Compatibility presentation

In the compatibility labs, we always give an big overview presentation about Windows application compatibility.  There's a lot of overlap between Vista and WS08 AppCompat but we call out some specific areas that mostly affect WS08.  We've recorded the WS08 specific section of the presentation and posted it to Channel 9.  I hope you find this useful in preparing your applications for WS08.

Detecting what Server Roles are installed on Windows Server 2008

I think there is always a nugget of information that inspires a blog.  This is the idea that inspired my blog.

By default, Windows Server 2008 has no server roles installed.  This isn't intended to make you do more work (it's a feature).  The goal is to be secure by default.  After the OS installed, you add the roles and features that that are needed.

So, from an application compatibility point of view, your application may require a role that isn't installed by default.  There are two ways to programmatically query what roles and features are installed.

Using ServerManagerCmd

UPDATE: ServerManagerCmd is being deprecated.  It is recommended to use PowerShell cmdlets for Server Manager starting with R2 forward.

There's a cool command line utility that has been added to Window Server 2008 called ServerManagerCmd.  ServerManagerCmd allows you to add, remove, and query roles and features. 

If you execute the following command:

> servermanagercmd.exe -query roles.xml

An XML file of all the roles and features installed will be created.  You could then parse that file to determine what roles and features are installed.  I was hoping to find something in the scripting repository to do this but couldn't find anything.  Powershell would be a good option but remember... no features are installed by default.  Powershell and .NET 3.0 would need to be installed.  You could do that with servermanagercmd as well.

For example:

> servermanagercmd.exe -install Powershell

ServerManagerCmd is great for scripting but what if you want to do determine installed roles in your application's installer? ...or avoid lots of parsing in a script? ..or needing to install .NET and Powershell?  WMI is probably a better choice.

Using WMI

With Windows Server 2008, there is a new class in the WMI namespace \Root\cimv2 called Win32_ServerFeature.  This will allow you to use WMI to iterate through what roles and features are installed.  WMI is a very good option for determining in your installer if a prerequisite role is installed.