When running my solution in debug mode, IIS Express and Internet Explorer as the browser, I get the following error:
The program '[12604] iisexpress.exe: Program Trace' has exited with code 0 (0x0).
The program '[12604] iisexpress.exe' has exited with code 0 (0x0).
I'm using Visual Studio 2017. If I change to Chrome, I do not get this.
The only way to resolve this and still use IISExpress and IE is to go into my properties of the web project and uncheck Enable Edit and Continue under Debuggers.
Any idea as to why?
Try any of the following fixes....
Clean + Rebuild Solution
Restart Visual Studio
Run Visual Studio as Admin
Restart Computer
Launch Without Debugging
Ctrl + F5
Step Into Debugging
Hit F11 to start debugging by stepping into the first line of executed code. If that works, the problem is likely in your code somewhere (possibly an ehem StackOverflow Exception)
Break on CLR Exceptions
If there is a problem with the code on startup, you should break when thrown
Go to Debug > Windows > Exception Settings (Ctrl + Alt + D)
Select Common Language Runtime Exceptions
Change Project Port
Go to Project > Properties > Web > Project URL
Try using 8080, but any change might work
Create Virtual Directory
In the above screenshot, select Create Virtual Directory to the right of the Project Url
Delete .vs folder
Open the Directory where the solution / project lives.
Make sure hidden file are visible, and delete the .vs folder
Restart IIS Express
In the system tray, right click on IIS Express and select Exit
Enable 64 Bit IIS Express
If you're on a 64 bit machine...
Go to Tools > Options > Projects and Solutions > Web Projects
Select Use the 64 bit version of IIS Express...
Check Event Viewer
Check for any additional diagnostic information in Event Viewer under Windows Logs > Application
Run IIS Express from cmd line
You can rule out if there's an issue with Visual Studio or your Web Project itself.
Here's the docs on Running IIS Express from the Command Line
Pass in the path to the root of your project (where the web.config) is located
> "C:\Program Files (x86)\IIS Express\iisexpress.exe" /path:C:\repos\project\
Download IIS Express
Get the standalone installer for Internet Information Services (IIS) 10.0 Express and try again
Disable Edit and Continue
Go to Project > Properties > Web > Debuggers
Deselect Enable Edit and Continue although this will remove that functionality
Further Reading:
ASP.NET MVC5/IIS Express unable to debug - Code Not Running
IIS Express crashes when starting a site from visual studio
Unable to launch IIS Express Web server
I ran into this problem today. I had forgotten that I had set my application to a single instance application and I already was running another instance of the application in the background while I was trying to start another program instance.
To fix the problem you just have to open the program properties tab and uncheck the Make single instance application checkbox temporarily or close the same application running in the background.
My situation was too interesting. I tried all solutions of KyleMit but it didnt work.
So when i looked back to my previous commits in one of my service method i saw an action like this :
public List<Master> GetActiveMastersByCity(int cityId)
{
return GetActiveMastersByCity(cityId).Where(x => x.MasterStatus == MasterStatus.Active).ToList();
}
as you see there is a mistake in my method because in the scope the method name is wrong. it seems i tried call another method like GetAllActiveMastersByCity but i typed GetActiveMastersByCity is the same as my current method.
To be frank, this is too interesting adventure in my .net core story. Because its compiled and runned already and i did not understand absolutely why is this issue related with iis.
Hope it will helps you all.
I've come across an extremly annoying bug this afternoon. I've been working casually on console application I'm working on for a while now and for no reason at all the VS2012 debugger started hanging when I quickwatch any variables. It hangs for like 15-20 seconds, then I get the message
Function evaluation is disabled because a previous function evaluation timed out
If i then hit F10, the debugger unattach and the process goes on. It crashes on almost every variables that are implicitly declared
Here's the steps I have taken so far to resolve this problem.
Steps I have taken:
Restart VS
Reboot computer
Deleted all breakpoints
Deleted ncb and suo file
Symbol Server is not enabled
No Network location is used, User files are local, project files are
local.
Just My Code enabled/disabled
Ensured Enable .NET Framework source stepping is NOT enabled
Ensured Step over properties is enabled
Ensured Enable source server support is not enabled
Start visual studio with /SafeMode to suppress extensions
Cleared Watch Window (was empty anyway)
Tried changing target platform to x64 and any CPU
Disabling antivius
Resetting visual studio default settings(devenv.exe /ResetSettings)
Reinstall VS
The application I'm debugging :
Type : C# Console application
Target Framework: 3.5
Platform target: x86
For my health sake, please help.
EDIT : I have Visual Studio Update 3, version 11.0.60610.01
EDIT: My computer specs
Windows 7 Ultimate 64 bits
Dell Optiplex 960
Intel Core i5-2400 3.1 Ghz
4 GB RAM
EDIT : I tested on two machines (same code) without visual studio update 3 one that does work, one that does not.
EDIT: A created a simplified console application with the same settings that contains only the following lines of code. I'm getting the hang problem when I watch and then it unattach also. What could be wrong with my machine?
This is a simplified application that hangs the debugger
static void Main(string[] args)
{
var _AppLocation = System.Reflection.Assembly.GetEntryAssembly().Location;
_AppLocation = _AppLocation.Substring(0, (_AppLocation.Length -
(System.Reflection.Assembly.GetEntryAssembly().GetName().Name.Length + 5)));
var directoryInfo = new DirectoryInfo(_AppLocation);
Console.ReadyKey(); //I break here, check the directoryinfo
}
EDIT 10/3/13: This is still unresolved, reinstalling everything(office,framework,vs) completly did not solve the problem. It must be a vs2012 bug that is os/hardware related. I will open a ticket at Microsoft and update if they find out something usefull.
EDIT 10/30/13: This problem have been reproduced on two machines with different hardware configuration. I'm still in contact with microsoft to find the issue. Looks like something related to the framework/windows build/visual studio.
EDIT 11/19/13: I'm still in contact with Microsoft VS escalation team, here's the process monitor log and visual studio crash dump of the problem. http://sdrv.ms/1egpX4O
Solution found in parallelle with the Microsoft VS Escalation team. After analysing the crash dump and process monitor it seems that VS 2012 debugger process checks the store certificate for the Microsoft Root Authority certificate.
Since both computers where in a protected no internet environment, both of them never had been connected online. Thus, they never downloaded the Microsoft CA. Since the CA was absent from the store, it caused the debugger to hang and crash for 3.5 target framework specificly.
Here's the fix from Microsoft VS Team to bypass this check when debugging: (Add in the application app.config)
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
Problem resolved!
I had this same problem with Visual Studio 2015 (including Update 1 and Update 2). So posting my solution (which I submitted to MS) in case somebody else has this problem.
Whenever I tried to use QuickWatch in Visual Studio 2015 Enterprise it would hang the development environment. I can’t click on anything and I’m forced to kill the process via Task Manager. It seems like the modal window opens behind it.
My computer is an HP Spectre and I have another monitor plugged in. I’ve tried it on both monitors.
The fix was to:
Switch to a single monitor
Make the QuickWatch open (which it does)
Move it around (which must
save the window position)
Close it
Plug second monitor in
Now when I use the QuickWatch, it will open correctly
Consider using Process Monitor tool to get a log of file, network, registry and processes operations happen during your investigation. After capturing the log, you may see through it and investigate the possible reason. Or, you can send your log to me and I will investigate it on my side
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
I have done a quick research on msdn and found this :
http://social.msdn.microsoft.com/Forums/vstudio/en-US/2055d3a0-56d9-4134-be23-09a91203e508/quickwatch-says-the-following-for-all-evaluations-function-evaluation-disabled-because-a-previous
Please try the following suggestions to check the result:
Click Tools | Options.. | Debugging | General, and uncheck "Enable
property evaluation and other implicit function calls" option. Step
into (F11) the code to find the root cause of the "time out" Restart
debugging
For more information on the Function Evaluation error, please refer
to: http://msdn.microsoft.com/en-us/library/ms234762(VS.80).aspx
Also, we could get more workarounds of Function Evaluation at blog:
http://blogs.msdn.com/greggm/archive/2005/11/18/494648.aspx
Also it may sound weird but have you the latest update of visual studio 2012?
I had some similar issues when running VS2012 with UAC(User Account Control) turned on, and when having installed some extensions, VisualStudio binds to the running w3p.exe process which works as expected under 1 worker process. Upon allowing multiple worker processes to exist studio cannot track all the independent threads and chokes on the data which reads as corrupted memory.
For myself I have the save setup has yours except for the x64 bit. This always gave me headache in programming... Visual Stutio is 32 bit as long as i know and there is surely a reason why... Anyway you sample work and no hang happend... I cannot tell you exactly why it happened but i'm sure it's a 64 bits related environment of development.
I tried provided code.
VS2012 Ultimate works fine on debug settings and on release setting.
I tested on two differents PCs (desktop and surface Pro)
I also forced x86 setting instead of AnyCPU.
Here is my output for the test application :
http://beehiver.jurion.me/debug%20working.png
I recomend complete uninstall all VS and ALL versions of .net and reinstall. It seems to be a problem on your laptop.
I had the same problem. I suppose its more to do with the hardware configuration. I recently upgraded from 4GB ram to 8GB with Vs 2012 and have never been able to replicate the problem. I used to consistently get this error with the earlier Hardware config.
This Problem happens when your code is waiting for some previous threads to finish there execution,also try to delete .suo file then restart visual studio
This may be related Console.ReadKey() problems/bugs.
http://blogs.microsoft.co.il/blogs/dorony/archive/2012/09/12/console-readkey-net-4-5-changes-may-deadlock-your-system.aspx
Does the problems persist if you use a different method of "pausing?"
There are also some disadvantages of VS. For example, if you open two VS at the same time, while you are writing code, it sometimes get into no response and showing "Saving auto recovery Infomation"
I have seen this option under the debug menu, but I don't completely understand what it means. Could somebody explain it to me? Thank you in advance.
When you Attach to a Process, you're causing the debugger to attach to the process and allow you to set breakpoints within code that you have not started from a debugger. This is very useful in the situation of trying to debug things that have an automatic spawning process (such as .NET code that runs under IIS).
Instead of pressing F5 to start an instance of your app (or pressing the green "go" button), you can attach the debugger to an already running program. While you /can/ attach to an instance of Notepad, since Notepad is not a .net application and you don't have the .pdb debugging symbols for notepad, it won't do much good.
To attach to an already running instance of your program (or an internet explorer instance that is running your code)...
compile non-optimized
compile "Full" debugging symbols (the
default for the DEBUG configuration)
make sure the .pdb file is in
the same directory as the .dll or .exe (or you can find them manually)
make sure the code is in the same path as when it was compiled (or
you have to find it manually)
I don't know what the official documentation says, but this is how I use it.
If you are working in a project that runs continuously, say a web site deployed in IIS or a windows service and you have the solution with the code of the running program open in VS, you can attach to the process and debug it as if you had launched it hitting F5, set breakpoints, etc. It also allows to attach to a process running in a remote machine if it is properly configured, which turns out to be useful if you are debugging a process in a staging server or something like that.
You just need to make sure that the code you are editing is the one used to compile the binary.
You can attach the debugger to a running process and start debugging it where its at. Mostly useful only if you have the debugging information for the executable.
I tend to use it if my program hits an exception and I'm not already debugging it. I can attach and then view the variables and call stack.
That means to attach a debugger (i.e visual studio's integrated debugger) to the process so you can pause it and inspect variables at runtime. This happens when you hit F5 automatically, or can be done manually using the debug menu.
I've got a C# webforms app, that until today had been working just swimmingly.
Now today, all of a sudden, every time I try run the app, I get a file locking error:
Unable to copy file "obj\Debug\MyProject.exe" to "bin\Debug\MyProject.exe". The process cannot access the file "bin\Debug\MyProject.exe" because it is being used by another process.
Googling the error doesn't come up with anything beyond the obvious, i.e. VS thinks the file is locked. And it is definitely Visual Studio itself that locks the file, because when I close VS and reopen it, the project executes fine - the first time. When I try to run it a second time, I get the file locking error.
Closing VS and reopening every time I want to run the app is not a viable workaround! How do I find out what's locking the file, and stop it from getting locked?
EDIT: Another interesting discovery: I don't even have to run the app. Just compiling it once causes the file locking; I cannot compile twice in a row!
This problem is specific to one project in my solution. All other projects work fine and can be executed as many times as I like. It's only this one project that gets itself locked up.
I have found a simple solution which works for me. It goes like this:
When the problem occurs, just change the building configuration at the top (if in “Release” to “Debug” and vice versa), build and then change back to previous configuration and build again.
I suppose that changing the configuration releases the vcshost and devenv.
Well, I solved the problem myself - though I still have no clue why. I decided to isolate the problem by removing all files from the project, then re-adding them and determining that way which file was the source of my trouble. So, one by one I reintroduced files to the project, compiled & cleaned each step of the way... until... I added the last one...
... and everything still worked fine.
I did a compare to the source control of my original .csproj; no real differences. And even when I tried reverting to the previous version of the .csproj, it still worked.
Black magic. If it works, sometimes it's better not to ask why - just accept it and move on...
EDIT: The problem is a recurring one, and I believe I've isolated it to when I have the form designer open of an abstract/generic form at compile time.
Lesson learned: Make sure the Form Designer of any abstract or generic forms or controls is closed before you compile! If not, you have to close VS and reopen!
What we have discovered here, is the following:
In the project properties page, Debug tab, uncheck the "Enable visual studio hosting process".
I am unsure what this property is for, but it does the work once unchecked.
Solved by closing all instances of MSBuild.exe in the windows task manager
Actually you should want "Enable the Visual Studio hosting process" checked. At least for VS2010 anyway. And I also have:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
in the pre-build options. This problem has dogged me for a very long time and it wasn't until John W. mentioned this check box that I even took notice that it existed and low and behold it was already unchecked.
Also notice that -app-vshost.exe runs in the background even when not debugging. Which is what makes it successfully build and run every time I guess. It wasn't running before. And I also tried cleaning out the debug and release folders and changing the target type constantly and nothing worked except as described above. My solution before was to just wait 5 minutes between builds, which got super annoying and time-consuming to get anything done. I haven't seen any change in behavior where it mattered what tabs where open or XNA vs windows form or designers being opened. This issue occurred in 32-bit or 64-bit builds and didn't matter if I killed an app with ALT-F4 or killing it with task manager, which would, in theory, not allow the app to close or release resources. At first I thought it was a garbage collection issue.
I have overcome this problem by renaming the locked file (using Windows Explorer). I was not allowed to delete the file, but renaming the locked file works!
Little late to answer, but I solved this by going to the properties of the project > tab "Debug" > unchecked "Enable the Visual Studio hosting process" option.
I solved this by deleting the folder bin\Debug and, possibly, restarting VS
Run this command from the Run box:
net stop iisadmin /y
and then
iisreset
worked for me.
vs 2003
For me, it was a Windows Service that was installed and running. Once I stopped it, the build was successful.
I had a similar error but during the deployment of the UWP application. Finally, I found out the process that used a file that caused this error and stopped it. Credits to this link. Copy-pasted version is below.
How to Solve the Issue?
One of the easiest ways to handle locked files or folders is to use Microsoft Sysinternals Process Explorer.
Identify what program is using a file
Using Process Explorer there is a simple way to find the program:
Open Process Explorer (running as administrator).
On the toolbar, find the gunsight icon on the right.
Drag the icon and drop it on the open file or folder that is locked.
The executable that is using the file will be highlighted in the Process Explorer main display list.
Identify which handle or DLL is using a file
Open Process Explorer (running as administrator).
Enter the keyboard shortcut Ctrl+F.
Alternatively, click the “Find” menu and select “Find a Handle or DLL”.
A search dialog box will open.
Type in the name of the locked file or other file of interest.
Partial names are usually sufficient.
Click the button “Search”.
A list will be generated.
There may be a number of entries.
And then kill this process.
Unfortunately none of the answers worked for me. This is what solved it:
Win Key + R and run resmon.exe. There you'll find the EXE process that VS claims to be using the file. Right click and end the process. Although you might get an Access Denied error message, it will be suspended and you'll be able to build again.
Recently ran into this problem when attempting to build a solution I am working on (not just a winforms proj).
In addition to build failure, I noticed that cleaning projects would quietly fail (checking the bin folder showed that the files had not actually been erased) and closing the Visual Studio did not end the devenv process - rather, it caused it to crash. Windows recovery process would then restart the Visual Studio.
After some trial and error, I found the problems only happened to me when I opened the solution from the "Recent" menu on starting up VS.
Opening the solution from File >> Open >> Project/Solution found it working as per usually.
Currently no idea why - will keep looking into this but for now, at least I can work!
Just check the references and remove the self-reference to the project.
Explanation: My problem started after creating a custom control and drag and drop it to the toolbox palette for use it in design forms. First appeared a warning saying that there was a redundance between the custom control source file (.cs) and the projects executable (.exe). On executing/debugging appeared the error: unable to access the (.exe) because it's being used (and it was true).
I literally removed the whole source code regarding the custom control and the problem still remained, until I checked out the references and it was referencing itself in order to be "able to" get the former custom control. I removed the reference and done!!
I had the same issue on my Xamarin application in visual studio and it was resolved by unplugging my test mobile device. The application was closed and the debugger was stopped but the error was still happening when trying to build or rebuild the solution. It only stopped after i unplugged the device because i had to receive a call.
Just to throw in my 2 cents. My issue was solved by opening Task Manager and killing the application. It was running in the background without any indication that it was running at all (no item in the task bar, no ui, nothing), but I am not sure why this happened. Obviously the debugger was not running and I only had a single instance of VS opened at the time. It amazes me that this is still happening in this VS 2017.
Perhaps I can add a build step that looks for the application running the background and kills it before starting the new one.
I had the same issue and could not rectify by using any of the methods mentioned in previous answers. I resolved the issue by killing all instances of "SSIS Debug Hist (32 bit)" in task manager and now working as normal.
I had this issue (and its an issue I have seen in other places not just VS).
It's caused by Dropbox (in my case). After editing some code and hitting run, sometimes dropbox immediately locks the file (so it can process it).
Solution 1.
Just hit run again
Solution 2.
Pause dropbox. (not good if your using dropbox as your cloud backup)
Solution 3.
Remove the build folder from dropboxes sync list.
Deleting Obj, retail and debug folder of the .NET project and re-building again worked for me.
This got me stuck for over two days, had to reclone the project and save the project folder in a different name, but today I found the solution from a microsoft dev forum.
solution:
Create a pre-build action in your project by going to project properties (right-click on the project in the solution explorer, and select the Properties option), select the Build Events tab. Add this code:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
This code will copy the file to a different name, and allows the build to continue successfully.
How is your web app configured? Does it run under Cassini (the tray web server) or IIS?
This shouldn't happen normally though. I think ProcessExplorer can tell you what files a process has locked. If not process explorer one of the other sysinternals tools.
One thing to try before even downloading one of the SI tools is to stop the Cassini web server, and seeing if that frees up the file.
What worked for me was restarting IIS
i had this same problem as well. changing the debug/release config didn't do the trick. at least not without building in between.
in my solution (winform) it was solved by opening the mainform of the winform in the designer. switching to code (F7). Then closing the code, closing the designer of the winform and rebuild all (ctrl-shift-B). This worked for me.
seems like some kind of handle from within the winform app (which runs a backgroundworker) still had a file handle on some of the other libraries used.
I had two instances of Visual Studio opened the same solution.
In my case there were some vstest processes running (with various names but all containing the string vstest). I had to terminate them in taskmgr.
Same error, solved by updating Google Nuget support packages
When I ended the process .Net Core Host, everything built fine. I didn't have to close Visual Studio or do change anything else.
For those who are developing in VS with Docker, restart the docker for windows service and the problem will be solved immediately.
Before restarting docker I tried all the mentioned answers, didn't find a msbuild.exe process running, also tried restarting VS without avail, only restarting docker worked.
One more solution: when the files get locked, blocking process is reported (something like "ServiceHub.Host.CLR.x64 (7764)") with it's id in parentheses.
To get rid of the process, open PowerShell (x + Win + I) and type: "Stop-Process -Id idNumber".
I recently ran into the issue when deploying to Service Fabric. The error is implying a 'file' is in use, however, I found that the port was being used by another IDE. By stopping a running service which was already hosting on the port, I was able to stop this exception from occurring.
I have this message when I start debug in VS 2008:
Error while trying to run project: Unable to start debugging
Because of this I cannot debug any programs any more. Any ideas what causes this?
I had this problem when I brought my code over from another machine. I kept getting that message when trying to debug until I completely cleaned out the output directory (I just manually deleted everything in it). Once I did that, I could run in debug mode.
Sometimes it means the URL you have setup for the project in the Project Properties doesn't match what it is in IIS.
Assuming a client app and not a web app, there are a few things to try:
Make sure you run Visual Studio as an admin (elevated).
Make sure you have cleanly built your project and have matching symbols (.pdb and .exe have same timestamp).
Make sure you are not already debugging the app with VS or a different debugger.
This is also possible when in VS->Server Explorer Application debugging is enabled or CLR/SQL debugging is enabled..
Disabling that might solve the issue..
Verify that you are a member of the Administrators group and the Debugger Users group on the computer.
I received this error after our sys admins pushed new security settings. Added the ASP user to the Administrators group and that resolved it.