I have a very annoying issue with visual studio 2008 sp1 on windows 7 64 bit.
The software we are working on uses a client that connects to a windows service. so, when i do a debug, i debug on 2 processes, the client and the service.
When hitting a breakpoint on the service, and using F10, F11 for 20-30 times aprox, I get an "Visual Studio is busy doing an internal operation ..." message, after which the debugger throws me to another place. If I look at the call stack, there is a message "Evaluation of:". above it, the call stack where I currently am, and below it, there is the call stack where I was before the error occurred.
here is something similar: http://social.msdn.microsoft.com/Forums/en-MY/vsdebug/thread/4c30e3f4-587e-4f14-8cec-8663d268c55c
I tried installing latest updates, cleaning solution, deleting dll files, *ncb, *suo. nothing worked :|
It's not related to the wpf editor bug.
Thanks.
This is barely an answer, but I had the same problem with VS 2008 (updated to KB972221) running on 32-bit Windows XP.
The key seems to be running two instances of VS2008 at the same time.
I had a client/server setup and was running each of these executables via its own VS2008 instance. The server was multi-threaded, the client I think single-threaded.
Like you, I had set a breakpoint and was then F10 stepping through the code when I had the same experience of VS hanging for a while then dumping me elsewhere in the code following an Evaluation of: message in the call stack.
However, I changed to simply running the client executable on its own, with just the server running in debug mode with VS2008, and the problem never recurred (to date!).
So maybe the workaround is simply to stick to a single VS2008 session.
Related
I'm looking for tips for those who to develop for Windows XP embedded in Visual Studio2013, then debug in Visual Studio 2010.
The reasons for this are discussed in this Stack Overflow Link on the topic.
Essentially the remote debug protocol changed after VS2010, and the new msvsmon.exe which uses the new VS2013 protocol doesn't support XP embedded debugging. So we are forced into a TWO IDE solution, one for builds, another for debug. VS2013 is used for builds, and VS2010 is used to launch remote debug sessions.
There is some misinformation about the requirement to purchase both VS2013 and VS2010. It appears from the previously mentioned link, that it's possible to obtain the VS2010 debug environment for free. I was able to verify the free download of the components, but haven't had time to validate that the debug environment works. The environment I use consists of a licensed copy of VS2013 and a licensed copy of VS2010.
Here are two initial problems which I haven't seen doing remote debug in the former VS6 msvsmon.exe environment:
1) With VS2013 build projects, VS2010 does not want to open the *.sln file. If I open the VS6 .dsp/.dsw we ported from VS2010 does a "ONE TIME CONVERSION" which destroys my painstakenly built VS2013 build project.
It seems I will have to build TWO different solution spaces, one named SOLUTION_NAME_VS2013 and another SOLUTION_NAME_VS2010. I'm interested to know if there is a more elegant solution to manage 1 set of BUILD files with two different "Highlander" (there can be only one) IDE's.
2) When starting up the project remotely, if it crashes I get one of those annoying "Your program has crashed" dialogs on the Win2012 debug host (running VS2010), which is trapping the crash signal from the debugger. About 30% of the time, it detects the running instance of VS2010, 70% of the time it doesn't.
3) msvmon times out (needs restarting) and requires extra time/mouse clicks to setup over the old vs6 msvcmon.exe
I'm wondering if other Windows Embedded developers have discovered elegant solutions for these issues. I'll post what I find here if I find any more tips moving forward.
For Issue #1: Unable to read VS2013 *.sln file in VS2010.
The problem was that the VERSION of Visual Studio 2010 must be at least SERVICE PACK1. Earlier versions of Visual Studio 2010 cannot read the VS2012/VS2013/VS2015 solution files.
For Issue #2: Your program has crashed dialog preventing signals from reaching debugger.
This Stack Overflow link was helpful. There are multiple ways to suppress the "Your program has crashed" dialog. In my case, users may need to debug new applications on a production system, so changing the setting globally is not ideal.
I choose the solution from this Raymond Chen link it allows me to disable the dialog box on an application by application basis. Since I typically have access to source code I'm debugging this was the best solution for me.
DWORD dwMode = SetErrorMode(SEM_NOGPFAULTERRORBOX);
SetErrorMode(dwMode | SEM_NOGPFAULTERRORBOX);
I still see an issue occasionally with the Windows runtime not seeing the running debugger instance on a crash and wanting to initiate a new one. This seems to happen ~30% of the time. When I figure out what is causing that I will update it here.
Finally, the new remote debug client changed to msvmon.exe which has improved security. To save the extra mouse clicks, the following command is usefull to run on the remote Windows Embedded XP client:
"Path\to\msvsmon.exe" /anyuser /noauth /nosecuritywarn /timeout:2147483646
The /noauth and /anyuser require /nosecuritywarn. /timeout max value keeps the debugger client from terminating after ~ hour of idle time. If your workday is to be spent debugging you don't want it timing out after a coffee/rebuild all break.
At least two or three times a day Visual Studio gets stuck (in a deadlock I suspect) and displays the spinning-toilet-bowl-of-death cursor and pops up the dreaded "Microsoft Visual Studio is Busy" notification in the notification area:
It used to be that when this happened Visual Studio would stay like that for hours (and possibly until the end of time itself or a power cut) unless I kicked it to the kerb with an "End Process" in task manager.
More recently I noticed another process always seemed to be lurking about whenever this problem arises - Microsoft.PythonTools.Attacher.exe - which is part of the Python Tools for Visual Studio project:
If I kill that process then Visual Studio manages to free itself from whatever deadly embrace it's got itself into and can continue on its way, and this is what I look out for every time VS does this.
Whilst I do have Python Tools for Visual Studio 1.0 installed, the projects I am working on are plain old ASP.NET MVC3 apps written in C#. I'm not using any Python code or libraries and often I only have one instance of Visual Studio running.
What I also observe is that this process doesn't always start/appear for whole development sessions, and when it does, it seems to start up an random times (i.e. it's not there for the first hour or two and then it magically appears in the process list in task manager), but when it does I know I'm going be in trouble at some point.
Does anyone know why this process seems to randomly start and why it's interfering with Visual Studio in such a dramatic fashion?
I'm running Visual Studio 2010 Premium SP1 on Windows 7 Ultimate x64 SP1.
When you do Debug->Attach to Process you'll see that VS displays a list of processes and along with them it displays the types of code that you can debug which are running in those processes. To get this information VS queries the various installed debug engines. So when we get queried we go and inspect a bunch of processes to see what's going on. If it's a 32 bit process life is easy - we can use various APIs to enumerate the modules and try and figure out if there's a Python interpreter in the process. If it's a 64-bit process life is a little tougher because we're running inside of VS and it's a 32-bit process. We can't use the APIs from a 32-bit to a 64-bit process so instead we spawn a helper process to do the work.
It sounds like this helper process is somehow becoming a zombie on your system. It'd be great if you could attach VS to it and send any stack traces back in a bug. But we should also provide some defense in depth and timeout if the helper process isn't responding.
Finally killing it should generally be safe, it's not doing anything stateful, and we'll start a new one when we need it.
If you never use Debug->Attach to Process for Python debugging there's probably a trivial file update to our .pkgdef file which I could track down and post which would make this problem go away entirely.
I recently installed VS2010 Ultimate on my Windows 7 Ultimate 64-bit Edition computer and I receive "An unhandled exception of type 'System.ExecutionEngineException' occurred in mscorlib.dll" randomly (or so it seems) when starting the IDE. If I reboot the computer then about 50% of the time the IDE will start normally. If not, I have to keep rebooting until it finally behaves normally.
I've looked around on various sites and this seems like an error that comes from many different problems ... any idea on why I might be receiving it, or something I should be checking for?
Thanks for any help or advice you care to offer.
Have you checked the system event log? There might be some clues there. You can also try a couple of the VS command line parameters such as Log, SafeMode, ResetSettings.
Another approach which is more advanced and not for the faint of heart is to use Debugging Tools for Windows to start devenv.exe from WinDbg to see what causes the crash by looking at what threads are doing (stack trace, etc.).
Following my last question (see: Problem in hosting ActiveX on Vista (in a Visual Studio 6 C++ application)) I ran into a strange problem. I hope this’ll be a simpler issue to the experts here:
Each time I run certain application like iexplorer or firefox, the Visual Studio 6 suddenly opens up in debug mode with a message “User breakpoint called from code at 0xSOMETHING”.
I can press F5 to continue but the applications run slowly and needless to say I have no wish to debug these applications…
My guess is that when I worked on my VC++ application I placed breakpoints at windows methods like CAxDialogImpl::Create(), AtlAxCreateDialogA() etc’, and for some reason it was kept somewhere.
Of course I now removed all the breakpoints and re-compiled the project but still this keeps happening!
I checked in the tools->options but the “Just-in–time debugging” is not marked.
Any idea?
(I use Visual Studio 6 which I installed on Vista)
Thanks a lot,
Erik
Not sure this helps but anyways:
Try disbaling the default debugger option. (It says Dr. Watson but it depends what you have set as the default debugger)
http://www.bridgetonova.com/2007/09/how-to-disableenable-windows-default.html
Also as per this post Visual Studio 6 is not supported on Vista. Only Visual Basic is.
http://www.itwriting.com/blog/167-visual-studio-6-on-vista.html
You should probably re-ensure yourself that you have removed all calls to DebugBreak() and manual break-points. Also try to ensure that when you recompile you re-register everything to point to the right places (i.e. the activex pointed to by the guid in the registry is actually the latest recompile).
My VS 2008 has a lot of plugins such as Resharper, Syncfusion, Typemock, TestDriven.net and you-name-it. And I am always running all of them on the latest beta versions.
The problem is that this morning the VS 2008 crashed when it was loading Windows Form designers. I think it must be due to Syncfusion ( version 7.2.0.20), or its interaction with other add-ons such as Resharper. Just to be sure, I need to have access to the stack trace before it crashed so that I can get the vendors to fix the problem.
Any idea where the exception trace is logged when VS 2008 crashes, or is there anyway I can obtain the stack trace?
P/S: there is this log switch command in devenv command, but from what I learn, it's only logging the activities, not the stack trace.
If you'd rather not have another instance of VS running in the background, you can use adplus instead. Just attach it to the VS instance you use for dev, and have it create a full dump in case VS crashes. This way, you won't have any overhead while doing your regular work with VS, and in case it crashes you'll have the full context of the crash.
Start another Visual Studio instance, go to Tools -> Attach to a process, and select the instance that should be debugged here. This will give you the ability to break into the debugger when the problematic instance crashes.