I am using VS 2010. While debuging my C# website, if there is any run time error, my debug internet browser will crash and only the triangle on the left-bottom roughly shows the error info. Previously in the normal situation, my VS could stop at the code where this crash happens in case of run time error occurs.
Is there any setting in VS that I can restore this feature? BTW, I installed Just-Code but disabled its add-in in VS, don't know if this software caused this problem.
Thanks,
Wei
In VS, in the toolbar click on the Debug -> Exceptions.
Then check the Throw checkbox for the Exceptions you are interested in.
Check out is Silverlight debugging is turned on for the project by mistake. You can debug either JavaScript OR Silverlight.
Related
In VS2015 and earlier, when you started debugging a web application or site, it opened IE (or edge) or even chrome to view and test your project. When you closed the browser, the debugger would stop and when you stopped debugging the browser would close. In VS2017, this behavior does not happen. I find myself leaving tons of browser windows open all over the place. I would much prefer if it would simply behave as it did in VS2015 and clean up after itself.
I am sure there is a reason for this but I cannot fathom it. Is there a way to get this behavior in VS2017?
It is not a bug/issue this is a feature you can disable by inside Debug -> Options you can disable it now.
The shop where I work is currently using VB6 for development using controls and libraries. Someone once showed me how to use Visual Studio to be able to debug this code by simply creating a console application in C# and then changing a few options. He showed me this in VS2010, but I am now using 2015. When I go into the project properties and go to the Debug tab, the option for "Enable unmanaged debugging" is not there. Did Microsoft remove this option? I have searched the web quite a bit, but have had no luck finding a solution.
Also, for kicks, I also have 2010 installed on my machine. The option is available there, however when I attempt to run and debug I get a LoaderLock failure. After researching it I found that I have to disable the exception in Visual Studio. However, it would appear that my exceptions are locked down and I cannot change them as they are all greyed out. I am an administrator on the machine I am using, but I am unsure of where or what I need to change to enable me to change the exception settings.
Any recommendations on either issue would be greatly appreciated. It's not a show stopper for me, but a HUGE inconvenience.
I have updated Visual Studio 2015 to the first update. Since then I cannot debug my code twice in a row. It goes like this:
I start VS and try to debug. So far OK
Change code, build and debug.
Try to reach a web but it never loads.
If I close the VS and load the solution again it works or If I do not change code in step 2.
Other thing I noticed is the IIS Express Worker process is consuming most of CPU time.
And apparently the symbols are not loaded (I do not see the messages of DLL loading in the status bar).
This is making my development process very slow and tedious.
The solution is a MVC project under 4.6.1 framework.
Any ideas? Thank you very much!!
You should boot Visual Studio into Safe Mode. To enter safe mode do the following:
Open Command Prompt, as Administrator.
Enter: cd C:\Program Files (x86)\Microsoft Visual Studio 14.0
Enter devenv.exe /safemode
If Visual Studio does load and debug, then more than likely an extension or an update is the culprit. This will allow you to also see which updates may have occurred. The other potential issue would be if your Internet Information System had an issue.
Otherwise if your Internet Information System is stuck 'on'.
CTRL + ALT + DELETE
Go to processes, end W3P process.
Try to launch and debug inside Visual Studio.
Otherwise, simply try restarting your computer. We would need more information, as this can occur for an assortment of reasons.
#Julen - I have the same issue as you and I have found a work-around.
Add the "Terminate all" button to your toolbar and use it instead of just stopping the debugging. This command kills the IIS Express process.
See how to add it here:
Automatically Kill IIS Express Process After Debugging (VS Express 2013 Web)
If your IIS doesn't shut down after stopping the debugger, you could do one of the tricks written in this blog post - but the opposite way because the article focuses on keeping the debugger on.
Here is the proposed solution 2 - to check "Enable Edit and Continue":
Similar to VS 2013, if you disable Edit and Continue IIS Express will continue to run when you stop your debug sessions.
Open the menu item Tools/Options, look for the Debugging/General option. Scroll down and uncheck “Enable Edit and Continue”
It might be hanging when trying to load external symbols. I had a problem with that before.
To test this theory:
Open the Tools menu.
Click 'Options'.
Find and expand 'Debugging' on the left.
In the 'Symbol file (.pdb) locations' list, uncheck everything.
Click OK and see if the problem reappears.
I have a relatively large C#/WPF Visual Studio 2008 solution that I am trying to test and synchronize across 2 developer's computers. On my computer, I am able to build and debug (run) the project successfully without errors.
On the second computer, I am able to build the solution without any errors. When I attempt to run the solution, Visual Studio starts the process but about 3 seconds later the entire development platform exits. Before it exits I briefly see one of our .xaml files opened by visual studio with a yellow 'unhandled exception' box pop-up on a certain line number. I'm currently contacting the part of my company who is responsible for implementing the functionality of that xaml file.
This raised a bigger issue in my mind: How can you troubleshoot an issue when Visual Studio is immediately exiting after attempting to run a program?
The Visual Studio 2008 crashes when starting to debug post may also be helpful. I'm trying those solutions now.
We found that executing the three following commands helped to fix our problem:
devenv.exe /ResetSettings
devenv.exe /ResetSkipPkgs
devenv.exe /Setup
This was suggested in another stackoverflow post here helped us to determine that it was a plugin, AccuRev's Visual Studio plugin, that was causing the issue.
The issue also appears to be a "known issue" with a hotfix from Microsoft, documented here.
VS2008 SP1: In Visual Studio 2008 SP1, having windows in non-default locations, for example after docking and undocking windows, when switching between debugging and designing or switching to/from full screen, can result in a crash of the Visual Studio IDE.
Thanks for your help!
Run devenv/debugexe to debug your exe. When an unhandled exception occurs, in the debug menu, select "save as dump", then visit http://connect.microsoft.com/visualstudio to open a bug report and attach the dump file after creating the report.
I just migrated to Windows Ultimate 64 SP1, because my system's hard drive crashed. I installed Visual Studio 2005 SP1 and all the patches that Microsoft has recommended. I finally got my source code from my SCM, but now debugging does not stop on any of my breakpoints I have set. This is just a plain Winforms app, nothing fancy.
The first thing I did was to change the build target to x86. No dice. Then I went and downloaded Debugging Tools for x64, still no dice. I set the debugger to break on all exceptions both handled and unhandled. No dice either.
I've been looking at Google search results, but no luck there either. I've been at this for 3 days now with no luck. Has anybody dealt with this issue before?
Update:
The projects are all set to Debug (x86).
Breakpoints stay normal when the debugging session starts.
I already did a re-install, and that didn't work either.
I am running as Administrator and turned off UAC.
I attached to the project using "Attach to Process", and I was able to step into the code that way. I'm hoping to find out why it is not auto attaching, in order to avoid having to do this manually every time.
This is listed as a known issue for VS2005 on Vista (Via MSDN):
Title: Just-In-Time (JIT) Debugging of
an elevated process will fail
Description: Elevated processes cannot
be JIT Debugged by VS 2005. This
includes system processes, such as
IIS, and applications started by
selecting ‘Run as administrator’.
Workaround: The debugger must be
attached manually before the debugger
will catch unhandled exceptions or
user break points
(System.Diagnostics.Debugger.Break,
__debugbreak, etc).
Couple of questions.
When your code fires up, does the breakpoint become an empty circle with a tooltip that indicates that the breakpoint won't be hit? Or does it become a full circle with a tooltip that indicates the process it's attached to?
You can try manually attaching the debugger to see if you get any traction that way. Just fire up the app and once it's running, go to the debug menu and choose "Attach to Process" - select the process that your app is running in and click "Attach".
I run Vista64 w/o issues - VS2008, though.
I am using Visual Studio 2005 with the same patch level on both Windows Server 2008 x64 and Vista x64 SP1 without any issues.
Are you running it as admin? When all else fails, try uninstalling and reinstalling.
Insure that the project is set for a debug compile and not a release compile, as the release compile doesn't contain your debug information.