Microsoft Terminal Services Compatibility Analyzer - Analyzed

As promised, I have spent a little bit of time reviewing/investigating the Microsoft Terminal Server Compatibility Analyzer on a few packages.

I downloaded and installed the TS Compatibility Analyser and attempted to run the application against a few packages on my desktop; Adobe Reader 8, WinZip 10, and Real Player. I chose these applications as they are readily available, are known to work on Terminal Services (though you may not choose to deploy them to a Terminal Services environment)

After the quick installation, I selected C:\Program Files\Adobe\Reader 8.0\Reader\AcroRd32.exe and tried to launch the application from within the TS Compatibility Analyser shown here;


As I mentioned in my previous blog, it appears that we can scan for; File Access, Registry Access, INI File Access, Access Tokens, Privilege (I assume elevation requests) , Name Space and Process information.

I was a little disappointed to see that once attempted to launch the application via the Launch button, I was requested to down the Microsoft Application Verifier. Application Verifier is a key component of the Microsoft Application Compatibility toolkit . Microsoft describes the Application Verifier as;

"Application Verifier is a runtime verification tool for unmanaged code that assists in quickly finding subtle programming errors that can be extremely difficult to identify with normal application testing. Application Verifier is designed specifically to detect and help debug memory corruptions and critical security vulnerabilities. It makes it easier to create reliable applications by monitoring an application's interaction with the Windows operating system, profiling its use of objects, the registry, the file system, and Win32 APIs (including heaps, handles, locks, and more). "


Once downloaded and installed, I tried again, this time successfully loaded Acrobat Reader and generated some results.



And some registry analysis




As you can see by the "Tabs" on the image results from the TS CA results, there are other objects and Privilege issues for this sample application that may cause an issue. The more interesting aspect of this analysis is illustrated in the summary overview.




These results are really interesting as they break things down into nice, detailed groups for you. But, I am a little surprised by the issues raised. Acrobat reader works fine under Terminal Services - but these results indicate a compatibility issue.

And, somewhat cryptically, the column titled "Works with Virtualization" (which I assume Virtualization refers to SoftGrid or MAV) give me even more cause for concern. Have a look at the following diagram.





Sure, it makes sense that you should not be able to write to a protected system area, but you should be able to write to your user profile (USERDATA) area.

So, I have the following questions for the Microsoft TS Compatibility Analyser;

1. How are you detecting the TSAware bit?
2. What does the "Work with Virtualisation" column really mean?
3. What algorithms make a YES or a NO in the Virtualization column?
4. Can we get a list of forbidden API calls for Terminal Services
5. I know this is a BETA release, but more documentation would be helpful
6. What files, directories and registry keys does the TSCA think causes compatibility issues?

I will ping the guys from the ACT team at Microsoft and see if I can find out. Watch this space.

References and useful links;

Just for those who have not read my previous posts, the TSCA application can be downloaded from the Microsoft Connect BETA website here: https://connect.microsoft.com/tsappcompat/Downloads/DownloadDetails.aspx?DownloadID=11658

If you have to Adobe Acrobat running on WTS, there is some documentation from Adobe located here: http://www.adobe.com/devnet/acrobat/pdfs/wts_8.pdf (watch out: PDF warning)


To download the Application Verifier separately, look here: http://www.microsoft.com/downloads/details.aspx?familyid=bd02c19c-1250-433c-8c1b-2619bd93b3a2&displaylang=en

And, for some instructions on how to use the MS Application Verifier look here;
http://support.microsoft.com/kb/286568

Microsoft Terminal Services Compatibility Analyser (MS TSCA)

OK, my previous blog was a little light... A few quick references to another posting, a link to a Microsoft release and a quick surmise of a potentially helpful tool. Not the great insightful depth that you would expect. But hey, we are only human... And so with this latest post, I bring you another tool from Microsoft. Ohhh nooo...

On the Microsoft BETA site (http://connect.microsoft.com/) there has been a new "addition" to the Microsoft Application Compatibility Toolkit (ACT, Version 5); the Terminal Services Compatibility toolkit. I use the "quotes" as I am not quite sure if this tool is now part of ACT or if this tool will be included in future versions of the collection of compatibility and analysis tools that are shipped as ACT.

The Microsoft BETA Connect site describes the Terminal Services Compatibility Analyser (TSCA) as;

"TS Application Analyzer is a runtime program analysis tool to enable administrators/users to determine if they can deploy an application on TS with a degree of confidence. It provides a summary of TS incompatible behaviour of an application and provides recommendation indicating the confidence level for deploying the application on TS".

Reading from the user manual it appears that the TCSA can identify the following issues;

• Shared resources – Files/registries
• Access/Privilege issues
• Windows API calls with special cases for TS


For TS Compatibility Analyser installation notes and the user guide look here; https://connect.microsoft.com/tsappcompat/content/content.aspx?ContentID=8267. (you need to sign in first with your Microsoft Live ID - of course)

For a deeper dive into the technical requirements and developer information, consult the MSDN Terminal Services documentation located here; http://msdn.microsoft.com/en-us/library/bb892075(VS.85).aspx

I will review the TSCA over the next week, but am delighted with some of the points raised by the developers of this tool. Noting that Microsoft Terminal Services (TS) may cause application compatibility issues due to the shared nature of application resources (as opposed to the single user nature of desktop environments) the TSCA also investigates registry and file-system security issues as well as Application Programming Interface (API) issues. In addition, the tool offers a remote view of the results and allows for a centralized "administrator" view of several machines under analysis. I am little concerned about some of the filtering of the TSCA output required to get the "right" level of results.

And I think this is where the real utility of the tool will be questioned; a skilled administrator will be still be required to determine if the results are relevant to the application and if any issues raised really will cause an issue for the application under is intended use scenario.

I have some questions here;

1) What kind of volume of results are we going to get from this application?
2) How well can we filter out "noise" from the API and registry access requests?
3) How do we determine a SERIOUS issue from a less potentially serious compatibility issue?
4) Does the TCSA take into account other platform issues? (i.e. 64-bit or Windows 2008 vs. 2003SP1?)
5) Will global/shared memory issues be identified (i.e. Shared RPC ports are a hassle)

Clearly from the product description of the TCSA, the focus will be on Terminal Services compatibility issues.

So, we are going to be missing stuff like;

1) Application conflict analysis: Does this application break another when installed on the same machine?
2) Dependency analysis: Does the application have everything it needs to function correctly?
3) OS level platform analysis: Will my drivers and services work on the TS server platform (i.e. Windows Server 2008)?

It looks like the guys from Microsoft are taking the application compatibility issue seriously now and including some additional coverage for the TS platform - so KUDOS to the AppCompat boys..

Will keep you posted on the results of my findings... Ohhh so much fun... So many ways to break an app...

Helpful Softgrid/MAV virtualisation tools

Still a little groggy from the rather grey/bleak/UK wasteland that is a typical UK bank holiday. I can't really complain as the weather looked terrible from the inside - but once you were outside, it was mild and actually quite good for sport. That said, a few glorious days on the beach right now, would not go amiss.

I wanted to mention a rather useful tool that have recently come from Microsoft.

As quoted by one of the TechNet blogs;

"The Microsoft Installer (MSI) Utility for Microsoft Application Virtualization, a utility for SoftGrid Application Virtualization solution that bridges the gap between traditional physical control of installed applications and the new paradigm of virtual applications."

This means that you can now load MSI packages into SoftGrid environments and not have to "Sequence" or convert them to SoftGrid (SFT) packages before deployment. This would allow an organization to utilize their existing SMS environment and "dilute" their application management efforts through supporting two different application management formats.


Have a read:
http://blogs.technet.com/softgrid/archive/2007/09/11/microsoft-unveils-plans
-for-the-msi-utility-for-microsoft-virtualization-at-vmworld.aspx

And the official source:

http://www.microsoft.com/presspass/features/2007/sep07/09-11virtualization.mspx


This makes sense as the SoftGrid SFT file format was riddled with Open Source/GPL software and the compression algorithm was written by a lovely French chap who detested Microsoft - hardly the recipe for a thriving format for M$. I am not too sure that this is going to work for more difficult/complex applications. However, it may help with some of the rapid proto-typing required to get a SoftGrid (aka MAV) environment off the ground and get some applications sequenced quickly, ready for testing (i.e. thrashing).

IE7 - Another Compatibility Platform to consider

Getting applications to work on Vista or Windows Server 2008 is not the only compatibility issue that you may encounter. One additional "platform" that you may not have considered is the security and application compatibility restrictions that have introduced as part of the update Microsoft's Internet Explorer - IE7.

Chris Jackson (Microsoft compatibility SWAT team) has made a recent post on his blog (http://blogs.msdn.com/cjacks/) where he mentions how you can extract (more) useful data from the Internet Explorer Compatibility Evaluator - a key component of the Microsoft Application Compatibility Toolkit (ACT), version 5.

These ideas got me thinking about the IE7 compatibility question(s). More specifically,

1) Have new security restrictions been introduced?
2) What features and functionality are no longer available?
3) Are there recent Microsoft updates or patches that may cause an issue with IE7?
4) Are there any new compatibility issues that are specifically relevant to Windows Vista and Server 2008?

It does not take long to work through the IE 7 release notes, the accumulated IE7 support documentation and with a little help from friends who have deployed IE7 to highlight some of the potential security and compatibility issues including;

Deprecated API's
Does you application reference any API's or functionality from these groups?

• DirectAnimation
• Channel Definition Format (CDF)
• Gopher Protocol

Deprecated Features
Does your application rely on any of the following functionality?

• XBM Image format
• Telnet Protocol
• Gopher Protocol
• SSL Version 1.x
• Scriptlet MIME Types


IE7 Signed Controls
Internet Explorer 7 allows for ActiveX controls to be signed and therefore allow for greater privileges and access to local machine file system. Some intranet environments may require that all controls are now signed. To deploy to these environments, you need to ensure all of your ActiveX controls that rely on the IE engine are signed.

IE7 Safe for Scripting Controls
Managing ActiveX controls in an secure enterprise environment is a difficult balancing act. IE7 allows for an additional level of security with the CATID_SafeForScripting and the CATID_SafeForInitializing component category registry settings. These settings allow your IE7 applications to fully use the ActiveX scripting model

E 7 ActiveX Pre-Approved CLSID
Due to the increased security restrictions available in IE7, ActiveX objects (DLL's) may not install correctly due to lack of sufficient permissions. Adding the unique identifier of an ActiveX control to the pre-approved list of ActiveX controls will allow the application component to install successfully. As recommend in Microsoft's (ActiveX Security: Improvements and Best Practices - see references) you should not employ this option if;

- Your ActiveX control was not designed to use pages served from the Internet (as opposed to your intranet)
- Your ActiveX control is downloaded to the target machine
- Your control is solely intranet based (you should use Active Directory Group Policy objects instead)


I will post an update to this blog in a few days, as I will collate all of the security updates that relate to IE7 and add a patch/security update section to this posting.



References:

Microsoft IE7 Release Notes
http://msdn.microsoft.com/en-us/ie/aa740486.aspx

Security and Compatibility in Internet Explorer 7
http://msdn.microsoft.com/en-us/library/ms649488.aspx

Finding Security Compatibility Issues in Internet Explore
http://msdn.microsoft.com/en-us/library/bb250493.aspx

ActiveX Security: Improvements and Best Practices
http://msdn.microsoft.com/en-us/library/bb250471.aspx

Active Setup: Questions and Concerns

The Microsoft Active Setup feature is a start-up process within Windows XP (all service packs) and later OS's that automatically runs a specified process when a user logs in. This process usually is required to ensure that all relevant registry keys are configured for each user who logs onto that machine. This is required to complete an application installation process that due to the specific nature of the application may require individual, user-by-user configuration. In addition, Active Setup can be used as part of enterprise login procedures or to ensure that certain processes and configuration routines have successfully completed.

The Microsoft Active Setup feature employs the following registry keys to ensure that each local machine setting exactly matches the user components;

HKLM\Software\Microsoft\Active Setup\Installed Components\%APPNAME% and HKCU\Software\Microsoft\Active Setup\Installed Components\%APPNAME%

If the machine and the user portion of the registry do not match, then the designated process is run. Note: this process is run under the user security privileges so you need to ensure that process initiated by Active Setup does not require administrator rights to the local machine component of the registry or restricted areas on the local file-system.

Active Setup is commonly used when the application in question does not include advertised entry points (AEP), shortcuts or other triggers to complete the user based installation process.

I have few problems with Active Setup;

- Can you ensure that the user-based installation process completed successfully
- How does this affect enterprise level conflict management?
- Will all users have the correct privileges to run the local process
- Do I have full control of the process, once initiated in the user environment
- Is there any real/pragmatic dependency checking to ensure that Active Setup process initiates correctly?
- How are custom actions handled in the local cached MSI?


Loads of questions here, and I will try have a few thoughts on these issues over the next few weeks. That said, I would really appreciate any comments on this topic. Anymore concerns regarding Active Setup?


Here are some noted dangers to using Active Setup :
Active Setup can be a serious candidate (in security speak: an attach vector) for virus infections, malware and other "bad" things that make you work harder, sleep less, and generally suffer more.

There have been a number of security updates to the Microsoft Active Setup controls (which to be fair are now a little dated) but include;

MS00-042:
Microsoft has released a patch that eliminates a security vulnerability in an ActiveX control that ships with Microsoft® Internet Explorer. The vulnerability could be used to overwrite files on the computer of a user who visited a malicious web site operator's site.
http://www.microsoft.com/technet/security/bulletin/MS00-042.mspx


K-057: Microsoft "Active Setup Download" Vulnerability
The Microsoft Active Setup Control has an internal flaw which allows the downloading of a trusted ".cab" file to any disk location.
http://www.ciac.org/ciac/bulletins/k-057.shtml



References:
Wikipedia Citation
http://en.wikipedia.org/wiki/Active_Setup

App Deploy's Overview
http://www.appdeploy.com/articles/activesetup.asp

The Altiris Juice MSI Healing Article
http://juice.altiris.com/article/2514/a-guide-to-msi-healing#comment-8491

Etlen Engineering
http://www.etlengineering.com/installer/activesetup.txt

A brief overview of XP SP3

This is a little late in coming, but here is some details on the Windows XP Service Pack 3 update.

The collection of Microsoft updates that comprises the recently released Window XP Service Pack 3 (XPSP3) is a culmination of the following groups or "clusters" of updates including;

• A Microsoft Common Control Update (COMCTL)
• A roll-up of Windows Security updates
• A Microsoft middleware update (Microsoft XML)
• A collection of tested and approved Microsoft Hotfixes
• The revocation of 3 rarely used API calls (relating to DEP)
• A roll-up of a series of application updates that have been released since XP Service Pack 2

When referring to the potential impact on applications stability or installation, there are two primary factors to consider when considering the deployment of Microsoft's Windows XP Service Pack 3; likelihood and the impact of a particular issue.

After reviewing the compatibility and impact analysis results of just under 1000 application packages from a variety of sources and industries, we have developed the following views on each of the XP Service Pack 3 sub-groups or clusters;

1) Microsoft Common Control Update: This control has been included on the initial release of Windows XP and has a minor update. As this update has been included as part of an OS update, following installation best practices (and using MSI Installer packages) will respect the later versions of this control and so, this update should have minimal impact on application compatibility and stability.
2) The roll-up of several Microsoft Security updates (i.e. MS05-040, MS05-032) have been available for a number of years and all workstations with Microsoft Update enabled should have already received and installed these updates. The impact on application stability will be minimal as any problems should have been discovered many months ago.
3) As with the previous Microsoft control update, there has been an update to the core XML middleware layer. This update has also been available for a number of months and for the most part, most environments will have already deployed this update. This update should have minimal impact on application configuration and stability for most well-maintained and updated system.
4) As issues arise, Microsoft support teams will respond to specific application and operating systems issues with a specified update or "Hotfix". These Hotfix updates progress through the full Microsoft testing regime but may have been exposed to a limited number of customers for deployment. In this instance, these hotfixes may have a are and limited impact on application compatibility and stability.
5) As part of the Microsoft XP SP3 update, three DEP (memory handling API) calls have been deprecated and formal Microsoft support removed. The occurrence of applications that would employ these API calls would be rare and so it is expected that this update will have a very limited (very rare) potential for application stability.
6) As part of the OS update process, Microsoft has also updated an number of applications such as Outlook Express and the Shadow copy service. These updates have been included in recent Microsoft updates and organisations that have well-maintained and subscribed and deployed recent Microsoft updates should not experience any reduced application stability or compatibility.

To outline the likelihood and potential impact of the updates causing a stability or compatibility impact on a given application, the following table outlines the risk for each grouping included in Windows XP SP3.



In summary, it appears that the configuration and OS level changes included in Microsoft's Windows XP Service Pack 3 will have a limited impact on application stability and compatibility and given the many security updated and application updates included, it appears that XPSP3 should strongly considered for rapid deployment for most organisation.

Patch Tuesday - August 2008

ChangeBase AOK – Patch Tuesday Update
July 2008


As part of the July release of the regularly scheduled Microsoft Updates, there are currently eleven scheduled for release; six with the maximum rating of Critical and five with the maximum rating of Important.

Here is a brief summary of the patches that affect the Microsoft Windows operating system;

1) Microsoft Security Bulletin MS08-045
Description: Cumulative Security Update for Internet Explorer (953838). This security update resolves five privately reported vulnerabilities and one publicly disclosed vulnerability. All of the vulnerabilities could allow remote code execution if a user views a specially crafted Web page using Internet Explorer.

2) Microsoft Security Bulletin MS08-046
Description: Vulnerability in Microsoft Windows Image Colour Management System Could Allow Remote Code Execution (952954). This update resolves a privately reported vulnerability in the Microsoft Image Colour Management (ICM) system that could allow remote code execution in the context of the current user.

3) Microsoft Security Bulletin MS08-047
Description: Vulnerability in IPsec Policy Processing Could Allow Information Disclosure (953733). This update resolves a privately reported vulnerability in the way certain Windows Internet Protocol Security (IPsec) rules are applied.

4) Microsoft Security Bulletin MS08-048
Description: Vulnerability in IPsec Policy Processing Could Allow Information Disclosure (953733). This update resolves a privately reported vulnerability in the way certain Windows Internet Protocol Security (IPsec) rules are applied. This vulnerability could cause systems to ignore IPsec policies and transmit network traffic in clear text.

5) Microsoft Security Bulletin MS08-049
Description: Vulnerabilities in Event System Could Allow Remote Code Execution (950974). This update resolves two privately reported vulnerabilities in Microsoft Windows Event System that could allow remote code execution.

6) Microsoft Security Bulletin MS08-050
Description: Vulnerability in Windows Messenger Could Allow Information Disclosure (955702). This security update resolves a publicly reported vulnerability in supported versions of Windows Messenger. As a result of this vulnerability, scripting of an ActiveX control could allow information disclosure in the context of the logged-on user.

Note: These are not all of the patches that have been released by Microsoft today as the following only apply to Microsoft Office products;

• Microsoft Security Bulletin MS08-042
• Microsoft Security Bulletin MS08-041
• Microsoft Security Bulletin MS08-043
• Microsoft Security Bulletin MS08-051
• Microsoft Security Bulletin MS08-044

Using the ChangeBase AOK Workbench to analyse each of these patches against a sample of approximately 700 unique application packages with the intention of providing some insight into the following questions;

What patches when released are likely to cause my applications to fail?
What patches contain files and settings already included in my application portfolio?
What order should I test my applications?
What patches should I test most and why?

Results
The following table details the results from the ChangeBase AOK Patch Impact Analysis and includes information on what application packages in the sample portfolio;

What is the total number of applications affected by each patch?
What applications also include files and configuration data that were embedded in the patch update?
What applications had specific dependencies on changes includes in these updates



Special Notes:

• MS08-046 Security Update for Windows Server 2003 raised a specific driver issues with Fujitsu 4340 colour scanners (mscms.dll)
• MS08-048 Security Update for Windows Mail raised a specific DLL conflict with Microsoft Digital Image software
• MS08-050 Security Update for Windows XP raised an application conflict with Microsoft Messenger



Conclusion

From the results derived from the ChangeBase AOK Patch Impact Analysis, it appears that the following patch updates could be deployed with relatively light testing and with an expected minimal impact on the application portfolio; MS08-46, MS08-47, MS08-48, MS08-49 and MS08-50. However, the Microsoft Internet Explorer 7 Update IE7 (MS08-045) appears to cause application level conflict issues and has been raised a direct dependency for a number of applications. This could mean that these applications may be adversely affected by the MS08-045 update and this patch should be fully tested prior to deployment to production environments.

The Microsoft Compatiblity database - Dynamic Shims

I was doing some thinking about a central database of application compatibility shims. I have a couple of concerns regarding the implementation/deployment of these compatibility shims – but these may be more due to my ignorance rather than the limitations of the design/deployment of this compatibility technology.

First, is that the shim is “attached” to the application object and is not related to the user and second, I have found it hard to separate shims into “machine” shims and "user" shims; effectively separating changes to the target desktop or server environment based on machine or user privileges . This is important for deployment reasons and that we may not want to apply a particular shim to a particular user on a particular machine or a particular machine etc… you get the get the kind of matrix of deployment scenarios that one could encounter.

So, following along these lines, I wanted to move up the problem tree and start dealing with the compatibility problem on a larger (let’s call it Enterprise) level. Some of the things that I would require from an application compatibility framework/approach would include the following “pillars”;

- Leverage existing management approaches and technologies covering
- Deployment
- Reporting/Audit
- Updating/Removal
- Support for central management, remote access and disconnected use
- Support for machine, user, grouping and domain focused management
- Support for versioning, incremental updates and roll-backs

Using these pillars of Enterprise Compatibility Management, my thinking led me to use Active Directory as a central store for all compatibility settings. These GP objects would contain either the machine or the user appropriate settings for each app compatibility issue and would benefit from both GPO deployment and reporting technologies.

If this has not already be done, I think that we would probably not want to store all of the shim data in AD… we may need a translator that sits between the deployed AD registry settings and the local machine SDB database. Something like the following rough diagram ;



Using this approach we could deploy shims to the user, desktop, group or by domain. We could also determine what settings have been put in place and be able to audit the results. Also, no major technology needs to be created. We could use the existing SDB database (which incidentally gets recompiled every time a change is made anyway). We would require the creation of a Active Directory GPO2SDB converter and the WMI interface but that could done relatively easily now that the SDB API's have been made available on MSDN and their is an XML converter for viewing the contents of the SDB database.

The WMI interface would be required to interrogate the closed SDB database and enable auditing and reporting of the result SHIM changes to the local machine.

API calls that break applications

As mentioned in the Microsoft Compatibility tool-kit, the Developer cookbook and Microsoft Developer Network (MSDN - see references below) Safe Exception handling under Vista refers to the deprecation (end of support) for two API's under Vista, Windows 2003 and Windows Longhorn Server. These two API's (IsBadReadPtr and IsBadWritePtr)

relate to the handling of pointer to the global memory stack used by Windows.

These two API calls are used ensure that a particular pointer (or memory handle) is properly committed to the Windows Heap stack. Meaning that the code in question has not cased a corruption in the Windows swap file or memory stack. These two calls were intended for debugging purposes and known affectionately as "CrashMyApplication" and "CrashMyApplicationAndMyMemory" respectively as they had a very common habit of crashing an application under debug and trace conditions.

Microsoft has removed support for the two API's for security reasons and Windows Vista and Longhorn server will no longer support these API's. It is possible to determine if these calls are included in shipped software but unless the application is tested thoroughly and all functionality is tested, it is impossible to determine if these calls are actually employed and potentially could cause a compatibility issue. However, there is a rough an ready way to determine if these calls are actively employed in an application. If the application works under the following operating systems, then these calls are not being used;

· Windows 2K (all service packs)
· Windows XP SP1 and SP2
· Windows 2000 Advanced Server
· Windows 2003 Server

The IsBadReadPtr and isBadWritePtr API calls really translate to very old applications that related to Windows 9x and NT4 systems. If your applications are currently running normally (i.e. without frequent and continuous crashes) then your application is very unlikely to actively employ these (now deprecated) API calls.

Simply scanning an application for references to these API's would produce serious over-reporting without actually demonstrating that these calls are likely to be used in a production environment (i.e not a developer testing or debugging mode). As such, ChangeBASE does not currently scan for these deprecated API calls as part of the Platform Integrity analysis.

References:

IsBadReadPtr references can be found at;
http://msdn2.microsoft.com/En-US/library/aa366713.aspx

IsBadWritePtr references can be found at;
http://msdn2.microsoft.com/En-US/library/aa366716.aspx

Critical Section and Vista Compatibility

There have been a number of questions raised about why ChangeBASE currently does not analyze applications for Critical Section security issues. Referencing the Windows 3.1 Windows Logo certification program and Microsoft's developer handbook, "Critical Section" changes under Vista include the following recommendations;

"Developer Code should always;
Should always initialize critical sections.
Should not read into undocumented objects. Applications that read into the undocumented structures to assess the status of a critical section will most likely break if they are looking for uninitialized and freed critical sections.
Should prevent starvation. Applications that call Sleep while holding the critical section lock now can cause starvation for other threads that need the lock. Sleep calls should be placed after the LeaveCriticalSection call."

To analyze specific Critical Section thread synchronization references (i.e. InitializeCriticalSectionAndSpinCount or EnterCriticalSection ) you must be able to determine the process flow or the logic flow of the software under analysis. And to this, you must run the software and walk through the desired functionality. It is possible to examine file and COM object headers for these types of functions. However, this will generate a significant "over-reporting" issue without actually producing useful information on whether the identified Critical Section functions may cause a problem.

Given that, the impact of this issue is slightly reduced performance issues on multi-threaded applications and the probability of an adverse impact is extremely low, ChangeBASE is currently not including the Critical Section analysis in the Platform Integrity plugin pack.

Further Information on Critical Section code changes can be found at:
http://msdn2.microsoft.com/en-us/library/ms682530.aspx

The 6 Laws of AOK Compatibility

There is much in the news about Vista and migrating to Vista recently. Of prime concern is application compatibility which when simply put means getting applications to work on the target desktop or server environment. There is a lot of complexity in getting applications working - whether on Windows XP or Vista or the soon to be released Windows Server 2008.

And this is where I think there is some general confusion. Application compatibility is not simply about getting applications to function or work correctly on an Operating system such as Vista. Ensuring that application work correctly really means getting the application to work on the target platform and which involves the following;

1. Ensuring Operating System (e.g. Vista ) compatibility
2. Ensuring the availability of the complete and correct versions of middleware
3. Ensuring that applications do not conflict with each other (on install and un-install)
4. Ensuring that user environment is correctly setup and available

Breaking the application compatibility question into these four layers delivers a fundamental step change in the understanding and resolution of application compatibility issues. No longer can we just get one application to work on a desktop, we need to get several or even tens of applications to successfully install, update and un-install without breaking other applications. We now have large, complex and constantly changing middleware layers (Java, Crystal Reports, ODBC) that applications depend upon. Adding to the confusion, differing applications may require different versions of middleware components or worse, may ship from the software vendors with incomplete ("middleware fragments") dependencies which may allow the application in question to function but may prevent another application from working or even installing successfully. Viewing application compatibility with these four layers in mind requires a paradigm shift; to the Platform Integrity model which takes into account all of the requirements to successfully install, use and maintain applications.

To further this goal, AOK has developed the "AOK Laws of Application Compatibility" which include;

1. Enable the installation package to install successfully
2. Provide the application the required privileges and security access levels
3. Ensure that the required dependencies (middleware) are available and complete
4. Ensure that applications do not conflict with each other on installation, updating/patching or un-installation
5. Ensure that the user environment is correctly configured
6. Ensure that future changes/patches/updates do not adversely affect any of the four layers; the OS, the Middleware layer, Applications or the User Environment

When you follow these guidelines, your chances of successfully developing, deploying and maintaining your application portfolio are significantly increased; today and when dealing with future changes.