Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Monday, October 12, 2015 10:18 AM
I am getting this message pop up constantly and it takes 10-15 seconds for the pop-up to disappear. It happens when I start up VS; and when I end a Debug session. I'm guessing this is from some VS addon that is not responding to a VS request.
Qustions:
Is there a VS log somewhere that will tell me what addon VS is waiting for? If I can uncheck a VS option to stop this, that would be great. But I have no way of knowing what's causing this.
There is a cancel button on the pop-up dialog. Can I dismiss it with no ill effects?
All replies (17)
Thursday, December 17, 2015 12:22 PM âś…Answered
@Im Virginia,
Thanks, I tried that but it did not work.
My workaround for this problem is to set the Project Debug Platform Target to x86. That avoids invoking the x64 VS Remote Debugger which is where this problem resides (IMO). I don't need to do any remote server debugging anyway so I don't know why VS2015 uses invokes that debugger anyway.
Monday, October 12, 2015 11:07 AM | 1 vote
Hi Telexer,
I would suggest please have a look into MSDN blog created by Nitish Nagpal, that will help you to solve your problem,
http://blogs.msdn.com/b/dsvc/archive/2013/12/31/visual-studio-debugging-issue.aspx
Thanks, If my reply is helpful please mark as answer or vote as helpful.
Monday, October 12, 2015 1:17 PM | 1 vote
Kamlesh ,
Thanks for that link.
Given that blog article, I tried turning off both the computer firewall (Zone Alarm) and antivirus (AVG).
I also added these to the firewall trusted application list.
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe
None of that made any difference.
If VS doesn't log the dll it is waiting on, this is going to be a bear to determine the source.
I am not going to start uninstalling VS addon willy nilly. Last time I did that, VS became unstable and I had to uninstall/reinstall it.
Tuesday, October 13, 2015 8:25 AM
Hi Telexer,
>>1) Is there a VS log somewhere that will tell me what addon VS is waiting for?
Please check the ActiveLog.xml under the path of %AppData%\Microsoft\VisualStudio\14.0. This file will log all operations when you operate Visual Studio. There may be have the information that you want.
>>2)There is a cancel button on the pop-up dialog. Can I dismiss it with no ill effects?
I don't occurred this problem so I don't have a try to click the Cancel button. But I find someone who has the same problem do cancel, it will show another error window. I don't confirm whether it will affect the solution or Visual Studio.
Visual Studio is a 32 bit program. This problem often occurred when Visual Studio runs on a 64 bit machine to access network. There are two workarounds for this problem.
Workaround 1:
1.Run cmd.exe as administrator
2.Type in and run the following commands:
netsh winsock reset catalog
tetsh int ip reset reset.log hit
Workaround 2:
1.Navigate to C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger
2.Open x64 folder and rename the msvsmon.exe file to msvsmon_old.exe
3.Now, navigate to x86 folder and copy msvsmon.exe and paste it into x64 folder.
4.Restart the Visusl Studio 2015 IDE, and now try attching to process during debugging
Best Regards,
Weiwei
Tuesday, October 13, 2015 8:57 AM
Weiwei,
Thanks for the workarounds.
Workaround 2 does NOT work -- at least not on my system. After I followed the instructions to rename/copy msvsmon.exe, but then I could not start Debug in VS. I have a Win7 x64 machine and the project is marked CPU-ANY. After I open the project in VS, I see that msvsmon.exe does not appear in Windows Task Manager. So VS will not load it. I renamed the x64 msvsmon_old.exe back to msvsmon.exe and Debug works again, so it was worth a try.
I'll try Workaround-1 later after I have time to lookup and read what those commands are doing.
Wednesday, October 14, 2015 10:44 AM
Weiwei, again thanks for the suggestions.
But, Workaround 1 does not fix this problem either.
In fact, now after I end a debug session, the Debugger msvsmon.exe often disappears from Win Task Manager. So then I have to close VS and restart it to get msvsmon.exe loaded again. Really Really Aggravating and Time Wasting.
Not sure if Workaround 2 caused this or something else, because it has been happening in the past few weeks. But now it is back with a vengeance. Ugh.
I can't believe the time I have wasted trying to get VS2015 to just do builds and debug without blowing up.
Thursday, October 15, 2015 5:09 AM
Hi Telexer,
Do you have check the ActiveLog.xml file and get any error message in that file? Is this problem occurred after you installing Visual Studio or used it for a long time? If it works before, please recall what do you do in the meantime.
Please create a new project or create other type project to check whether it is occurred with a specific project, one type of project or for all projects.
According to the message in pop up window, it is occurred with 64-bit debugging operation. Please try to changing properties/compile/target platform to x86 instead of Any CPU.
Best Regards,
Weiwei
Thursday, October 15, 2015 10:57 PM
Weiwei, thanks again for more suggestions. I had a good day today, The debugger only crashed a couple times. So can live with that if it doesn't become more frequent. No idea what changed since yesterday except Patch Tuesday patches were installed.
I looked at the ActivityLog.xml. There are no messages regarding MSVSMON.EXE. And no error messages with today's date.
If I discover anything new, I will post it back on this thread.
Monday, October 19, 2015 11:23 AM
Hi Telexer,
Do you have discover anything new?
The pop up windows mentioned that it may caused by 3rd part networking software, please try to run Visual Studio in safe mode with "devenv.exe /SafeMode" command to prevents all third-party VSPackages from loading when Visual Studio starts, thus ensuring stable execution.
In addition, please try disconnect the internet connection to verify whether it is caused by the internet connection.
Best Regards,
Weiwei
Tuesday, October 20, 2015 10:45 AM
Weiwei,
I tried your suggestions.
- First I disconnected from the Wifi Internet.
- Then I started in VS2015 in safe mode.
Neither of those helped.
In both cases, I still get the "64-bit debugging operation is taking longer than expected."
Wednesday, October 21, 2015 9:49 AM
Hi Telexer,
Could you please provide a sample project which has this problem to OneDrive and share the link here to help us reproduce your problem.
You have mentioned that before this problem occurred you installed Patch Tuesday patches. If possible, please try uninstall these updates to make sure whether it is caused by them.
If can't, please debug this solution in another computer to confirm it is related to your solution or Visual Studio 2015 on current environment.
Best Regards,
Weiwei
Thursday, October 22, 2015 9:51 AM
Weiwei
Yes it still happens constantly. I have tried everything. It is an annoyance and slows me down a bit. But it is managable and I'll live with it. I'm hoping some future service pack will magically make it go away. I doubt that Patch Tuesday patches had any effect on this. None of the patches were related to VS2015.
I am not willing to post the projects for public inspection. Sorry, this is source code for programs that I sell. It is too large anyway -- multiple solutions for a main program exe and utility dlls.
And I can't reproduce the problem with a new simple project. I have tried that.
I'll probably just live with the annoyance and get back to coding.
Thank you for your help.
Wednesday, December 16, 2015 11:21 PM | 1 vote
Try this solution from stack overflow
it worked for me...got the same error in VS2015
Run cmd.exe as administrator. Type in and run the following two lines of commands:
1) netsh winsock reset catalog
2) netsh int ip reset reset.log hit
It may say that a reboot is required, but actually that is not necessary. Try to debug your application again, the problem should be solved.
Friday, January 19, 2018 5:40 PM
Finally solved it for me. I cannot change the Debug platform to x86 but found this comment and worked:
Posting were so that others may come across.
Monday, February 5, 2018 4:05 PM
In case anyone is still looking at this in 2018, I had the same problem while trying to boot up a .net app using local IIS - the solution was the recycle my app pool.
Wednesday, August 8, 2018 9:17 AM
Yes. Finally I could able to solve this issue with the workaround mentioned in the link.
Thanks a ton for posting it here!! Appreciate your help
BR,
Aditya
Friday, September 27, 2019 6:11 AM
Thanks Tiago,
that solved the problem for mee, too!
In my case Visual Studio 2015 actually never recovered after this error message but stayed frozen until debugging was terminated.
I forcly stopped the "VSStandardCollectorService" via "taskkill /pid [pid number] /f" and then disabled it completely in the"services.msc".
After that, dubugging finally worked again :-)