Application Virtualization Explorer

Kalle Saunamäki is a reallly deep dive kind of guy. He knows a lot about the App-V 4 filesystem, the App-V 4 client and now he is digesting the App-V 5 client.


How does one notice this? Well, he is the creator of the most amazing App-V 4 / 5 editing tool. Anyone doing any type of packaging for App-V needs this tool.


Have you previously tried converting packages from App-V 4 to App-V 5? Seems really as the process is the following;

  1. Install the sequencer on a dedicated VM
  2. Run PowerShell cmdlets to spit out a new package
  3. Open the package to, and save the package again to get all new virtual extensions.

AVE does this in a much faster and easier way. Simply choose to Import the 4.X package, and then save it as a brand new package. This can happen on any workstation you are using, even if you have the App-V client installed!


Whats in my package?

Have you wondered exactly what a package contains? As the sequencer only reveals the VFS and registry (and sometimes the shortcuts and FTAs), quite often you resort to reading the DynamicConfig-files that are produced in XML – after you save the package. And even when reading the XML-files trying to understand what will get published on a client – there are quite a few entries missing (shell extensions and browser plugins as a sample).image

AVE will immediately make this visible and more to that!


How about this great feature! Did a service you captured get left out? You can import it and directly insert into the package;


App-v and wisptis.exe

Some applications that are virtualized with App-V 5 have caused issues with wisptis.exe –  a process to handle the input of pen-enabled devices. image


When an application that uses a .NET Framework(WPF, silverlight, SCOM / SCCM console, App-V UI etc) 4.5.2 is virtualized on any version of the App-V 5 client there is severe mouse-lag or hang.

Reproduce the issue

Connect a device which uses the Tablet Input service – most commonly Wacom-devices. Any WPF application based on .NET Framework 4.5.2 can cause the issue – for example using Chrome to access Outlook Web Access and then pressing “New message” (will use Silverlight) to generate a new email will spawn the wisptis.exe. The mouse freezes. If the process (wisptis.exe) is terminated mouse responsive will return to normal. The below is the process start of wisptis.exe

Process 5836 starting at 000000013F5AD9C8 C:\Windows\System32\wisptis.exe 11:24:08.939: [6388/6532] NtTerminateProcess( ProcessHandle=0x4f8, ExitStatus=0xc000042c ) => 0

The attempt to start this process fails with an STATUS_ELEVATION_REQUIRED code.

(credits to Paul Richards for the above info)

Public Workarounds

It seems that reverting back to .NET 4.5.1 has resolved the issue for quite a few people. If your application actually requires the .NET Framework 4.5.2 version that is of no use as a workaround. Installing the below hotfix may improve the issue aswell, however the successrate so far is low;

Mouse drawing is displayed incorrectly when the screen resolution is restored after a full-screen application stops on a Windows 7-based computer that has a multitouch screen installed

(while you are at it – apply this one aswell: Tablet PC Input Panel cannot be moved after you install update 2973201 in Windows 7 or Windows Vista )

Obvious workarounds

WISPTIS.exe is a process to handle the pen input, and therefore we can reduce our impact by completely disabling the the functionality. The policy can be find under;

User Configuration – Administrative Templates – Windows Components – Tablet PC – Cursor image

You can also disable it as a service (applicable on Windows 7 – named “Touch Keyboard and Handwriting Panel Service” for Windows 8): image

I haven’t personally confirmed this and so far this seems extremely intrusive as it completely disables the functionality for all applications.

Community discussed workarounds

WPF uses an interface, documented on MSDN, to determine if this is a tablet / touch enabled device. If you, inside the App-V 5 package while sequencing, edit the following registry key;


Change the default value (to something else), and then set it to Override Local. image

This obviously breaks the input functionality, however only for the virtualized application.

(Thanks Paul Richards for the above suggestion – brilliant in so many ways)

Microsoft Support Solution – 2014-10-15

This is the Microsoft suggested solution. Apparently App-V makes an attempt to start a second process, and therefore the lag is experienced. Create the following registry key on the App-V client machine. Location:“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Subsystem\ObjExclusions” Type:       Reg_SZ
Name:     93
Value:     {773F1B9A-35B9-4E95-83A0-A210F2DE3B37}-running

The number 93 is used in this because 93 is the first available number in a default installation. This might be higher if your installation has more object exclusions.

Thanks Paul Richards for the update

Long-term resolution

Report it to Microsoft. There is a bug file on Connect that seems to have an open discussion, and there is a pending support case with Microsoft that is awaiting the long term solution.

Interesting topic

If you are a heavy user of Wacom hardware – see this guide of Vizibler that hopefully can improve your situation.

WMI Hotfixes for Windows 7 x64

You cannot overwrite an exported event log file by using the Wevtutil.exe tool in Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012
Files Updated:

Profile loading takes a long time due to full DFS namespace sync with PDC

Files Updated:


Not applicable

Not applicable

High memory usage by the Svchost.exe process after you install Windows Management Framework 3.0 on a Windows-based computer
Files Updated:










An update that prevents a “0xC0000034″ error message when you try to install Windows 7 SP1, Windows Server 2008 R2 SP1, or Windows Embedded Standard 7 SP1 is available
Alot of files are updated

Forwarded events cannot be displayed in Event Viewer on a Windows 7 or Windows Server 2008 R2-based computer
Files Updated:

Wmiprvse.exe process crashes when you run a WMI script on a computer that is running Windows 7 or Windows Server 2008 R2
Files Updated:

Unexpectedly slow startup or logon process in Windows Server 2008 R2 or in Windows 7
Files Updated:

An application or service that queries information about a failover cluster by using the WMI provider may experience low performance or a time-out exception
Files Updated:


Not Applicable

Not Applicable

Windows Installer Source Management

As part of ensuring that installations work “OK” if initiating a repair regardless of how many servers are terminated or ConfigMgr caches are deleted – here comes a summary of the feature.

Whats the purpose of this feature?

To ensure that the source-files for any MSI-based installation is available, even if they are removed from ConfigMgr cache or a single / multiple DPs are terminated.

How do you use this feature?

For each deployment type, you can configure the ProductCode that ConfigMgr will track;


Select the MSI-file part of the source-files by clicking Browse (the one in the red square). The file you select should (as you might guess…) be part of the deployment types content.

I realize that some installers are less than ideal for this feature. Any standard MSI will work out of the box, however if the MSI is embedded within an executable, or if the installation is multiple MSIs – this feature may not be a perfect fit. You can of course test it, or bring it up for discussion with everyone.

What happens at the client, when I do this?

Any client which has the software made available / forced to it will have the source updated on the fly. You can trigger the action to update the source-location manually by using this action;


The source-location to the closest DP will be appended to the Source-list for any managed application. Do note that nothing is changed in Net and Media. Only URL is appended. Original source-location will be intact – regardless if files are still there or not.


How do I troubleshoot this?

All actions are logged here;


Sample output;

Adding install source C:\WINDOWS\ccmcache\5d\ to source list for product {1AD1DCA6-73FE-4803-858C-3441DF875BC1}            SrcUpdateMgr   2014-05-01 23:01:38       5944 (0x1738)

UpdateURLWithTransportSettings(): OLD URL – http://server/sms_dp_smspkg$/content_b0bd89d3-1cfb-4348-97bf-590f75672d0c.1            SrcUpdateMgr   2014-05-01 23:01:38       5944 (0x1738)

UpdateURLWithTransportSettings(): NEW URL – http://SERVER/sms_dp_smspkg$/content_b0bd89d3-1cfb-4348-97bf-590f75672d0c.1            SrcUpdateMgr   2014-05-01 23:01:38       5944 (0x1738)

Added source http://server/sms_dp_smspkg$/content_b0bd89d3-1cfb-4348-97bf-590f75672d0c.1 from local dps to source list for product {1AD1DCA6-73FE-4803-858C-3441DF875BC1}   SrcUpdateMgr   2014-05-01 23:01:38            5944 (0x1738)

UpdateURLWithTransportSettings(): OLD URLhttp://server/sms_dp_smspkg$/content_b0bd89d3-1cfb-4348-97bf-590f75672d0c.1            SrcUpdateMgr   2014-05-01 23:01:38       5944 (0x1738)

UpdateURLWithTransportSettings(): NEW URLhttp://server/sms_dp_smspkg$/content_b0bd89d3-1cfb-4348-97bf-590f75672d0c.1            SrcUpdateMgr   2014-05-01 23:01:38       5944 (0x1738)

Added source http://SERVER/sms_dp_smspkg$/content_b0bd89d3-1cfb-4348-97bf-590f75672d0c.1 from local dps to source list for product {1AD1DCA6-73FE-4803-858C-3441DF875BC1}   SrcUpdateMgr   2014-05-01 23:01:38            5944 (0x1738)

Successfully updated source list for product {1AD1DCA6-73FE-4803-858C-3441DF875BC1}         SrcUpdateMgr   2014-05-01 23:01:38            5944 (0x1738)


Ensure that the software is available for the device.
Pre-requisites for Windows 7 (pre-SP1) clients; KB2619572

The following registry key:

Name: WinHttpAutoLogonLevel
Type: REG_SZ
Value: L

Never ending reboot prompts

A few servers had continue to request, through the ConfigMgr, a reboot after the servers were, surprise, rebooted due to Windows Updates.

Use the below PS code you can see the current state of the reboot.

Invoke-WmiMethod -Namespace “ROOT\ccm\ClientSDK” -Class CCM_ClientUtilities -Name DetermineIfRebootPending -ComputerName <name>

Obviously, before actually doing any of the below suggestions – a restart should before forced on the client. On the servers in question, a minimum of one reboot per server has been confirmed before using this workaround.

The WMI method apparently only retrieves the current value of the ConfigMgr-client. To change the state of the WMI method –  one has to digest the registry a bit;


The current state is saved in HKLM\Software\Microsoft\SMS\Mobile Client\Reboot Management\RebootData

On a server rename it to old, and then restarted the CCMEXEC-service.

To confirm that a request for a reboot you can either await the GUI initialization, or use the above PS code to verify the pending reboot state.

All Reboot requests are logged in RebootCoordinator.log in the ConfigMgr client log-folder.

Some interest articles;

ConfigMgr Client installation failure

Two odd failures from the ConfigMgr client that caused some headaches.

StatusAgentProxy.dll fails to register.

Verify that MSVCR100.DLL in c:\windows\system32 (yes, on a 64-bit system aswell) is the correct size.The renamed file (MSVCR100old.dll) shows the size of 755kb – which most likely is installed by a 3-party application and in error replaced the correct version of the file. As you can see, both files have the same version number.



CcmRegisterPerfCounter fails with an unexpected error.

The custom action is intended to register the Performance Counters for ConfigMgr client. Basically it needs two files in c:\windows\system32 (ccmframework.h and ccmframework.ini), a few registry keys and then it can set it up. Performance Counters seems to be very stable so only a 3-party application can actually cause any havoc here. To resolve this perform the following;

Open MSCONFIG. Select the Startup-tab and click disable all.


Select the Services-tab. Select to hide all Microsoft-services and then click the Disable all.


Restart the computer, and verify that the installation will complete.

Sequence Ecowin Pro 6

This is a repost of an old-blog article. This still applies to App-V 5.0, and as far as I remember – this content is not published anywhere else.

Since about 2009 and when I first replied to a thread regarding a “common” issue with sequencing a specific software named Ecowin Pro 6, a more or less active pursuit of finding a resolution has been ongoing.

Back in November 2009 Tim Mangan was over having a training session with us and I brought up the issue. Just about the same time the App-v 4.6 RC2 client was released to public and I posted the thread as a bug and got a response. Unfortunately the only response anyone gave was; Yes, its a problem.

Currently a bit jetlagged and trying to convert back normal hours (US v SE). I decided to stay up (landed about 7am and wanted nothing else than to sleep) to revert back the clock to normal – what better task than the above unsolved mystery?

After about 3 hours of various failed attempts and loads of reading among various articles that hopefully would give a hint – something came up. A guy named Jochen had described a solution to making SidebySide local (meaning placing them in the same folder as the application). As the error was similar and related to SxS (see below) a trial has to be made to see if this could possible be the solution. Below is a note from what the Application log showed when attempting to start Ecowin Pro as an app-v package.

Log Name:      Application
Source:        SideBySide
Level:         Error
Keywords:      Classic
Activation context generation failed for “Q:\ecowin.002\VFS\CSIDL_PROGRAM_FILES\EcoWin\EcoWin.exe”. Dependent Assembly Vinga.vscom90u,processorArchitecture=”X86“,publicKeyToken=”e520fe831c9439c8“,type=”Win32“,version=”” could not be found. Please use sxstrace.exe for detailed diagnosis.

Jochens approach was to place the needed DLL-file and two manifests referencing it within the same folder as the application.
As I am not a programmer and specifically not the programmer any recompiling was not in question. From my understanding the manifest first created told the executable that it needed an assembly and the second manifest defined where to locate the DLL.

So, first manifest to tell Ecowin where it should get its above Vinga.vscom90u (named ecowin.exe.manifest)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
<assemblyIdentity type="<strong>win32</strong>" name="<strong>Vinga.vscom90u</strong>" version="<strong></strong>" processorArchitecture="<strong>x86</strong>"></assemblyIdentity>

The second manifest telling Ecowin where VScom90u.dll was (named Vinga.vscom90u.manifest)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<noInheritable />
<assemblyIdentity type="<strong>win32</strong>" name="<strong>Vinga.vscom90u</strong>" publicKeyToken="<strong>e520fe831c9439c8</strong>" version="<strong></strong>" processorArchitecture="<strong>x86</strong>" />
<file name="<strong>vscom90u.dll</strong>" />

The version, name, type, processorArchitecture, publicKeyToken are all picked up from the original error message. Cross-referencing those with what is captured within the package the following file was located – the folder named contains the file, the version, the processer architecture and that seems to fit pretty good (and the file name seems to ring a bell..)


That file was now copied from its original folder to the same folder as the manifests and the Ecowin.exe

Wrapping up my project and deploying it to the client gave me some hope as a splash-screen showed up – only to reveal the next error message;

<lost screenshot>

For some reason the following registry key came to mind;

<lost screenshot>

Apparently the software notes what operating system it was installed on – just altering the above to (601) gave a new error message;

<lost screenshot>

Extracting the detailed message the following shows

06/28/10 15:36:38 Class not registered [VSCoCreateInstance(progid=EWDBINET2.MtickSeriesListInet2,clsid={EB702F7B-DF8E-4E4D-AE7D-BCC0E48E7105},iid={00000000-0000-0000-C000-000000000046}),CMTickApp::CheckDefaultDB]

So – something is wrong with the datasource specified. Reviewing a process monitor log a reference can be found

<lost screenshot>

Not really knowing the application – this is where some insightful answers would be needed. The error is very application specific and what relevance it has (or not) could perhaps be guessed from the 136 000 process monitor log seen above or simply asked to an application expert.

If anyone cares to explain the above to me – it would be greatly appreciated. I figured out a workaround using some experience, wild guessing and lots of reading.

Visual Studio 2013 silent install

Visual Studio 2013 is now available through Microsoft Volume Licensing Website, and can also be downloaded through Developer Network.

Directly from the Visual Studio-website you can find all editions with the latest Update 3 slipstreamed into a single media, however if you visit the Microsoft Volume Licensing Website there is only the RTM version of Visual Studio 2013 available. The major difference between the Visual Studio-website and the MVLS-website is that the license is embedded within the downloaded media you retrieve from MVLS. The files available from Visual Studio-website is a 90-day trial version. If you press the Key-option at MVLS no product key is presented to you.

So, if you want to deploy Visual Studio 2013 with the latest (or any) update? Do the following!

Downloaded Visual Studio 2013. Technically we are not interested in the bits, but when the download is started a product key is generated with the download link

Downloaded the latest ISO-file from the edition of Visual Studio 2013 (Professional perhaps?)


Once the ISO-files is downloaded (weighs in at about 6gb), extract the file.

Do not read the guide from Developer Network on howto deploy Visual Studio in an unattended manner (well, ok – if you really want to). Instead start the vs_<edition>.exe file with a question mark. Like this

vs_professional.exe /? 

The following output is generated;

Setup - Usage

This setup supports the following switches:

/Help              Display this usage text.

/Quiet             Quiet mode with no display and no user interaction.

/Passive           Display progress but do not wait for user input.

/PromptRestart     Prompt the user before restarting the system.

/NoRestart         Do not restart during or after installation.

/ForceRestart      Always restart the system after installation.

/Log               <filename> Specifies a location for the log file.

/Uninstall         Uninstall the product.

/Uninstall /Force  Uninstall the product and features shared with other
/U /Force          Warning: using this switch may cause other products i
nstalled on this machine to stop functioning properly.

/Repair            Repair the product.

/Layout            Create a copy of the media in specified folder.

/NoRefresh         Prevent setup checking for updates from the internet.

/NoWeb             Prevent setup downloading from the internet.

/Full              Install all product features.

/AdminFile         <filename> Specifies the installation control file.

/AddRemoveFeatures Choose which features to add or remove from the insta
lled product.

/CustomInstallPath <path>
Set Custom install location

/ProductKey        <25-character product key>
Set custom product key (no dashes)

For more information see <a href=""></a>

A sample command-line for silent install would be;

vs_professional.exe /Q /S /LOG %SYSTEMROOT%\TEMP\VS_2013_U3.log /NoWeb /NoRefresh /Full /ProductKey XXXX-XXXX-XXXX-XXX
1 2 3 15