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

Status : 


Sign in
to vote
ID 758876 Comments
Status Closed Workarounds
Type Bug Repros 45
Opened 8/21/2012 4:44:03 AM
Access Restriction Public


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.
Sign in to post a comment.
Posted by Deon [MSFT] 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:
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:
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?
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 Marc [MSFT] 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 Marc [MSFT] 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 Marc [MSFT] 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.

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 Marc [MSFT] 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.

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

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

It is directly related to the homedir.

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.
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.


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.

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:
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(