Home Dashboard Directory Help
Search

Visual Studio 2012 - Unable to start program error when debuging website on Win8 & IE10 by JCorker


Status: 

Closed


90
0
Sign in
to vote
Type: Bug
ID: 758876
Opened: 8/21/2012 4:44:03 AM
Access Restriction: Public
10
Workaround(s)
view
45
User(s) can reproduce this bug

Description

When trying to run either our existing website or a new one in VS2012 & Win8, we get an error "Unable to start program 'http://localhost:port/page.aspx'. The system cannot find the file specified.
The website is at that url if I type it into the browser the page loads, also if I don't press F5 but select "Browse With" and pick IE the website loads ok. Switching the default browser to Chrome is also a workaround for now.
Details
Sign in to post a comment.
Posted by Microsoft on 4/29/2014 at 12:32 PM
Thank you for reporting this issue. This issue has been fixed in Visual Studio 2013. You can install a trial version of Visual Studio 2013 with the fix from: http://go.microsoft.com/?linkid=9832436
Posted by ThunderHelper on 7/30/2013 at 2:43 PM
Disregard the previous comment it was submitted inadvertently.
Posted by ThunderHelper on 7/30/2013 at 2:42 PM
I'm having the same problem. IE10, Win8, VS2012.
Posted by Microsoft on 7/19/2013 at 10:11 AM
Hi, ThunderHelper, please make sure you windows 8 has the latest update, since this is supposed to be fixed with IE10's update a few month ago. If it still doesn't work, please log a new connect bug and mention this. Thanks!
Xinyang Qiu
Web Platform and Tools team
Posted by ThunderHelper on 7/19/2013 at 10:06 AM
Is there an update or patch that fixes this problem?

I am seeing this problem with Win 8 and VS 2012 Update 3 after moving to a new computer. The following work around DID work. Our company forces the home drive to Z:.

Set HOMEDRIVE variable before starting Visual Studio, for example from a batch file:
SET HOMEDRIVE=C:
CD C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\
start devenv.exe
Posted by Microsoft on 4/9/2013 at 7:18 PM
Hi, DaveAce, I don't think you are having the same "homedrive" problem as I couldn't repro it with the original repro on win7+VS2010+IE10. Also, this issue has been closed. Please log another connect problem with detailed information. Thanks!
Xinyang Qiu
Web Platform and Tools team
Posted by DaveAce on 4/3/2013 at 12:55 PM
forgot to mention that VS2010 is started as "Run as Administrator"
Posted by DaveAce on 4/3/2013 at 12:53 PM
Having same issue with VS2010 on Windows 7 after (important) install of IE10. Project is set to launch from IIS and get the "Unable to start program <url> there are no more files" error. IE10 does launch but VS2010 kicks back the error moments later and stops debugging.
Fix mentioned is only for win8.
Any other progress as it is most likely an IE10 issue?
Posted by Microsoft on 11/20/2012 at 1:37 PM
Hi, David,
Do you mean tht your IE10 preview on win7 works after reboot? Or do you mean it is broken with IE10 preview on win7, even after reboot?
Thanks.
Xinyang Qiu
Web Platform and Tools team
Posted by David Libido on 11/14/2012 at 2:01 AM
Same here after upgrading to IE10 preview on Win7
Posted by Microsoft on 11/12/2012 at 3:03 PM
Thanks for all of the great details, Gibwar.

It sounds like you are completely unblocked for using VS to debug web applications on x64 windows 8. There are still two issues outstanding but are likely related to the second change that the IE team said would be coming in a later update. I've let them know the results of your detailed investigation so they can confirm.

I'm going to go ahead and resolve this bug as fixed since the original issue is now resolved and leave the remaining issues to the IE team to handle.

Thanks again to everyone who reported this and helped us track it down.

Marc Paine
Visual Studio Debugger QA Lead
Posted by Gibwar on 11/9/2012 at 6:59 AM
Thanks for the quick reply. After a couple extra subsequent reboots it appears the problem is fixed from within Visual Studio 2012 when using the provided "Internet Explorer" default. It fails to launch with no error (silent) if I explicitly add IE 32-bit to the browser list and attempt to launch with that.

I've confirmed that setting the HOMEDRIVE back to C: allows IE (32-bit) to be launched directly, though the debugger doesn't seem to attach to the explicit 32-bit process. It does attach fine when using the default though.

As for your questions:
- I'm running Windows 8 Enterprise x64, Visual Studio 2012 Ultimate, and IE10.
- The HOMEDRIVE is set to H:, HOMEPATH is set to \, and HOMESHARE is set to \\server\share\username.
- It started working with the default IE, but setting the HOMEPATH back to C: let 32-bit launch explicitly.
- Without it, not only did it fail, it failed silently without any warning. Targeting the default worked, though.

As an aside, even with all of the patches installed, I cannot launch IE 32-bit explicitly from explorer or the command prompt either. Setting HOMEDRIVE to C: allows IE 32-bit to launch.

So, just to summarize: the patches did fix the initial problem, I can now create a new web project in VS 2012 Ultimate, use the default Internet Explorer listed in the Browse With dialog, and run the project. If I add IE 32-bit to the list, set as default, it runs but doesn't open a window and doesn't attach. Changing HOMEDRIVE will allow IE 32-bit to launch, but the debugger does not attach to the new process.

Thanks for the help in this!
Posted by Microsoft on 11/8/2012 at 11:25 AM
You can also try a reboot as sometimes KBs will modify files in use and so the update doesn't take effect until after a reboot.
Posted by Microsoft on 11/8/2012 at 11:19 AM
Thanks Gibwar. I've talked to the IE team and they say that 2756872 should fix nearly all cases of this. There were some very corner cases that they didn't think were possible through VS that will be fixed in a later update.

Can you let me know your exact config/scenario?
What is your homedrive set to?
Does resetting it to the local value fix the problem?
Does only x86 launch of IE fail? Can you target the x64 one through the VS launch project settings and does that succeed?

Thanks in advance.

Marc
Posted by Gibwar on 11/8/2012 at 8:07 AM
I've installed all available updates for Windows 8 and the problem still persists.

Hotfix(s): 6 Hotfix(s) Installed.
[01]: KB2712101_Microsoft-Windows-CameraCodec-Package
[02]: KB2756872
[03]: KB2761094
[04]: KB2764870
[05]: KB2768703
[06]: KB2770041
Posted by Microsoft on 10/29/2012 at 4:34 PM
Hello, if anyone is still hitting this problem, can you try running windows update? I've been told that IE released a fix for this issue as part of a recent windows update patch (KB 2756872). Please confirm that installing this update fixes the problem for you.

Marc
Posted by ZeroSVT on 9/6/2012 at 1:02 PM
Hi,

I also tried removing my homedir from AD and it also fixed this issue.

It is directly related to the homedir.

Thanks!
Posted by TPaling on 9/3/2012 at 4:41 AM
I had our network manager remove my home drive setting from AD, rebooted and logged with my AD account and it worked fine.
Posted by Microsoft on 8/30/2012 at 1:54 PM
Thanks all for the confirmation. IE team get the repro and is fixing it. When they deliver the fix, I'll let you all know. Currently, please use the workarounds shown in the Workarounds tab.

If you encountered the issue which not related to "Homedrive" environment variable, please let us know asap, as there might be other causes.

Sorry for the trouble. Thanks again!

Xinyang Qiu
Web Platform and Tools team
Posted by JCorker on 8/30/2012 at 12:50 AM
I can confirm it works for me too. Off the domain my homedrive is C: and on the domain my homedrive is F: debugging is working fine when I'm off the domain.
Thanks.
Posted by Marc-André Boivin (PA) on 8/29/2012 at 2:22 PM
I confirm the fix.

Before I removed all the kix32 scripts we are running at logon, my homedrive was U: and I was unable to debug.
Now after I removed them, my homedrive is C: and I'm able to debug.

Another developer here can confirm it works for him too.
Posted by Microsoft on 8/29/2012 at 1:53 PM
Thanks for all the support here.

We are in talk with IE team. They have a theory that they might be using "HomeDrive" environment somehow when determining the IE path, which might cause this issue if Active Directory set this for the AD users. I want some confirmation to see if this is the case for your scenario. Please go to the command prompt and type set home, and tell us about the output.

And if you can convince your AD administrator to test the theory out for us, it would be even better, that if they don't assign the homedrive for you, would your problem goes away?

If this can be confirmed, I will pass it to the corresponding team to seek for a fix.

Thanks!

Xinyang Qiu
Web Platform and Tools team
Posted by Sanny Jacobsson on 8/29/2012 at 6:24 AM
Create a local account that is part of the Administrator Group.
Run VS 2012 as the created local user, "Run as different user".

Hit F5 and debug as usual.
Posted by KillingComputers on 8/28/2012 at 2:37 AM
It's not just VS2012. I removed VS2012 and installed VS2010. The same condition exists. Launching with CTRL+F5 will open the app, no debugging, but I also get the same popup. I was going to try uninstalling IE10 and putting IE9 back, but then thought of what else would I be breaking popped in my head.

Oh well. Hot Fix and/or SP1 in the first month of release. Take Note Microsoft. Quality goes out the window when you rush to meet release dates.
Posted by EHCarleton on 8/25/2012 at 5:44 AM
I am seeing the same issue:

* Fresh install of Windows 8 64-bit
* Fresh install of VS2012
* Fresh install of SQL Server 2012 (not that I think it matters)

I created a basic ASP.Net 4 web application and ran it and got the error.

Here is the key: I was logged into the Active Directory Domain. I just logged in to the machine with a local user and I did *NOT* get this bug! It is directly related to something with the Active Directory. My AD user is a full admin on the domain, also.

Sam
Posted by MarkEwer on 8/22/2012 at 5:59 AM
Using any browser other than IE seems to be a work-around but not a very good one because Visual Studio will not debug JavaScript code in any browser other than IE. This is broke ... help!
Posted by Microsoft on 8/21/2012 at 11:47 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Mathieu Aubin on 8/21/2012 at 11:46 AM
Same Issue here, very annoying. Need a fix ASAP
Posted by Louis-P Perras on 8/21/2012 at 11:01 AM
I think the real problem is with Window 8 with Active Directory accounts. The issue is that IE10 32-bit cannot be launched. If you try to execute C:\Program Files (x86)\Internet Explorer\iexplore.exe from your AD account it will do nothing. Then if you try from a local account or any Microsoft Account it will launch properly. Since VS2012 tried to launch the process in 32bit I think this is the reason why we have this error.
Posted by JCorker on 8/21/2012 at 6:05 AM
More variations on this problem have been discussed here:

http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/a469a1a4-5890-4fe2-92f5-256a1aad845a/
Posted by Simon de Kraa on 8/21/2012 at 4:51 AM
I have the same problem on Windows 8 x64, IE10 and Visual Studio 2010 Premium.

To reproduce the issue:
1. Create a new project: File, New, Project, Visual C#/Web, ASP.NET Web Application.
2. Hit F5.
Posted by Microsoft on 8/21/2012 at 4:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
Posted by KurienP on 11/1/2013 at 1:44 PM
I had this issue for both VS 2012 and VS 2013. First I Set HOMEDRIVE variable before starting Visual Studio. It worked and solves the issue .

But the best thing is to do a Repair on the VS 2012/VS 2013. It solved the issue on both the Versions
Posted by jwk1 on 1/11/2013 at 1:49 PM
I found that having a dummy IE 10 browser open, not even showing a web site, before running VS 2012, a new browser opens and runs the application with debugging just fine. When closing the application browser, it does not stop debugging, nor does stopping debugging close the browser. The dummy browser seems unaffected, but VS 2012 debugging will stop when it is closed.
Posted by SolarStorm50 on 10/30/2012 at 5:02 AM
One more vote for changing the homedir in AD fixed this for me
Posted by Boris2000 on 9/26/2012 at 2:21 AM
Set HOMEDRIVE variable before starting Visual Studio, for example from a batch file:

SET HOMEDRIVE=C:
CD C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\
start devenv.exe
Posted by ZeroSVT on 9/6/2012 at 1:03 PM
Have your domain Admin remove your Home Directory from your AD path. Reboot, and the problem will be solved.
Posted by Sanny Jacobsson on 8/29/2012 at 6:25 AM
Create a local account that is part of the Administrator Group.
Run VS 2012 as the created local user, "Run as different user".

Hit F5 and debug as usual.
Posted by Louis-P Perras on 8/24/2012 at 6:28 AM
Disconnect your Ethernet cable or disable Wi-Fi on your laptop before you login with your AD account. They plug the cable in or re-activate the Wi-Fi. Debugging should now work as long as you keep this session open. What I did was login with network off and ran C:\Program Files (x86)\Internet Explorer\iexplore.exe just to make sure that it now runs. After that launch VS and debug like you did before being an early adapter!
Posted by Steve Loethen on 8/22/2012 at 10:35 AM
"There be dragons..."

I found another way to get IE to use f5 or ctl-f5. I went into ProgramFiles/InternetExplorer, copied the IE exe to another name in same directory (I called mine IE64.exe) and then added it as a browser. Set it as default, and hit ctl-f5. Eureka....

I am sure this is full of drawbacks, but it currently hasn't broken anything yet.
Posted by JCorker on 8/21/2012 at 4:46 AM
Click browse width under the debug button and then select IE, this is more time consuming than just installing another browser though so you can press F5.
Posted by JCorker on 8/21/2012 at 4:45 AM
Install Chrome and set that as your default browser.