When running the debugger about 50% of the time, Visual Studio 2010 freezes and also locks up my entire machine. I can't even get to Task Manager. Nothing works except my mouse will still move. The only way to recover is to hard boot the machine which takes about 15 minutes each time. I don't have anything else running on my machine at the time except VS, IE 8 (sometimes) and Outlook.
I am running Windows XP on a Lenovo T400 with 3G RAM
Has anyone seen this behavior? If so, how did you fix it?
Thanks,
Rhonda
You don't mention what language your app is but I have run into this with our C++/CLI application on occasion. To avoid it, I changed the Project properties / Debugger and specify "Native" or "Managed" explicitly for the debugger type. The default of "Auto" can get confused.
Also, if you use Application Verifier from Microsoft, I have had VS hang while AV was configured to verify our .exe. To avoid this, we have to launch the app under the debugger as "Native".
Related
When I stop and re-run the debugger in Visual Studio against a Windows Mobile 6 device, the emulator restarts each time making the debugging experience extremely slow. I could understand if I made changes to the code, but this is happening regardless of whether changes are made.
Is there any reason why Visual Studio would restart a new emulator each time? How can I ensure that the debugger uses the same instance of the emulator that is already running?
I figured it out. I had multiple projects within the solution for various assemblies and the emulator type set for each project was sometimes different and thus causing multiple emulators to fire up. When I closed the multiple emulators Visual Studio would then re-start them all next time I went to debug.
I have a VB6 app that loads initially (for a small prompt to enter a license key, only on the first time). It works fine on my machine (windows 7).
I had complaints of it crashing on someone else's machine (both xp and 7), so I made a Windows XP virtual machine. I installed it on the virtual machine, it crashed. I wanted to see where it crashed so I installed Visual Studio on the virtual machine so that I would get a debug prompt. When I ran the program again, it worked.
I am more familiar with C++ and had these kinds of problems, so I figured it was some sort of runtime issue.
I found this VB6 SP6 Redistributable Runtime:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24417
I installed that, and it still wouldn't run.
Any ideas where to go from here?
Edit:
I have tried depends.exe, it only shows MSJava, which I've heard I can ignore. Does depends.exe also show things like .ocx (Active X controllers?) that are required?
Also, from the cmd prompt, %errorlevel% doesn't seem to get populated. Is that a VB6 things, or does that indicate that this is truely a crash and not a user exit?
Open the Visual Basic project and check both "References" and "Components" under the "Project" menu.
Since it is crashing with the VB runtime installed it is likely a component that you have referenced in the project that either does not exist (or is not registered) on the client under test.
This should be a simple fix.
I had the same problem on my windows 7 computer.
I have uninstalled everything, changed my windows theme to Windows Classic.
I changed following properties of VB setup file.
Right click on setup.exe and go to properties and in compatibility tab change the compatibility mode to windows XP SP2. And in settings uncheck the following check boxes.
Disable Visual themes
Disable Desktop composition
Disable display scaling on high DPI settings.
Run this program as an administrator
And have completed installation.
Followed by installing VB 6 service pack 6 from here.
http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=24417
Hope it helps.
It may require something else other than just the runtime, have you tried viewing it with dependency walker http://www.dependencywalker.com/ on the machine that it crashes on?
It should quickly point out any missing references.
Maybe try again, create a new VM, but install the remote debugger instead of the full VS.
You should create an installer for your application. There may be more dependencies than just the VB6 runtime. A good installation tool will detect at least some of necessary dependencies for you. Have a look at this question or this question
I am running XP SP3 at home (yes, I know) and am running VS2010 Ultimate Edition SP1.
I am attempting to run a profiling session on a Winforms app.
The first thing that happens is that I get told,
Unable to open profiler driver, would you like to upgrade credentials of [account name]?
My account is already an admin account, so I'm not sure what other options I have.
The second thing that happens, regardless of what I do, is that I get message VSP1398:
The monitor was unable to start the VS performance driver. An instance of the service is already running.
But as far as I can tell no such instance is running. If it is, it must run for mere microseconds and then shut down.
I've tried a handful of things: checking what version of .Net I'm targeting, changing the target CPU to x86, turning off my AV software. messing around with the security settings on the project. I get the same response every time.
I've tried doing a repair install, too, but that didn't change anything.
Any ideas, anyone?
When i debug apps on windows7 using VS 2005, it's very slow. just general slowness. works fine on xp.
running outside of the debugger is normal. Even when i start apps outside the debugger then attach and debug it is normal.
im running VS 2005 in Vista compatibility mode.
Any idea what i can do to prevent slowness when debugging?
Seems like the problem happens periodically and is related to the amount and location of breakpoints set in the debugger. The problem can be worked around by attaching to the process after starting it.
For a complete solution, probably need vs2008.
Recently, my coworker and I upgraded our development environment to Win7 x64 with VS2010 Pro. Our application is specifically targeted at x64 platform.
The problem we are encountering is during debugging, when attempting to step through the code (F10), at least 50% of the time VS will simply lock up the application being debugged. The IDE has the appearance of having pressed F5, but the application is not responsive and we have to force stop the application.
Our application is a Client (GUI) and a Server that communicate through .NET remoting.
This is starting to directly affect our productivity, so if anyone has any ideas what may be causing this, please let me know.
There is an outside chance that it might be the debug symbols loading. Check the status bar I think it tells you when the symbols are loading.
This may be a moot point, but have you installed the VS 2010 service pack 1?
There are various bugfixes related to debuggers included.
http://support.microsoft.com/kb/983509
I had a similar problem. it turned out that a higher level program had a different run-time library (multi-threaded debug dll), while my app was simply a multi-threaded debug. Once I converted mine to a multi-threaded debug dll, the freeze stopped happening.