Visual Studio 2012 RTM cannot debug x64 project - Operation taking longer than expected

Question

I have several projects, including a new WPF C# solution generated with VS2012. Whenever the target platform is set to x64, or attempting to start debugging an x64 target, the result is an eventual 'Operation taking longer than expected' dialog.

Having read all the documentation I can locate on VS2012 x64 debugging it seems that the remote debug monitor needs to be running for x64 debugging. I tried that with no success. I turned off the firewall with no success. I have run everything as administrator with no success.

This occurs on several machines, but all are Windows 7 x64. I have no problems when using VS2010.

Suggestions?

Bill

Answer 1

I run VS2012 on an x64 with no problems.  I think it could be environmental.  Let's start with the simple stuff though.  Can you set the target platform to AnyCPU for your app and run it.  Do you get the same behavior?  On an x64 machine the EXE will run as x64 so the behavior should be the same.

Does the debugger eventually start?  Do you have Visual Studio Host enabled for your project?  If so does turning it off help?  Do you have the same problem for a simple console app?  Are you using a symbol server?  If so try turning off the option to download symbols in case it is being blocked by your network firewall.

Michael Taylor - 8/22/2012
http://msmvps.com/blogs/p3net

Answer 2

Using AnyCPU displays the same results as x64, 'Operation taking....'

When using either the x64 or AnyCPU targets, the debugger never starts. When the 'Operation Taking...' dialog eventually appears the only option (button) is 'Terminate'. Selecting Terminate adn confirming the subsequent 'are you sure' dialog results in the display of an error dialog:

---------------------------
Microsoft Visual Studio
---------------------------
Error while trying to run project: Unable to start program 'C:\Users\bswanson\Desktop\Sandbox\Hello2012\Hello2012\bin\Debug\Hello2012.exe'.

The network connection to the Visual Studio Remote Debugger has been closed.

I have tried turning the vs host on and off with no success. There are no symbol servers enabled. Simply creating a new console application solution will display the dialog - since the default platform is AnyCPU, and debugging again results in the dialog.

In all cases, switching the platform to x86 works.

I would also believe that it is environmental, but I have the problem on several machines. To clarify I have not seen it work on any machine, but all of my machines are Windows 7 x64.

I think that the main clue here is "the network connection ... has been closed". It would seem apparent that some form of interprocess communication is being blocked in some way - which is why I tried it with the firewall turned off and as an administrator - all with no success.

Thanks for your help.

Bill

Answer 3

The next thing to try is starting up a debug session and while it is locked up use either Process Explorer or start up another instance of VS and connect to the first instance.  Check out the stack trace to see what is going on and if the remote debugger started or not. 

Here's what should happen process-wise:

1) You start VS so devenv starts up

2) When you create a new console app than an instance of vshost will start up. At the same time you'll see Intellitrace start up.

3) When you start debugging then and instance of MSBuild will also start up.

A couple more things to try would be to run in safemode (/safemode) to ensure no addins are getting in the way.  Also disable Intellitrace.

Michael Taylor - 8/22/2012
http://msmvps.com/blogs/p3net

Answer 4

When loading a console solution set to target x64 I see both msvsmon.exe and then HelloConsole.vshost.exe start. After perhaps 30 seconds (the 'Operation Taking longer dialog is displayed during this period) the msvsmon.exe process exits.

I do not see a process for Intellitrace, but this is VS 2012 Premium, not Ultimate.

Starting devenv with the /safemode flag had no effect.

A brief review of the event log yielded nothing interesting.

Another interesting find: When I launch VS, then Debug/Attach to Process.. the 'Operation Taking Longer' dialog eventually appears and after pressing Terminate the following error dialog appears:

---------------------------
Microsoft Visual Studio
---------------------------
Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'W7-BSWANSON'.  The network connection to the Visual Studio Remote Debugger has been closed.

At this time there is an instance of the msvsmon.exe process running, which again eventually exits after approx. 30 seconds.

Thanks,

Bill.

Answer 5

So it appears that there is a problem with the msvsmon process.  Normally if you kill the process manually then VS will restart it automatically.  I guess you don't see that behavior?  It'll also bring down the vshost instance.  What OS are you running?

Someone from MS also reported that a problem can occur if you have a file on the file system that is getting called in lieu of the monitor.  Refer to the following post (about half way down they talk about file paths) and see if the problem applies to you: http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/10452212-c8f7-47d1-ba5b-96350e1bd616

Another thing you might consider is ensuring that envvar for path doesn't contain something that would cause the wrong version of the monitor to start.

Michael Taylor - 8/23/2012
http://msmvps.com/blogs/p3net

Answer 6

Hello,

I was having the same problem on my machine installed with the new Windows 8 and VS2013 released on Aug.15.

Apparently, the problem in my case was the antivirus. (Bitdefender Internet Security 2013).

Problem solved after uninstalling BD. Important note! disabling the BD features is not enough. Only uninstall. I've opened a ticket at Bidefender and waiting for their reply.

Hope it will assist in your case.

Oren R.

Answer 7

The machine is a Windows 7 x64 sp1 machine up to date with Windows Update.

When the msvsmon.exe process is started by Visual Studio it does appear to be the correct version - i.e. right click select of 'Open File Location' from Task Manager brings up the "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Remote Debugger\x64" folder. There are no similarly named files along the path as described in the post you mentioned.

The msvsmon process does not seem to be relaunched after killing it , or it exits after a period of time.

I can manually start msvsmon and view/change options/permissions without any success. Starting msvsmon manually and then visual studio also does not help.

The only anti virus program I have installed is Microsoft Security Essentials.

Bill.

Answer 8

If you stop Windows Defender, Windows Firewall and MSE does this allow the monitor to start?  What threads are running when the monitor stalls but before it exits?

Michael Taylor - 8/27/2012
http://msmvps.com/blogs/p3net

Answer 9

Stopping MSE real time protection, shutting off Windows firewall, and stopping a VPN I normally run did not help. I am not using Windows Defender.

Attaching to the msvsmon.exe process with VS2010 and pausing it reveals a main thread and 9 worker threads:

Unflagged 7160 0 Main Thread Main Thread 0000000077ae18ca Normal
Unflagged 5148 0 Worker Thread Win64 Thread 0000000077ae18ca Normal
Unflagged 5492 0 Worker Thread Win64 Thread 0000000077ae135a Above Normal
Unflagged 7944 0 Worker Thread Win64 Thread 0000000077ae13aa Normal
Unflagged 8180 0 Worker Thread Win64 Thread 0000000077ae13aa Normal
Unflagged 3316 0 Worker Thread Win64 Thread 0000000077ae18ca Normal
Unflagged 7644 0 Worker Thread Win64 Thread 0000000077ae165a Normal
Unflagged 7656 0 Worker Thread Win64 Thread 0000000077ae2c1a Normal
Unflagged 7768 0 Worker Thread Win64 Thread 0000000077ae135a Normal
Unflagged > 3360 0 Worker Thread Win64 Thread 0000000077ae135a Normal

Answer 10

The problem is obviously with the monitor not running correctly but why is still a mystery.  I would try starting a copy of VS and then a separate copy of VS that you'll run your app in.  Start your app in the debugger and then immediately switch to the first VS instance and attach to the instance of the monitor that was started, before it disappears.  This should throw you into the debugger and hopefully allow you to see any exceptions it might be generating.

Answer 11

I'm getting the same exact thing with 2012 final release Premium.   You can't attach a second debugger to the first debuger because you get the blasted message when trying to attach to a process.

Answer 12

I'm afraid I've run out of ideas.  I think you're going to have to contact MS support and have them help diagnose the monitor issue.  They'll likely have you run the Windows Performance Toolkit which ships with VS to try to narrow things down.  I suspect something is blocking the monitor but I can't quite figure out what.

Michael Taylor - 8/28/2012
http://msmvps.com/blogs/p3net

Answer 13

When attaching the VS2010 debugger to the msvsmon process of the VS2012 instance and allowing the process to run it eventually exits without any exceptions caught in the debugger or any clues that I can determine as to why it exited.

Other issues that I have noticed include the ability to debug Silverlight applications, or the ability to attach to other processes as John noted.

Bill.

Answer 14

I believe that I have found the source of the problem... I installed VS2012 on a Windows 7 x64 VMware virtual machine that was relatively pristine. Debugging works.

I installed the Astrill VPN software that I use regularly - and debugging fails. Uninstalled Astrill and debugging again functions.

Note that you do not have to be logged into the VPN, just having it installed causes the problem. I was lead down this path by a separate thread that I read (I can't remember where at the moment) that concluded that an unnamed corporate VPN was the source of debugging problems under VS2010.

I have sent a query to Astrill support, but I am doubtful that they will be able to resolve the issue since their client seems to be based upon the OpenVPN stack.

Having narrowed down the culprit...and suggestions on working around it?

Bill

Answer 15

VPN is an odd beast because it inserts itself into the network layer even when it isn't called.  It has such a dramatic impact that I never install VPN on my dev machine.  Instead I run the VPN software through a virtual machine.  I don't know what it is about VPN but I've never had much luck with it.

Answer 16

Hi CoolDadTx,

Thank you for your friendly assistance.

Hi Bill,

I have sent a query to Astrill support, but I am doubtful that they will be able to resolve the issue since their client seems to be based upon the OpenVPN stack.

Based on your description, it seems that this issue is related to the Astrill VPN, so we could make sure that it is not the VS debugger tool issue. Since the Astrill VPN is out of support range of VS Debugger forum, and it seems that it has the specific forum https://www.astrill.com/. So if possible, I suggest you post this issue in that forum for better support. Thanks for your understanding.

Best Regards,

---

Jack Zhai [MSFT]
MSDN Community Support | Feedback to us

Answer 17

I am seeing this issue on Windows 8 Pro with Visual Studio 2012. Opening a 64 bit app locally won't allow me debug and reports the error. I have uninstalled SonicWall VPN however none of the fixes found by searching the issue rectifies the issue. Reinstalling Visual Studio 2012 does not work either. Is there a hotfix for this yet? Is there another work around without migrating to a 32 bit... which in my case won't be possible due to 64 bit references.

---

~Marty

Answer 18

There's no fix because it currently doesn't appear to be a problem with VS.  Certainly not one that can be replicated by MS.  After uninstalling VPN I would check your network drivers to ensure the VPN driver is still not in the network stack anywhere.  Can you provide any more information on what the call stack looks like when it freezes?

Michael Taylor - 9/3/2012
http://msmvps.com/blogs/p3net

Answer 19

Same problem caused by OpenText Socks Client 14 and/or Juniper Connect Client 6.5. Removed both, rebooted, then the tests ran fine. Actually tried with test processor set to X86 and still failed with "Operation taking longer than expected". So if this is to do with X64 then it must be just that VS is running on an X64 machine, not that the test process is X64.

Anyway, I'm still investigating alternatives to my administrator defined VPN requirements (out of my control - customer policy) so will have to try again to get it working with this software.

But I must say this should not be an issue for VS. What the heck has it got to do with networking, running a unit test? All local references should go via localhost thus bypassing any additional network filters (I guess)?

Once I know for sure and can re-create will create a MS Connect issue...

---

Key Artefacts

Answer 20

anyone able to find a fix?

my colleague have the same issue but he dont have VPN.

hope ms fix this soon

Answer 21

My issue was a Bigfoot network card... it was interfereing so I uninstalled the drivers. What I find from several users is that the culprit is random drivers from some programs. The fix is to uninstall drivers until it works.

---

~Marty

Answer 22

i tried reinstalling, uninstalling network driver but still have the issue.

any other solution?

Answer 23

I have the same exact problem. I uninstalled some applications but the problem continues. does any one have a way to fix or work around this issue.

Thanks

Found the problem by me. I installed an application to hide my IP address. uninstalling it solved the problem.

Answer 24

Just wanted to add some information about how this problem went away for me.

Besides avoiding additional VPN software, at the same time there were several issues with both Realtek and Intel motherboard NIC drivers and Windows 8.

There is another thread about that in the correct forum, so regarding VS it is safe to say when this error occurs you need to check and double-check everything to do with your network drivers (and in my case BIOS support for Windows 8 too).

I've since reinstalled my workstation and avoided having any virtual machines connected to built-in network adapters. I found the Intel 350 T2 dual 1Gb NIC on Amazon for 130 euro with VTd support a bargain (compared to other "server" cards which are very expensive).

Since then both Realtek and Intel have released updates for their built-in NICs specifically addressing issues with Windows 8 so you probably don't need new hardware, just to make sure all drivers and perhaps your BIOS are up to date.

---

Key Artefacts

Answer 25

Some of Microsoft products (not limited to Visual Studio) use background processes and communicate with each other using ::1.They first try to resolve this IP to get binary address, instead of just using it directly. As Astrill LSP includes a DNS anonymizer, it will rewrite IP to an internal IP. We believe this is what causes the issue and breaks communication with a background process.

You can hard exclude applications from Astrill LSP. Hold down Ctrl key and click on Help menu. You will find there "Hard Excluded apps" option. Type there executable names of all applications you wish to exclude (you will need to find all relevant programs used by one application - some might be not so obvious, some might be background services), for example:

notepad.exe

After changes, logout from Astrill and login back (or restart Astrill). Then restart affected application (if it uses background services, we recommend to reboot computer or restart these services manually).

Alternatively, you can uninstall Astrill LSP - hold down Ctrl + Help. After this, some features will be unavailable. OpenVPN will be not affected, except Application Filter will be unavailable.

Answer 26

Here's the answer I got from Astrill on this issue.

Hello Amine,

I suspect Astrill LSP is causing the issue as Microsoft products use a background processes and communicate with each other using ::1. They try to resolve this IP instead of using it directly.

You can try to hard exclude affected applications. To do so, hold down ctrl key and click on Help menu. Then add any affected application names to Hard Excluded List, for example:
notepad.exe

You'll need to identify .EXE names of all applications used by particular Microsoft tool. Some are maybe not obvious, some could be background services.

When you find the list of applications, you can send to us so we can exclude them by default.

Another solution is to uninstall LSP, you can do that from the same menu (Ctrl + Help). After this some Astrill features will be disabled. OpenVPN will not be affected, except Application filter will not be available anymore.

Best Regards,
Astrill Development Dept.

Answer 27

I had this issue on the release preview version of vs2012 but it went away with the full version.. until a few hours ago where the debugger just stopped working on x64 code.

After reading this post I went out to the store and bought an Intel EXPI9301CT to replace my Bigfoot Killer Xeno Pro.

After installing the card and fiddling with bios for a few moments everything boots up and the debugger connects instantly.

Answer 28

Clearly there is something wrong with VS2012 as VS2010 doesn't exhibit the same problems. One should not have to start uninstalling software to make 2012 run correctly when 2010 runs with no aggro. What is so whiz bang fantastic with 2012? a flat GUI instead of 3D? What a fasionista and they have introduced errors into the mix!

I don't know why people are so forgiving to Microsoft after all its the corporation owned by the richest man in the world (oh sorry 2nd richest now), new releases shouldn't break! maybe they should invest more in quality control or up the permutations of their test rigs or do something other than test in "production" via the plebs ...

Pretty shoddy work! they can't be up to anything good.

Answer 29

Got the same problem here (Win 7 64-bit, VS2012). When I start debugging a simple x64-WPF application VS2012 IS starting msvsmon.exe in the right directory. The task manager shows the following command line:

"...\Remote Debugger\x64\msvsmon.exe" /__dbgautolaunch 0x00001600 0x2438 /hostname [::1] /port 1846 /__pseudoremote

a) I wonder where does VS2012 take these parameters from?

b) why is the hostname a IPv6 address since I don't use IPv6?

c) why is the port changing from call to call?

I also installed remote debugger as a service. When running it starts two processes of msvsmon.exe (one in x64, one in x32) but with totally different parameters:

.....\Remote Debugger\x64\msvsmon.exe /CHILDSERVER e4 "+:4016" {B608A-...} 0x0 4017 e0 d0 cc dc /silent+ /servicemode+

Again the question: where are those parameters from? And maybe somebody can explain them to me?

Regards

Heiko