I'm working in VS2010 with a solution with lots of projects and it is constantly becoming unresponsive.
One thing I've noticed which may be a clue is that MyApplicationName.vshost.exe is constantly popping up in the process list despite the fact that I have not started any debugging. It could be happening whenever a build takes place perhaps?
I'm not launching the application from within VS at all. I'm just executing it from within the bin directory.
Killing the vshost.exe process seems to often cause VS2010 to become responsive again.
Any ideas why this process could keep getting spawned?
Thanks!
In your project properties, try unchecking the following box in the Debug tab:
Enable the Visual Studio hosting process
Related
For some reason I just started having an issue with my release builds.
I'm able to run any of my projects without issue from the debug builds, I can also run my release builds as long as I attach a debugger, but when I try to run the release builds on their own they either hang infinitely (The UI crashes, but I'm unable to stop the process with task manager), or they load up EXTREMELY slowly (I've only ever had them eventually load twice, and that was on a separate machine from my main PC).
I know I don't have any viruses or any other system issues (I take very good care of keeping my system extremely clean), and I've tried running the programs with AV disabled.
Nothing I do seems to make a difference, and the fact that debug builds of my projects perform exactly as expected leads me to believe somehow I've altered a setting in VS regarding how it builds releases or something similar.
Could this be the case? If so, how should I go about fixing it?
If you need any more information please let me know.
EDIT: Something else I've just noticed about this issue is, the only time I'm able to run any of the executables I've built is if they are in the bin\debug\ folder of my project. That includes copying the "release" build of my project into the debug folder. It then runs just fine. I've also tried building an installer for my project, and it also will only run while in the debug folder, and nowhere else on my system. Doesn't seem to matter whether it's a release or debug build, as long as it's in that folder.
I ended up doing a complete uninstall of Visual Studio Community 2015 and all of the runtimes/etc. that were installed on the same date as VS, and reinstalled the program.
I then deleted all of the debug/release builds for my project, cleaned the solution and rebuilt them.
So far everything seems to be working okay now.
I'm not sure what the issue was, but a fresh install seemed to fix it.
Currently I am developing a global exception handling in a .NET C# application. I get some strange behavior:
If I debug the application from Visual Studio (F5), an unhandled exception causes the main thread to be terminated.
If I start the application without Visual Studio (click on the .EXE) with the exact same compile output (DEBUG-Build), the App doesnt crash after an unhandled exception occured.
This is kind of weird behavior...Does anyone know what's going on here?
EDIT:
It seems as if something changes within the running code as soon as a debugger attaches to the process... If I start the App without Debugging from within VS, the App doesnt crash.
I’ve been doing some work with ASP.NET MVC but was having periodic issues with Visual Studio 2008 hanging (freezing / becoming unresponsive) when I tried to run my web application with debugging. The problem only occurred with a specific web project.
I tried deleting the Temporary ASP.NET Files (%userprofile%\AppData\Local\Temp\Temporary ASP.NET Files) but that did not solve the problem.
I tried deleting the obj folder. No luck.
I tried waiting it out one evening. I eventually feel asleep and when I awoke sometime in the middle of the night, my web app was happily waiting for input and Visual Studio debugging was completely responsive. That proved to be a temporary salve.
showallfiles The problem resurfaced again a few days later and I finally figured out the problem with my uncooperative debugger. I have a folder containing approximately 20,000 images that are not included in the Visual Studio web project but are sitting in a directory in the web site. I had turned on "Show All Files" in Solution Explorer to add some script files into the project. When "Show All Files" is off, F5 (Start Debugging) works like champ. When "Show All Files" is on, Visual Studio becomes unresponsive. In reality it is not "frozen" but simply taking a very long time to process those 20,000 image files.
Mystery solved.
I'm running a web application with models defined in C# and views being in HTML5, client-side business logic is JavaScript/jQuery. I've noticed something odd recently. Whenever both Visual Studio and my web application are running simultaneously, the browser memory usage starts to climb. It is worse in IE and Chrome, but likewise substantial in Firefox (all the latest versions of these browsers). Also, the memory usage of Visual Studio starts to climb. The CPU usage for the browser hovers in the teens, normally hovering around 0 otherwise.
Once I close down either the web application, or Visual Studio, the memory stops growing, and indeed, closing Visual Studio often allows the browser to run its garbage collection and clean up the mess. I suspect this has something to do with some sort of background debugging going on. I'm surprised that googling this hasn't turned up a similar issue for somebody somewhere in the world, and I suspect it's some kind of configuration setting in my IDE. Visual Studio 2013 Premium. I've reset my settings (Tools -> Import and Export Settings -> Reset all settings, with no effect. Building in Release mode likewise seems to have no effect. I'll keep hunting this one down, but has anyone here seen anything like this and resolved it?
edit: I have recently been debugging some dynamic code using the debugger keyword. I've commented that out, and am still seeing the same results. But I wonder if there isn't some lingering effect from using this in the first place?
edit: Updating Resharper from 8.2 to 9.2 didn't help either.
edit: Apparently this issue has been seen before and reported, if you just know what to google for.
Visual Studio has a browser link feature that causes the web app to poll Visual Studio in case you have changed a file.
In VS there is a small refresh icon in the debug menu with a drop down. In there you can disable this feature.
Did you trying running the application without debugging? (Ctrl+F5)
To enable VS debug the browser more info is needed specifically things like scripts and eval code are needed even after use. So, running the browser with debugging enabled will use more memory and cause memory to grow with time.
I use unmanaged dll with P/Invoke in this app, and I always tested it inside Visual Studio (with debug mode on x86 CPU because the dlls are only x86), and it works just fine. But when I just start the exe manually after some time (probably at the first operation with those dlls, but I don't know exactly) it says the exe has stopped working, and it starts checking for solution (I use Visual Studio 2013 on Windows 8.1, if that matters). I tried to add the dlls to the project as existing item, but that doesn't help. Also I know, that it's not because it can't find those dlls, cause if I delete them, it doesn't crash, just freeze without any error message. Shouldn't it work the same from Visual Studio as manually started?
There is also a weird bug when I run from Visual Studio: everything's work fine, but sometimes Visual Studio just suddenly stops debugging, as if the program were closed and the GUI of my app freezes, and I can only close it by closing Visual Studio (as I close it, the GUI disappears). Maybe it's a totally different problem, but it can be connected.
Edit:
Here's the project on github, if somebody could check it:
https://github.com/geiszla/CycriptGUI
Some news: If I run it with Ctrl+F5 it also crashes. What's the difference between F5 and Ctrl+F5, that can cause this problem?
Searched all over Google with no real simple answers. Here it is folks(at least it worked for me and is simple):
When you run the console app in Visual Studio, look at the output window at the bottom, get the location of the ..\bin\Debug\*.exe
Copy the *.exe and the *.config to your desired folder, run it, it should work the same way in Visual Studio.
Thanks for every help, my problem was solved: I called an unmanaged function with only 2 parameters, while it had 3. However I still don't understand why it worked with debugging mode, and not without debugging.
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.