A blog with focus on experiences with the Windows Client operating systems…
RSS icon Email icon Home icon

  • Checking Win32 application runtime dependencies in Windows 10

    Posted on March 17th, 2017 By Andreas Stenhall + No comments

    There are new WMI classes in Windows 10 that can be used to collect software inventory. The information can be displayed using PowerShell. Also, there is a feature that inventories what framework or runtime an application is dependent on, for instance which version of .NET Framework or Visual C++ Runtime and it can even see if there are dependencies for OpenSSL. Imagine having these feature in place when the HeartBleed bug appeared a few years ago.

    Display all installed applications on a Windows 10 machine:

    Get-WMIObject Win32_Installedwin32Program | select Name, Version, ProgramID | out-GridView

    Display all apps and dependent frameworks on a Windows 10 machine for a specific application (replace the ProgramID in the filter section with another one from the above example), and make sure everything is on one row:

    Get-WMIObject Win32_InstalledProgramFramework -Filter "ProgramID = '00000b9c648fd31856f33503b3647b005e740000ffff'" | select ProgramID, FrameworkName, FrameworkVersion | out-GridView

    or to bake them together to get both the application name and associated frameworks:

    $Programs = Get-WMIObject Win32_InstalledWin32Program | select Name,ProgramID
    $result = foreach ($Program in $Programs) {
    $ProgramID = $program.programID
    $Name = $program.Name
    $FMapp = Get-WMIObject Win32_InstalledProgramFramework -Filter "ProgramID = '$programID'"
    foreach ($FM in $FMapp) {
    $out = new-object psobject
    $out | add-member noteproperty Name $name
    $out | add-member noteproperty ProgramID $ProgramID
    $out | add-member noteproperty FrameworkPublisher $FM.FrameworkPublisher
    $out | add-member noteproperty FrameworkName $FM.FrameworkName
    $out | add-member noteproperty FrameworkVersion $FM.FrameworkVersion
    $out
    }
    }
    $result | out-gridView

    Now, happy hunting for runtime dependencies!

  • Dependencies when app compat testing in Windows 7

    Posted on May 12th, 2011 By Andreas Stenhall + No comments

    When testing application compatibility when moving to Windows 7 you can use ACT (Application Compatibility Toolkit) and the tools in there to test and fix applications. Another tool that you can use to learn about dependencies when compatibility testing your applications is a tool called Dependency Walker.

    With this tool you basically open a system file, for instance a DLL or an OCX file, and it will list its dependencies to other files on the system. This can be good for finding what is causing registration of for instance DLL or OCX files to fail on Windows 7 while it works fine on Windows XP. There can be runtimes missing.

  • HOW TO: Find 16-bit applications in your ACT inventory

    Posted on April 14th, 2011 By Andreas Stenhall + 2 comments

    When companies deploy Windows 7 most of them are looking at the 64-bit version of Windows 7. This architecture of Windows does not support running 16-bit applications, which unfortunately still is widely in use. If you do an inventory with ACT (Application Compatibility Toolkit) it will inventory all executables as well as CMD files and some other stuff and it will contain information about 16-bit applications lying around and being used by the users in your business.

    The trick is that the GUI does not provide a way to view these applications so you have to turn to doing a SQL query using for instance the SQL Management Studio Express tools. Use the SQL Query below to get information on any none 32- or 64-bit executable. The query (thanks to Chris Jackson) will return for instance WOW (Windows on Windows) or DOS applications and that will/might indicate a 16-bit app which you should prioritize to test and handle as necessary.

    USE ACTDATABASE
    GO

    SELECT DISTINCT Applications.appName, Static_App_Properties.fileName, fileModuleType

    FROM Static_App_Properties
    INNER JOIN Application_Instance_Files
    ON Static_App_Properties.identity_hash = Application_Instance_Files.filePropertyID
    INNER JOIN Applications
    ON Application_Instance_Files.appID = Applications.identity_hash

    WHERE fileModuleType<>'32BIT' AND fileModuleType<>'64BIT' AND propertyType='File'

    ORDER BY appName
    GO

    Happy hunting for 16-bit applications! :)

  • Look at the application to manifest to see the requested execution level

    Posted on August 31st, 2010 By Andreas Stenhall + No comments

    Yesterday I blogged about the classic shim for suppressing the UAC prompt for certain applications. To determine why an application requests an UAC prompt you can look at the application manifest, if it has one at all. The handy little tool ManifestView lets you load an EXE file and see which requested execution level the developers have set for it.

    If you should find the requested execution level to be set to something you do not like, for instance “runAsAdministrator” when what you actually want to do is to run is as a standard user, you can apply a shim to the EXE file to solve that problem. Be aware that most of the times the higher execution level is set for a reason but that does not mean you can still fix the problem, sometimes by modifying file and registry permissions for instance.

  • Classic shimming tip for forcing apps to run without UAC prompting

    Posted on August 30th, 2010 By Andreas Stenhall + No comments

    If you during your way in testing app compatibility with Windows 7 encounter an application that require a UAC prompt to launch you can suppress this UAC prompt by creating a more or less classic shim “RunAsInvoker”. A few years ago Microsoft posted this as a KB article but not long after it vanished. Now the guide for creating this shim is available in Ask The Performance Team blog and I strongly suggest you put this shimming tip in mind because it might come in handy when you least expect it.

  • ACT 5.6 released – many improvements

    Posted on June 14th, 2010 By Andreas Stenhall + No comments

    Being at TechEd in North America last week it seems that ACT 5.6 was released on Monday last week. Among the improvements are tools for migrating to the 64-bit platform, including a 64-bit version of the Compatibility Administrator.

    The assessment overview is something that also has been improved and I strongly recommend you to download and intall this tool if you are making an inventory for upgrading to Windows 7.

    Download at MS Download Center.

  • Custom commands when deploying Windows 7

    Posted on April 5th, 2010 By Andreas Stenhall + No comments

    I got a question the other day on a problem where a person is installing a set of applications during deployment of Windows 7, using MDT 2010. The problem is that one application requires to be run in Vista compatibility mode before it can even be installed, most likely due to a check in the installer for which Windows version is being used, a rather common compatibility issue.

    One solution to this is to use Compatibility Administrator which is a part of ACT to create a so called “shim” which makes the installation go through, fooling the application that the OS is Windows Vista even though it is Windows 7. But, how do we get the shim applied during our deployment, which we want to automatic?

    It is rather simple, just add a “run custom command” in the task sequence before the application is installed, which applies the compatibility shim to the machine, making the installation run through. Also note that you can run custom commands in the “applications” section in MDT2010, just add the command line to the path field and off you go!

  • Drivers for old Soundblaster cards in Windows 7 and Windows Vista

    Posted on June 22nd, 2009 By Andreas Stenhall + 3 comments

    A problem when Windows Vista was released some years ago was the fact that Creative wasn’t too “creative” to create drivers for older Soundblaster cards. This is where the kX Project comes in as it provides drivers for most older Soundblaster audio cards in newer operating systems.

    But why on earth do I mention this now that Vista has ben out for a few years? Well the reason is that I’ve heard of users (some of which totally skipped Vista) that are testing Windows 7 on older machines and does not find a driver for their Creative Soundblaster audio card.

    If you are looking for a Windows Vista och Windows 7 driver for your Soundblaster range of audio card go to http://www.kxproject.com.

    EDIT: URL updated.

  • Fool a web site into thinking you are another browser or OS

    Posted on June 8th, 2009 By Andreas Stenhall + No comments

    Some time ago I wanted to see a soccer game via Canal Digitals web service but as I am running Windows 7 on my Media Center connected to my TV the web service discovered this and did not let me play this using Windows Media Player and instead offered me to view it in Flash format. Viewing the game in Flash format really wasn’t the best in quality and as I and my co-watchers discovered the game was more or less unwatchable.

    In halftime I had the time to do the necessary corrections to fool the web service into presenting itself as another operating system and Internet Explorer version. This made the Windows Media stream instantly and not to mention with much better quality. This is done easilty by changing the so called user agent string which is a string which presents certain information such as OS, web browser and version and some more info.

    If you want to change the user agent string and fool a web site or service into thinking it is something it is not you can do this using one of the registry fixes found at http://www.enhanceie.com/ua.aspx.

  • What does a Windows 7 logo’ed application really mean?

    Posted on June 3rd, 2009 By Andreas Stenhall + No comments

    Now that Windows 7 RTM is closing in and it has been announced that Windows 7 will be available to partners as early as late July I thought I’d share a few facts about what an application being certified for Windows 7 really mean. For software developers to receive the “Windows 7” logo it must pass certain required tests. The certification process include for example the following requirements:

    • No installation blocks. One common problem is that software developers check which operating system the application is trying to be installed on which causes an application to not install on the latest operating system. For an app to become certified there must be no such blocks.
    • Remote Desktop Services environment. All apps must work in a multi user environment such as Remote Desktop Services (former Terminal Services) or when multiple users are logged on locally on a client machine.
    • Handling crash data. The developers must actively participate and handle application crash data that is sent to Microsoft via the built in application error reporting in Windows. For instance if an application carrying the “compatible with Windows 7 “ logo is discovered to cause more than 20 percent of crashes the developers have 30-90 days to present a plan to fix the problem(s), or the logo is revoked. 
    • Installation and uninstallation. Applications must install cleanly to standard locations in the file system and it must be possible to uninstall the application. 
    • Support for 64-bit platform. Applications that receive the logo must fully work on 64-bit version of Windows 7, either natively or by using WoW64.

    That is just a few requirements that an application must pass before it gets the “Compatible with Windows 7“ logo. More information can be found at https://connect.microsoft.com/site/sitehome.aspx?SiteID=831