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.
Related
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 am developing an application using Visual Studio, and when I install it (via Setup Project, .msi file) in a client machine and run it, I get some "Heisenbug" exception.
I am almost sure the error comes from earlier in the codepath, so I would like to debug it.
Fact is: when the application crashes, the following dialog is displayed (referring to my application instead of Windows Explorer, of course):
and if I choose "Debug the program", the Visual Studio Debugger (which is somehow available in the deployed machine) starts and shows details from the exception.
What I would like to do is to start the debugging session from the very start, so I can go on hitting F10 and F11 and check some intermediate values.
Anyone know how can I start the Visual Studio debugging session at any time while the application is running? Not that I am running the deployed application, not starting it from Visual Studio.
Since you have Visual Studio up and running on the machine running the deployed application, it should be straightforward:
Run the application
Load the project in Visual Studio
Go to DEBUG -> Attach to process...
A list will pop up with all the running processes
From the list, pick the process corresponding to the application, it should be named after your exe (if you sort by the numeric IDs, it's very likely it will be near the highest end)
Click "Attach", Visual Studio will should start debugging similarly as when you normally start with F5.
I also have another suggestion: implement heavy logging until you have everything figured out. Write down everything you have doubts about for further analysis in case something goes wrong: values, queries, etc.
You can start the application directly under the Visual Studio Debugger using the debugexe parameter:
devenv /debugexe “C:\MyApplication\Debug\MyApplication.exe”
This will launch the application with the debugger immediately attached. Otherwise it's very hard to debug issues that happen at the time the application is starting. You won't be able to manually attach in time to catch any events that happen during this time.
You can also place the following piece of code at the first line of you application (usually the Main(string[] args)) to force a debugger to attach and cause the application to break immediately:
System.Diagnostics.Debugger.Break();
If your application starts and runs fine for some time, you can use the "Attach to Program" feature as described by #Alex.
If you don't have the sources available on the target machine, you can either copy them over, or if you're using Source and Symbol Indexing features of TFS Team Build, you can tell the debugger where to look for your Debug Symbols (which will then resolve to TFS source control automatically).
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.
I wrote a WPF application in C# using VS 2010. The application will run fine in debug mode using Visual Studio, but when I go to run the .EXE from the bin\release folder, nothing happens. I do not get any error messages from windows and there are no errors or warnings in VS. I have tried to build, rebuild and clean the solution (in every possible order) with no luck. My solution contains 2 projects, both of which use .NET 4.0 framework, and I have .NET 4.0 installed on my PC. I have tried on both XP and Win7 and still nothing.
I also just noticed that the output from Debug when I run the application in debug mode says: "Cannot find or open the PDB file" after each .Dll it loads.
I am compiling to the Release folder every time, but i did try changing it to the debug folder and clean/rebuild just to see if that would make a difference, and it didnt, so I changed it back, tried it again, and still nothing.
Any Ideas?
Here are a couple of ideas that come to mind
If you are on a x64 machine, try changing the application from being AnyCPU to x86. This the mode that applications default to in debug mode and it's possible an issue running in x64 is causing a problem in release builds
Possible the Release binaries are out of date. Delete the binaries from the Release folder, rebuild and run the newly generated runs
Run the release build under the debugger in Visual Studio and see if it till crashes
I was experiencing the above issue too, however none of the other solutions worked for me.
My Application logs in Event Viewer listed event ids 1018 and 1022. This appeared to be bizarrely related to an ASP.NET 2.0 dll (bizarre; as this was a blank WPF project only). The logs contained messages like this:
Windows cannot open the 64-bit extensible counter DLL
ASP.NET_64_2.0.50727 in a 32-bit environment
In the end it turned out to be resolved when I disabled my anti-virus. I had read that this resolution worked for someone with McAfee; and it also worked for my environment, which has Avast.
I assume you tried on a machine that doesn't have visual studio installed, and also none of the components you are using for development.
You have only one option: start the application with a debugger on the machine that causes problems and check for exceptions there. (use WinDBG for example - it's light and easy).
This looks like a problem with missing dependencies, but might be something else also.
The Debugging Labs should give you enough information on how to use windbg to find your problem:
.NET Debugging labs
Also use this:
WinDBG Cheat Sheet
(JaredPar) answer looks right (x64), but if not try right clicking on the EXE and running in admin mode for win 7.
I had a very similar issue.
Check out this setting on your App Pool entry:
Go to Advanced Settings.
Change 'Enable 32-bit Applications' to 'TRUE'.
This worked for me!
I'm going to go with a wild guess that:
Either you have some odd corruption in your .NET Framework installation
There is some debug/release-specific code using #if DEBUG or the such that is substantially different to cause issues.
You have not compiled recently into Release yet (Try changing it to Release before compiling your latest code and make sure you get no errors).
Those are the only things I can think of off the top of my head.
I had run into a similar issue, I was missing a custom folder in the release mode I was referencing in the constructor. Adding the folder to the release fixed the problem.
Visual studio team system 2008 keeps crashing on me. Sometimes it just freezes, or certain parts of the UI get messed up or a weird popup box saying something about unable to load parameters or saying something else about memory or any other number of things.
it usually happens when I do a "complex" task like go into debug mode or do a search across of whole solution or run a unit tests or something like that.
I rebooted my machine countless time, reinstalled it VS, changed my virtual memory settings, flush my page file on every reboot and anything else i could think of.
It seems like VS runs out memory or something.
I have a powerfully machine with lots of RAM so that's not the issue
any suggestions?
You can always try some standard Visual Studio troubleshooting steps:
Clean the solution
Delete / rename all files in your solution created by VS, i.e. all .ncb, .suo, .user files
Launch Visual Studio with all add-ins disabled: devenv.exe /SafeMode
Reset All Settings: Tools -> Import / Export Settings -> Reset All Settings
Delete HKCU:\Software\Micosoft\VisualStudio\9.0 and then restart Visual Studio
Repair the Visual Studio installation through Add/Remove Programs
You might also check whether there is a hotfix available addressing your issue (e.g. KB960075 sounds like a good candidate for you), or whether you find your problem already reported on the Connect website.
The first step is to uninstall all 3rd party add-ins on Visual Studio. In particular if you have multiple add-ins as they can interfere with each other in unexpected ways and cause crashes. After uninstalling repeat your scenarios and see if this fixes the issue.
If not then it's best to consult the application log and find out why Visual Studio is crashing. The log will contain at least the error code of the crash which can searched on google or reposted here for us to take a look at.
Assuming this occurs with VS up to date with all service packs installed, you might try some of these suggestions. If you haven't tried with service packs, do that first.
What version of Windows are you using? If it is Windows 7, try launching Visual Studio with a compatibility mode and see if that resolves the issue. To do this, make a copy of the normal launch shortcut and go into the Properties dialog and set it to run as Windows Vista.
If this doesn't fix it, then you might also consider:
Checking your PATH environment for any weird settings which might be confusing it, e.g. paths pointing to other SDKs
Any 3rd party VS extensions such as source control, refactoring plugins, wizards etc.
Old versions of .NET or SQL server
Also test if the issue occurs for every kind of project or just certain kinds, e.g. does it happen for all projects? Does it happen in C++, C#, VB.NET projects etc.
You can also attach a debugger to Visual Studio, to see what it's doing. Sometimes a particular .sln will trigger bad behavior or more likely, some third-party add-on.
If you believe that you've gotten VS into a wired state, you can try the following command line switches
devenv.exe /ResetSettings (This will reset the visual studio settings to the defaults)
If that doesn't help, as a last resort, you can try
devenv.exe /ResetUserData