Win XP Mode - Cannot start virtual application. The application is blo

[MachoManRS]

Our office has an old program that we still need to use when upgrading our PC's to Windows 7. The program will run fine if you start a windows virtual PC and install and run it. However, based on the needs of our office, I need to be able to run Windows XP mode and simply have an icon for our users to click to take them to the application.



If I install the program in windows XP mode, and then add a shortcut to the file under all users/start menu, a shortcut is placed in the appropriate place on the windows 7 machine and I can copy that shortcut ot the desktop. The program runs fine until you restart the computer. Once you restart the computer and double click the link on the windows 7 desktop to the program running in windows XP mode, it says:



Cannot start virtual application. The application is blocked from running as a virtual application.



I read some other posts saying to put a new shortcut in the all users/start menu folder. This works, but only until our users restart their computer. The next time the computer is up, the problem happens again. This is not an acceptable solution to have to create a new shortcut for each workstation each time the computer is restarted.



Can anyone help me? I found some threads on various boards but none with solutions.



Thank you!

 

[itzdanielp]

This might be completely off the radar and unworkable...

But have you tried running in "Windows XP Compatability Mode" instead of the actual XP Mode?


(Right Click on the .exe, choose properties, select compatability tab, enable running in compatability mode)

 

[MachoManRS]

Yes, that doesn't work. The program must be loaded in a virtual environment. Thanks.

 

[itzdanielp]

Try removing Explorer from the registry exclusion list.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtual Machine\VPCVAppExcludeList

 

[MachoManRS]

Well I tried that and now something similar is happening, but not exactly the same. Instead of the specific error message posted earlier, upon opening the shortcut after a reboot, it loads the splash screen for the program and then a dialog box comes up wit a red encircled X and a box that says OK and that is the only option in the box. Not sure what to do at this point.

 

[MachoManRS]

I might should have explained this earlier, but I think it probably has something to do with the fact that the program being run on Windows XP mode is a program run from our old server. So the Windows XP mode program is run by being a shortcut to an executable file on the network, and then that program opens.

To explain better, I mapped a Z: drive on our windows 7 machine to our old server. The Windows XP mode sees this as Z on Rob-PC (Rob-PC is the name of the windows 7 machine). Then I create a shortcut in the all users/start menu folder to the executable file located in Z on Rob-PC.

Didn't know if this would help or not, but it might.

 

[howardp6]

If you are running from a shared file on a network server does each an every user have permission to access the network drive with their own ID and password and is it setup to automatically log them on. Your other alternative is to install the program in the virtual desktop for each machine.

 

[MachoManRS]

Yes each user has permission to access the network drive because that's how it was set up before we got windows 7 machines. Everybody in the office accessed the program and on the server and launched it. I can't install the program on each machine because installation does not work on Windows XP machines and the program is no longer supported by its maker. The program only runs if run from the server, but it has been performing flawlessly for the last 8 years or so on XP machines.

I did find something weird. If I copied a shortcut to the desktop of the virtual machine for the program from Z on Rob-PC the path looks like this \\tsclient\Z\program.exe

If I do this, when I reboot the computer, this shortcut no longer works and if I right click it, the path is greyed out and unchangeable. This is even though \\tsclient\z\program.exe is still the correct path. If I delete the shortcut and browse to the application, run it, then copy a shortcut to the desktop, the shortcut works again. It is the exact same shortcut.

However, if I create a .bat file as follows:

subst r: \\tsclient\z

This creates an r: drive on the virtual pc to the same path as the shortcut from earlier. However, if I put this .bat in the startup folder, when I reboot the virtual PC a shortcut to r:\program.exe works every single time. It doesn't get greyed out like \\tsclient\z did.

However, if I put a link to r:\program.exe in the all users/start menu folder and attempt to run it on windows 7 in xp mode through a link, the same thing happens as was happening earlier in my problems, it starts to load and then gives a red X and an "OK" in a box.

Can anyone make sense of this?

 

[itzdanielp]

What happens if you map to the network drive from XP instead of from 7?

 

[Rizlla]

Just another question. Do you run the program with admin privileges?
Did you also go into the security and select full control for all users?
Even if you are using an admin account some things will be blocked.

 

[MachoManRS]

itsdanielp - I cannot map directly from the XP machine to our server. The XP machine doesn't see any of the other computers on our network for some reason, except as they are seen through the Windows 7 OS.

For example, I can map a drive like this //tsclient/z/ but I cannot map a drive like this //actualserver/directory/

If I map a drive like //tsclient/z/ to drive q: the same thing happens upon restart of the computer. I get the same error.

Rizlla,

I am running the program as an administrator. Where do you mean to go into security and select full control? On the server? I do think it would be strange to need this when this has never been changed and it worked fine before.

 

[itzdanielp]

Are you running DHCP on your network?

Even though you have DNS, maybe the link isn't being sustained properly if the IP changes. Is it possible to switch to staticip?

 

[MachoManRS]

Hm, I will try a mini-setup where I put some of our boxes on a static IP tomorrow and see if that helps. Definitely worth a try.

Thanks.

 

[itzdanielp]

Yeah, sorry I can't help too much. Haven't encountered that problem, so I am coming up with stuff on the fly. Thinking out loud basically.

Hopefully that works

 

[MachoManRS]

Well thanks for the help guys. I didn't actually get it figured out, but I just revised our project to include the users having to manually launch xp mode and then double click a shortcut to a path created by a batch placed in the startup folder that reads "subst r: \\tsclient\z "

I was sick on fri-today so I lost several days and no longer have time to figure it out and must move forward. I may be able to revisit it later. Thanks for the tries!

 

[philellams]

Thanks for your experiences on this MachoManRS. I was having a similar problem running an old network-based DOS application, but adding to your attempts I was able to get a working solution.

As you noted, the problem seems to arise because the virtual XP machine loses contact with the application on the mapped network drive. The host machine then blocks the XP app from starting.

To cure the problem I added a batch file to the XP machine which begins by changing to the mapped network drive, thereby re-establishing the drive connection if it has dropped. The batch then calls the DOS exe on the mapped drive. The Host machine is happy because it can always see the batch file on the XP machine even during drop outs in the mapped drive connection (which typically happen during screen resizing).

Phil E

 

[tributary]

Well thanks for the help guys. I didn't actually get it figured out, but I just revised our project to include the users having to manually launch xp mode and then double click a shortcut to a path created by a batch placed in the startup folder that reads "subst r: \\tsclient\z "

I was sick on fri-today so I lost several days and no longer have time to figure it out and must move forward. I may be able to revisit it later. Thanks for the tries!

 

[tributary]

MachoMan, your answers suggestions were the most straight forward I have come acros and most similar to my situation. So I did wonder if you stayed the way you were or you did figure out how to have a short cut for your users so they don't have to think too much. I have been dreading the move to Windows 7. Had a shortcut that had the exe to the program followed by some parameters including a batch file, and can't get it to recognize it. Had this running since 1993 and on many versions of windows, so I am rusty on all the .BAT file stuff and it says it can't find (used to default to .BAT I believe if you did not specify an extention) Tried specifying RV.BAT instead of just RV in the parameters but then says can't find. You say you created a batch file, and not sure I even know how to do that anymore.

 

[yaretiree]

[Update: for whatever reason this approach stopped working. No idea why. Will update when/if I figure it out]

I ran into a similar problem running Win 7 Professional's XP Mode. I have an XP program and wanted its files located in Dropbox so that they could be automatically backed up and available in case XP needed to be installed (instead of within XP's virtual C: drive). I created a new XP mode hard drive, assigning to a file in Dropbox, then used XP's compmgmt.msc to initialize the drive and assign it a letter ( E: ).

I installed the program in E:\<pgm dir> (it's old, both data and program reside in the same directory).

It all worked fine when I started the application from within the XP virtual machine, but then I got the "The application is blocked ..." message when I tried to start it as an application. This thread got me thinking about permissions. In XP I changed E: to have network sharing, full permissions, and got the same message. I then changed E:\<pgm dir> to have network sharing, full permissions, and everything works fine.