After debug, in about 90% of the cases I can't rebuild my solution, because VS keeps the file handle of the old .exe (can't copy the new exe from obj\Debug to bin\Debug). I know that it's VS's file handle for sure, since I checked it with the Unlocker Assistent. Also, I tried the workaround with calling the default namespace the same es the executable, but no luck. Any ideas?
PS: Running it on Windows XP.
Seems to be a bug in VS since 2005. A google search will show MANY posts about this problem that Microsoft has yet to address. It hits me every so often as well when the IDE won't let go of a dll. Unfortunately a restart of VS is required :(
Related
I appreciate that this question has probably been answered before, but I can't find the solution to my problem.
This is that I can't run my C# program by double clicking it in windows explorer. I have tried to run the release and debug versions, but no luck. The program runs without errors or warnings inside VS. I have tried completely rewriting my project in a different solution and it still doesn't work. When I do try to run it, it uses about 75MB in the RAM but then closes. A window comes up saying "Sending information to Microsoft".
Thanks in advance.
Edit:
I've tried making another project with just a form and nothing else
It runs ok inside VS but when I run the executable from windows explorer it launches but comes up with "GUI has stopped working" when you click on the close button. GUI is the name of the app. This happens with all of the projects that I make from now.
It sounds as if you are missing something vital which your EXE depends on. It is present when you run the application from the IDE, but not when you run it from Explorer.
Are you running it from the directory which it got compiled to? This is normally under your project, under "bin\Debug" or "bin\Release". If not, then the odds are that you are missing a file which is in that folder. Copy all the files (and any subfolders) to where your EXE lives, and that should fix the issue.
Another possibility is that you need a file which the IDE can find, but Windows cannot.
Debugging issues which cause a crash without a callstack are always tricky. I'd suggest that you add some logging to your app, so you can see what is going on prior to the crash. If the issue is caused by your code, then logging will help to find it.
Or, even quicker and dirtier, throw up a messagebox before every line. Give each one a unique message, and you can then investigate the code around the area of the last messagebox that you see before the crash.
It turns out, there was a problem with visual studio or windows. I was running a version of windows 10 but after the update that came on the 06/01/16 it works OK now.
My guess is that it was a problem with the universal windows extension in visual studio
Update:
As of about 7 months later visual studio is working very well on my new computer with windows 10. I also use the latest version on vs which may have been my problem Because my old machine was that: old. It may not have been compatible with the latest software.
I am having great problems running the application in the debugger from Visual Studio 2008.
When I'm using vshost.exe, it says:
And when vshost.exe is turned of, it simply states:
Interesting thing about it is that when i do use vshost, debugger is actually started and breakpoint is hit on the first line of the Main().
I tried:
rebuilding the project(s)
removing .ncb, .suo, .user for the projects
repairing Visual Studio 2008
changing the build architecture for the project
... no help there...
Any experience in (trouble)shooting that?
More info: some projects DO work, and one that I have to work on, does not.
I have some ideas such as:
trying to create NEW project, add thing by thing to it and see at what point it will start to miss behave
work it other way around, delete project by item by item to see when it will (if it will) be working OK again.
EDIT (for google, as I see that there are many similar questions on the web):
Errors:
Error while trying to run project: Unable to start debugging.
and
Error while trying to run project: Unable to start program '....\PlayKontrol.exe'
Try upgrading your Visual Studio to Service pack 1, if you haven't already.
Did you restarted your computer? You never know how windows will react to that :).
Also be sure there aren't any keys stuck, like the ctrl or windows key.
Note that the key does not have to be visually stuck, it can be stuck for visual studio and not for the explorer.
The most common source of sudden problems like this is corruption of one of the data files that vs uses to cache information between builds.
You've tried a clean build, but this won't delete everything. A real clean build is: quit vs, delete bin, obj, debug, release folders, delete all generated files in the root - primarily ncb. Do the same for any locally built libraries that you're project references.
The easiest way to do this is if you have the code in source control, as you can rename away your entire code folder and then force a get of all the source.
You often need to do all of these things in one hit to clear the problem.
Less frequently, a reinstall of vs will sort things out (although this sounds unlikely in your case if it is only one project that breaks)
Also think carefully about anything you might have installed just prior to it failing... And remember that some install effects may not occur until the next reboot so it could be days ago. A particular cause of this are automatic windows updates and trial versions of things like the vs 11 beta.
You might try running the application from outside of VS, but have a line of code that looks like this: Debugger.Launch(); where you want your first breakpoint.
I have a rather large .NET 2.0 solution (151 projects) in Visual Studio 2008. Often times when I do a build (even for just one project) in VS I get an error saying that it can't copy one of my DLL assemblies to the output directory because it is in use. I don't have any other processes running in the background or existing debug sessions going that would be using this assembly. If I open up Process Explorer and do a search for this assembly name Visual Studio (devenv.exe) comes up as the only result. Looking at the results Visual Studio has my assembly loaded as a DLL for some reason. Closing the solution and reopening it doesn't solve the problem. I have to completely exit out of VS altogether to get around this issue which is quite disruptive. Does anyone have any idea what is going on? I'm running on Window 7, I don't think I saw this issue on Windows XP.
I am running Visual Studio 2008 Version 9.0.30729.1 SP. I'm also running ReSharper 6 if that matters.
Does anyone have any idea what is going on? I'm running on Window 7, I
don't think I saw this issue on Windows XP.
I run into this problem all the time on Windows XP and its not even localized to Visual Studio 2008. What always works for me is I simply clean all solutions, this gets rid of any file that might be in my system's memory, because of Visual Studio.
Visual Studio keeps any your references in memory, so when one of those references is updated, Visual Studio has to release it from memory. If it really happens more then "once in awhile" then you might look at trying to reduce the number of solutions in your project.
Use the following command and place it in "Pre Build Events" of visual studio:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
Hope this would help you.
Try to disable the hosting process:
Open an executable project in Visual Studio. Projects that do not produce executables (for example, class library or service projects) do not have this option.
On the Project menu, click Properties.
Click the Debug tab.
Clear the Enable the Visual Studio hosting process check box.
Kill process VBCSCompiler.exe and rebuild.
I would guess that the dll is being used by the (ProjectName).vshost.exe process. You might try killing that process and see if that works. Probably not the best thing to do, but it might be easier than restarting VS.
I would try the "Clean Solution" option before you build. This can clean up any extraneous temp files that could be hanging around from a program crash.
I have no idea about why this works, but I had the same problem and when I changed the Starting Project to the project I wanted to build everything worked again.
When I change the Startup project again to the right one I cannot build the other project anymore due to the file being in use, so looks like a bug at the Visual Studio IDE.
I'm using VS 2008. When ever I make a change in my code and try to compile I get the following error:
Error 7 Unexpected error creating
debug information file 'C:\Documents
and Settings\jbezanson\My
Documents\MyProjects\DispatchBoard\DispatchBoard\obj\Debug\DispatchBoard.PDB'
-- 'C:\Documents and Settings\jbezanson\My
Documents\MyProjects\DispatchBoard\DispatchBoard\obj\Debug\DispatchBoard.pdb:
The process cannot access the file
because it is being used by another
process. ' DispatchBoard
Using Process Explorer, it is always devenv.exe that is locking the file. If I run in Release mode this does not happen. It started 2 days ago when I started a WPF application, and since then it happens with every application I work on.
The only info I could find from Google was referring to a bug in VS 2003.
Anyone else have this problem? How do I fix it? It is getting very annoying having to kill the file handle every time I want to compile.
If you have multiple instances of VS open, close other instances (apart from the one you are trying to compile) - this may resolve the issue.
When I have problems with locked files, I use Unlocker. (If you tried everything and it's not working, try this ;)
In case of broken link, here's a mirror.
Have you tried closing VS, deleting obj folder then restarting VS?
I had the same problem this morning and noticed that I had another project open that had a reference to the one that would not compile or debug. I removed the reference (as I didn't actually need it) and it was fine.
I changed the 'StartUp Project' of my solution to a project without reference to the locked file's project.
This solved the issue for me using VS 2010 SP1.
(Process Explorer said msvsmon.exe (started by devenv.exe) locked the pdb file.
After changing the startup project the processes msvsmon.exe and .vshost.exe disappeared and so did the file handle.)
Alex Clark, thank you for pointing me in the right direction.
The only thing that worked for me is to remove the optimizeCompilations="true" attribute from on the compilation element in my Web.Config file.
Compilation time may be a little longer, but it worked well.
To avoid that problem just open the project properties, go to Debug tab an untick "Enable the Visual Studio hosting process"
I had this issue today. In my case, I had just grabbed the data from my company's source control and instantly hit this issue when I tried to compile the project. The issue ended up being that the \bin folder was set to Read Only. To solve the issue, I just made the folder not Read Only.
I just came across the same problem today. And then I realized what went wrong: I had couple of Visual Studio windows opened at the same time, and one of them was in debug mode.
When I stopped debug mode in that one, the problem was solved.
That happens when you have a "fistfull of VS windows" opened.
Right Click The Folder that contains debug .pdb and uncheck the folders read-only propertys then ok. thats it.
This works for me with web projects in Visual Studio Express 2012 for Web:
Press F5 to begin debugging
"Do you want to execute last successful build?" - hit YES
At this point you could try a request - not sure if this step is necessary
Hit the stop button
Recompile successfully
I have solved a similar problem by adding these lines as a pre-build event:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
With proper modifications, it might help your problem.
Since you say you have it on all applications you work on it sounds like a more global problem. You could try and reinit the vs2008 by writing
devenv.exe /setup
Edit: link to command line options
This worked for me. What I done was that close my visual studio and delete the .suo file and then re-open the solution. The locking should be disappeared now. Cheers.
Old topic, but something that worked for me. I had 2 projects in my solution, a class library type project and a windows form project. The windows form project was referencing the compiled binary and not the project itself in my case which was causing the lock. After changing the reference to the class library project, it worked properly.
Not need to restart or delete the file.Deleting will not be possible , you will get error message. Just rename the file and that is enough.
VS2010 will create another file for you as it wont find the origional. :)
I had the same issue from time to time. Usually no problem but once in a while... This particular time, it was impossible to work. I would shut the application down, and even that didn't work most of the time. I saw this post and a person said they had no issues until they started a WPF application. I was playing music (radio station) in the background with Windows 8 "Music" app. I had the idea that it was a Microsoft App built with Visual Studio. Once I stopped playing music, I never encountered the error. If you are reading this, see if you have any Microsoft apps running.
I also had the same issue. Tried all the suggestions above with no luck. I eventually change the Build Configuration from Debug to Release, the solution built...
This problem started occurring for me after changing from Cassini to IIS Express as my platform for debugging.
Cassini was much better than IIS Express but doesn't properly support the Integrated pipeline. IIS Express is hopeless.
This seems to be some sort of race condition in Visual Studio or IIS Express. It is nothing to do with one project locking another project - the locks are coming solely from the activity of the web application's build process.
Anyways, none of the above solutions worked for me. Unlocker doesn't seem to be supported for Windows 8 anymore. So instead I tried LockHunter. What I do is keep the LockHunter app open all day. If I get a complaint about some file being locked I copy and paste the file path into LockHunter then try again. This usually sorts out the problem but sometimes takes a few attempts.
I'm using TortiseSVN for my subversion client on a Windows Server 2008 box and I've got a folder with code checked out into it.
When I go to open the solution file that's under source control Visual Studio 2008 starts and before it can even finish loading the solution from what I can tell Visual Studio crashes. I'm trying to open a solution that has VB code in it. It gives no error messages or warnings. It's just gone.
I have checked the files and they all seem fine. The solution file seems fine when I look at it with a text editor.
This is also Visual Studio 2008 SP1 and I've got all the latest .NET service packs installed.
Has anyone else seen this before and know how to fix it?
Edit: I just did an SVN export to a new directory and it still crashes in the exported directory where there is no longer any SVN attached to it.
Additionally, it crashes EVERY time I try to open the project that came from SVN.
You should be looking at the solution file with an xml editor, at least then you will get some help for subtile flaw's in the formatting or something like that.
You can also submit feedback to Microsoft on the VIsual Studio Connect site, if the bug turns out to be real.
Some commonsense things todo however would be, goto your visual studio command prompt, start off with "devenv /ResetSettings", that often helps isolate any weirdo add-on or something lke that.
Also, try to build clean with msbuild or vcbuild, then build fully with either one (i.e. if vcbuild can not build your solution, use msbuild). That can help by laying out the symbols and such and maybe clear out some corrupted file or something.
You also may have .suo files from your subversion, those are binary files that do contain some settings, it's common for people to accidentially check them in, but they are usually better off being kept on a per-developer basis (not in the source tree). The /resetsettings will likely clear these out also, but you may want to make sure.
You can also double check the path's to all of the assemblies referenced, that your not going from a 32/64 bit host, and the CLR DLL's are in different path's now etc...
One last thing, if your really stuck, you can get a stack trace and debug the crash a bit ;), see where the fault is occuring and search that module online, your'll often find that somebody may have a specific solution.
Oh yeah, also, hooker's can be trickey. Don't trust them for a minute. Make sure you set tsvn's "only load in windows exlporer" option and configure it specifically for what folders on your system have local-svn working directories, this will greatly reduce the working set for their shell extension. On most any system, over time, one program or another (apple irw.exe or adobe pdf-preloader.exe sort's of ad-ware) will try to work it's way into your shell. You should try to make sure your dev box is rather clean from anything hook's, simular to what VladV was saying...
I had a similar problem and I fixed it and afterwards I wasn't quite sure how I managed it.
It basically involved going to the tools/options menu and setting the source control plugin to none. However, I obviously had to have had the solution open in Visual Studio if doing this was to fix the solution, but yet I thought the problem was I could not open the solution.
The only possible scenario would be if I was able to open the solution, but not open any of the projects inside it, hence able to change the source control settings immediately after opening the solution.
Does that make sense?
Try opening your solution and projects files in a text editor, and looking for anything strange.
I once heard of a similar problem: a solution contained SVN bindings created by AnkhSVN, but Visual Studio had no AnkhSVN installed, and failed to open the solution without giving any meaningful error information.