VS2010 express will not run anything in debug mode

Question

I have a very anoying problem with Visual Studio Express.

The problem is that nothing will run in debug mode.  I click the little green arrow and nothing happens.  Or I get an error in the error list:  Unable to copy file "obj\x86\Debug\project1.exe" to "bin\Debug\project1.exe". The process cannot access the file 'bin\Debug\project1.exe' because is it being used by another process.

The problem suddenly started appearing a few days ago and I now cannot use the language at all.

There are inquiries in many places about this, with all sorts of odd seemingly bizzar fixes that work for one person and not others, including reinstalling Windows, or altering system files.  The problem has been there since at least 2005 and still going with no solid solution.  I have not found anything that works.

Some people unknowingly suggest that it could only be bad code, only to be disproven by empty project with the same problem (an empty project for me though, runs fine).

I have turned off my antivirus with no effect.

There doesn't seem to be any fix for this, and much to the frustration of many people Microsoft has not offered anything that helps.  That is, on the forums I have been reading, including some threads in this forum.  So I thought I would give it another shot before I abandon visual studio as a viable option for these projects.  Unfortunately there are several other projects written in VS that are now stalled because of this problem.

At this point, after tens of hours on this to no avail we are defeated and completely dead in the water with VS.

Has anyone found anything that works across the board for this?

Windows 7 64 bit, VS2010, VB Express, Windows Form Applications

Thanks in advance if anyone knows anything.

Answer 1

I don't have a patent remedy, too. I'd first find out which process is locking the file. Start Process Explorer, press Ctrl+F and enter project1.exe. Which process locks the file?

---

Armin

Answer 2

(Supposing you've done a reboot, etc...) The first thing I'd suggest is to try running: devenv /resetsettings

This will revert any customization or odd settings that may be causing a problem.  Often, an invalid configuration file can cause VS to behave strangely, and this will correct it.

---

Reed Copsey, Jr. - http://reedcopsey.com
If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

Answer 3

Well, the devenv command executed against vs2005 which I had previously installed on this machine.  So I uninstalled all obvious vs2005 programs.  Then devenv could not be found.  So I did a reinstall of vs2010, which mostly worked, except that in a couple of cases it can't write to it's own files that it created in config.msi (the backup dir the installer creates).

Not sure where devenv would be, but I can't count on something that didn't install flawlessly.  So I'm going to try uninstalling everything VS, re-downloading vs2010, and reinstalling.  Then we'll see if devenv is there and try that.

Armin,  the process that ProcessExplorer seems to be showing tied to the project are:

System, svchost.exe, csrss.exe, project1.exe, vbexpress.exe

That's while the project is running.  But, let's see what happens after the reinstall.

You may be wondering how I can get it to run?  If I close VS2010, then run it, load my project again, then hit F5 or the green arrow, it will run as many times as I want, as long as I don't edit anything.  If I go into any of the code and so much as type a space, then backspace (so it really didn't change anything) and not even save -- it will not run again for several minutes (if at all).

Will be back after the reinstall.

Answer 4

I uninstalled everything VS, then re-downloaded and installed VB express.
There is no devenv executable anywhere.  There was when I had the full VS2005 installed.  So I think that command is only with the full VS, not express.  However, I did execute from the menus:  Tools.Settings.Reset, which may be somewhat equivalent.

However that did not change any of the offending behavior.

I've been watching the ProcessExplorer to try to determine what is happening, if not why.  The hook seems to be when I change any code.  I can run the code over and over again as usual.  But when I change anything, even just a space then backspace (no change), and I don't even save it, then hit F5, I get the error.  So I've been trying to see what process this involves, and haven't been able to glean anything meaningful.

I think the changing of code is a flag where VS knows to recompile the code because I changed something, and that's when it runs into the file lock (which is itself).  The file lock is from any previous run of the code.

So this explains why I can restart VS and run the first time.

VS holds the file lock for a few minutes.  In some cases, much longer.

But this is a production killer of course, as I usually re-run after small changes in code to test as I go along.  So I am not able to run any code any more often than every few minutes on it's "good" behavior, to not at all on it's worse behavior.

The process "System" is what has a handle on the file: C:\Users\John\Documents\Visual Studio 2010\Projects\PersFS1\PersFS1\bin\Debug\PersFS1.exe.
(In previous posts I called this Project1, to be generic.  The actual name has always been PersFS1.)

Answer 5

Unfortunatelly there's not much I can add.

There's the "visual studio host process" setting in the project properties.

If enabled:
If the application is not running, there is NO lock on project1.exe, only on project1.vshost.exe. The locking processes are the same as on your machine. If I start the app, only project1.vshost.exe holds a lock on project1.exe. After closing the app, these locks are freed so that no lock is held on project1.exe.

If disabled:
If the app is not running, project1.exe is not locked, but it is locked by the mentioned processes if it is running.

"I think the changing of code is a flag where VS knows to recompile the code because I changed something, and that's when it runs into the file lock (which is itself)."

Yes, it's not running but compiling (or trying to compile). Even if you don't save manually, it's usually saved automatically before compilation if you change anything (behavior depends on IDE settings; menu tools->options).

---

Armin

Answer 6

Yes, the hosting checkbox was one of the many suggestions I had tried, with no effect.

Very strange problem here.  Many people having the problem.  Its been a problem since at least 2005 - its all over forums once you figure out what to search for.  So many suggestions out there that have worked for one or two people and not others, and Microsoft seems to be completely stumped on this one.

We are considering moving all our projects to another programming platform, but that is a huge undertaking.  But we do need something we can count on.

Answer 7

Hi Jwadew8,

Is this scenario still appears when you debug a new created project? If it still occurs, I will move this thread to VS debugger forum. If new created project debugs well and have problems in current project, could you please provide some quick steps to reproduce this issue?

Moreover, I'm not sure if you've read the following links which may be helpful:

http://stackoverflow.com/questions/2690119/visualstudio2010-debugging-the-process-cannot-access-the-file-because-it-i

http://connect.microsoft.com/VisualStudio/feedback/details/688789/unable-to-copy-file-obj-x86-debug-exe-to-bin-debug-exe

Thanks in advance.

Best regards,

---

Shanks Zen
MSDN Community Support | Feedback to us

Answer 8

Thanks Shanks,

I certainly appreciate any and all qualified suggestions.

After your post I did look at those two threads.  They didn't resolve my issue, but are typical of the problem, where something that fixed this for one person, does not for others.

A new project in VS does not have the issue.  However, at least one project that formerly had no problem, now does, without changing anything in the project.  The only difference is that since the last time I worked on it, maybe a couple of months ago, there have been the usual updates from Microsoft, and there may have been minor software installed.