Launching reg / bat / cmd / vbs files in App-V 5

App-V 5 behaves a little differently to App-V 4 when it comes to launching files with different file extensions.  For instance, if you have a shortcut pointing to a PDF file, in App-V 4 this could prove a problem if Adobe Reader was already running since it would pass the command onto the already running instance asking it to open a file in the virtual environment that it could not see.  This is no longer a problem in App-V 5 since the shortcut points directly to a PDF file under C:\ProgramData which Adobe can open since the location is always visible.

I had the pleasure of sequencing an application recently that had start menu shortcuts to .reg files to configure the application in different ways.  When launching these .reg files, the registry settings were applied locally, outside of the virtual environment, which were then hidden from the application due to the main keys being set to override.  The solution to this was to point the shortcuts to reg.exe import <Path to reg file> instead.  But then I had to do a couple of tests to satisfy my curiosity to see what would happen with batch files and vbscripts!

I created a .bat, .cmd and .vbs file that each created a registry key under HKCU and added them to a sequence.  A point of note is that the vbscript uses the RegRead method, since the WMI method will always write outside of the bubble anyway due to the WMI Windows service being run outside of App-V.


reg add HKCU\Software\Test /v Test.bat /d Success /f


reg add HKCU\Software\Test /v Test.cmd /d Success /f


Set wshShell = CreateObject("WScript.Shell")
wshShell.RegWrite "HKCU\Software\Test\Test.vbs", "Success", "REG_SZ"

The result was that the .bat and .cmd wrote the registry keys outside of the virtual environment, whereas the .vbs file wrote the registry entry inside the virtual environment as desired.

To workaround this you can change the shortcut to run cmd.exe /c <Path to batch file>.  I don’t know why .vbs behaves differently and we don’t have to resort to using wscript.exe <Path to script file>, but nobody ever said that any of this would make any sense!

4 responses on “Launching reg / bat / cmd / vbs files in App-V 5

  1. Dan,

    Internal commands to the cmd processor do not produce a new process, while external commands do. You should have the same behavior with other internal cmds like move, copy, etc… If you ran a .reg file (which would launch regedit.exe process), it probably would have worked inside the VE.

    That explains shortcuts that point to reg as a target, but not when the target is a cmd/bat file. It also explains vbs since that is an external cmd. I am surprised by cmd/bat file behavior, although I have seen this happen and worked around it the same way you did without bothering to think about why I had to do it.

    Thanks for posting this.

    1. Here’s how I see it – If you launch a file with a non-exe file extension, it gets passed to Windows to open it up with whatever application is registered to open it. So a .reg file triggers regedit.exe and a .cmd file triggers cmd.exe, both of which happen outside of the VE. For some reason though, .vbs files trigger wscript.exe inside the VE. The App-V client is continually monitoring all process launches to see whether or not they should be virtualised so that you can start a virtual application just by running it’s executable from its location. I assume that the App-V client is designed to intercept the launching of .exe and .vbs files but not batch files or any other file types.

  2. msitekkie

    Tim, i’m a little bit confused by your reply. You say If you ran a .reg file (which would launch regedit.exe process), it probably would have worked inside the VE. But that sounds like just what Dan did. He had shortcuts to .reg files that will have invoked Regedit.
    Interesting point about internal commands vs external commands though with external commands requiring cmd.exe whereas internal commands don’t. Without DOS experience you probably wouldn’t think of that.

    1. I don’t think there’s any relevance whether or not the batch file you run contains internal or external commands. What matters is if the host cmd.exe that gets spawned to run the batch file is started inside or outside of the virtual environment. Once it’s started running, any internal commands or child process created by external commands would continue to run in the same mode as the parent cmd.exe; either virtualised, or not.

Leave a Reply