Project-system: Visual studio 2017 can not stop dotnet.exe

Created on 16 Mar 2018  Â·  36Comments  Â·  Source: dotnet/project-system

@SharafiAli commented on Wed Dec 13 2017

Visual studio 2017 can not stop dotnet.exe

Visual studio is unable to stop dotnet.exe process.

General

After migration of 3 dotnet core projects from dotnet core 1 to 2.0, Visual Studio cannot stop dotnet.exe processes after stopping the debugging. The solution contains 3 dotnet core projects (Identity server, Api and Web application).

Visual studio shows the popup window "_Stop Debugging in Progress..._" with the message: "_Debugging is being stopped but is not yet complete. You can force debugging to stop immediately, but any processes being detached may be terminated instead. this window will automatically close when the debugging has completely stopped._" but it can not stop the dotnet.exe process.

Even the "End Process" on the Processes-Tab can not terminate the dotnet.exe process, it gives an AccessDenied warning.

Even the command "taskkill /pid ProcessID /f" cannot terminate it. It returns "_The process with PID ProcessID could not be terminated._" Error, with "_This task is not running currently_" as reason.

The only possible solution that I have at this moment is restarting my pc, which makes the development impossible.

Does anyone have any idea why this is happening?


@richlander commented on Thu Dec 14 2017

PTAL @Andrew-MSFT


@Andrew-MSFT commented on Thu Dec 14 2017

Looping in @caslan


@orobert91 commented on Mon Dec 18 2017

I have vaguely the same problem since upgrading to Visual Studio 2017.5.2. About 1 time out of 3 I have to kill the IIS Worker Process manually. Never experienced this before.


@caslan commented on Mon Dec 18 2017

@WardenGnaw, can you help investigate?


@WardenGnaw commented on Tue Dec 19 2017

@SharafiAli I tried to reproduce this issue with a solution with two web apps and a dotnet console app. I can successfully start, run, and stop the debugging session. All of the dotnet and iisexpress processes are gone.

Do you have a project that you can share that reproduces this issue?


@GeekyMonkey commented on Mon Feb 19 2018

I'm having this problem with a dotnet core angular spa app from the template. It happens about half the time. I have to kill the dotnet.exe process to get a compile.


@GeekyMonkey commented on Tue Feb 20 2018

Un-checking this fixed it for me
Tools - Options - Debugging - General - "Enable JavaScript Debugging for ASP.NET (Chrome and IE)"


@ramvdixit commented on Wed Mar 07 2018

Deleting all breakpoints and running in Debug mode fixed it. Unfortunately, nothing else did it for me. I had to again set the breakpoints that I wanted.

Area-External Feature-Debugging Resolution-No-Repro

Most helpful comment

I see the same thing as @davkean in 2017-15.9.17. In my case i'm running in circles trying to figure out whether or not my latest changes are executing or if the first version of code launched is executing. The other problem is, i'm trying to debug application lifetime stops, but the web server is still running and my code never stops when I stop debugging. I can keep making api calls from the browser, and the code keeps executing. So no application stop. I think we should have an option to stop the web server if we need to. Exiting VS every time is very annoying and breaks the developer experience/continuity.

All 36 comments

@greggm - any ideas here?

I'm currently investigating this issue. Sadly, I can't recreate the issue and I am still looking for a consistent repro.

Any updates here?

Still none. I can still terminate dotnet.exe from VS in .net core projects.

@SharafiAli @GeekyMonkey Instead of using VS to stop the process, Can you try killing the dotnet.exe process with another tool? You can use something like taskkill /im dotnet.exe. Let me know if this actually kills the process.

Another way to help is to provide a dump for us to investigate this issue:

You can collect a dump file with the following steps:

  1. Start Visual Studio. 
  2. Start another instance of VS. 
  3. In the second instance click Debug | Attach to Process… 
  4. In the list of processes locate msvsmon.exe. 
  5. Click Select… and explicitly choose 'Native' and 'Managed(v4.6, v4.5, v4.0)' code. 
  6. Click OK and OK to close Select dialog and Attach to Process dialog. 
  7. Go back to the first instance of VS and repro the issue. 
  8. Go to the second instance of VS and do "Debug->Break All"
  9. In the second instance click Debug | Save Dump As… and save the dump. 
  10. Attach the dump file to your problem report and send it

Thank you.

For me the problem comes and goes. I can work half the day doing lots of bulks cycles and it works. Then once it stops working, I have to manually kill the dot net process to enable the build to complete. I set up a Windows hot key that fires a power shell script. It'll stay like this for all subsequent build cycles. If I reboot then I'm back to normal build cycles.

Thanks to those one who replied on this issue,

I've had for a long time problem with this anoying issue. I couldn't find the cause. So, finally I've decided to:

Update: This comment is not helping!!!

  1. Uninstall VS2017
  2. Delete all temporary files
  3. Delete the .vs folder of VisualStudio
  4. Delete my local version of SourceCode
  5. Install VS2017
  6. Get Latest version of SourceCode via TFS.
  7. Disable Diagnostic and profiling tools (Very Important)

That solved the problem with dotnet.exe, but now I have another problem with IIS Express. After stopping debugging the IIS Express does not stop !!! what I do at this moment is to RMC on IIS and then click on Exit.

@SharafiAli the not stopping of IIS Express is by design. For ASP.NET Core, no user code is hosted in the process, so stopping and restarting it slows down F5 a bit with no technical benefit (it will exit when you close Visual Studio). Are you seeing problems associated with it still running?

Thanks,
For the moment no.

What I noticed today was everything was cool until I did an effort core migration on the command line. Then it got into the ugly state after the next build. Could be a coincidence.

Effort=EF
Dang autocorrect

@GeekyMonkey any further leads? Did the EF correlation continue?

@WardenGnaw, @Pilchie I did experience the problem again today. This was after doing an ef migration. This was my first build of the day on this project. First build was OK. I added an ef migration and it ran ok. I tried adding another change and building and this is when I got the error. It wasn't the first build after the migration was added.

I tried to follow Andrew's steps to get a dump, but I don't see an msvsmon process.

This is my error message:
Severity Code Description Project File Line Suppression State
Error MSB3021 Unable to copy file "obj\Debug\netcoreapp2.0\FlotillaWebUi.dll" to "bin\Debug\netcoreapp2.0\FlotillaWebUi.dll". The process cannot access the file 'bin\Debug\netcoreapp2.0\FlotillaWebUi.dll' because it is being used by another process. FlotillaWebUi C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets 4118

Tried running taskkill /im dotnet.exe
and this gave me:
ERROR: The process "dotnet.exe" with PID 10400 could not be terminated.
Reason: This process can only be terminated forcefully (with /F option).

Running it with /f did work, and then visual studio was able to build the project again.

@Andrew-MSFT Thanks for the info about it being by design.

It confused me while testing what would happen in one application when a microservice dependency wasn't running. I quit VS and the server stopped and I could make my test :)

@livarcocc - see this comment (https://github.com/dotnet/project-system/issues/3394#issuecomment-382008270). I can't see that being project system. Can you take the next look?

I am somewhat confused. Is this related to F5 with debug or EF migration? Each can have their own reasons. If the first, I would loop in or move the issue to EF. If the second, I would somehow suspect the app or a debugger problem, as in that case, there is no SDK in play, VS simply runs the application and attaches the debugger.

My take is that we have determined that there isn't an issue with debugging - just confusion about the fact that IISExpress continues running, but there is a second issue that might be correlated with EF, but we're not sure.

We've not seen an update on this bug for a while - I'm going to close it out. If someone is still running into this issue can you please open a new bug with repro steps and actual/expected behavior?

@Petermarcu @davkean @Pilchie @Andrew-MSFT

I'm having this problem again.

Not just sometimes, but every day after making a change and rebuild. my other colleagues don't have this problem, they've never experienced this problem.

Could it be related to hardware?

@WardenGnaw
I've followed the steps to get a dump file whithout success.
After stopping the debugging session in the first instance of VS: In the second instance of VS which the msvsmon.exe is attached to, the process msvsmon.exe gets automatically detached. After then it is not possible to save a dump file.

Same problem here.

I have a solution with 4 projects. After I start it, each one gets its own iisexpress/.../dotnet process, listed as process tree by "pslist /t":

explorer                        9544   8 116 2335 4194303  117740   58480
  devenv                        3700   8  59 2877 1332344  475920  384080
    iisexpress                 14728   8  26  497  192400   21264   11304
      conhost                  14748   8   5  118 4194303    9680    5576
      iisexpresstray           14904   8  30  589  314760   46560   31880
      VSIISExeLauncher         15276   8  12  327  187044   16868   14740
        dotnet                 14992   8  29  484 4194303   50380  100140   !!!
        conhost                15344   8   5  119 4194303    9644    5520
    iisexpress                 14976   8  27  557  194672   22432   11984
      conhost                  14776   8   5  118 4194303    9652    5544
      VSIISExeLauncher         15032   8  19  369  197112   18200   15456
        conhost                 3416   8   5  119 4194303    9648    5540
        dotnet                 15564   8  48  724 4194303  160984  341892   +++
[...]

Occasionally VS stops these IISExpress hosts and all child processes with them. However, sooner or later (usually sooner :-[) one of the dotnet processes gets "stranded alive":

Name                Pid Pri Thd  Hnd   Priv        CPU Time    Elapsed Time 
dotnet                         14992   8   1  479 4194303   50564  100116   !!!

When this happens, the process cannot be killed (despite being admin and having made sure that I have termination permissions). Also I cannot attach to it with the debugger.
What's more, when this happens I get a bluescreen (reference by pointer, 0x0..018) during shutdown.

I originally attributed the bluescreen to some issues with Windows 1803, therefore I just set up my laptop from scratch two days ago, i.e. the machine is as clean as can be. The issue remains though.

Just got this error late yesterday while working, trying to fix it now....so far no success. Will update as I work through trying to fix this issue.

Running VS 15.5.3 but have another dev running 15.7.1 and not getting the error yet.
What is everyone running?

@abpiskunov / @BillHiebert / @livarcocc - this needs to be moved to the right home - is that CLI or web tools?

It feels like it could be on the web side. I will create a TFS bug for us to investigate.

TFS 621726

In meanwhile @pthorsley, @ajdotnet, @SharafiAli could you please update to latest VS update and see if you still see this issue there on the same machine.

I've formated my pc, installed one of the latest build of Windows 10, installed last version of visual studio professional 2017, installed all needed updates, get the code through tfs and rebuild the solution, for couple of days it works fine, then it began again.

Just updated to 15.7.1 on the same machine and it is still happening....UGH...
Here is debug output:

Unhandled exception at 0x00007FFAD93F3C58 (KernelBase.dll) in dotnet.exe: 0xE0434352 (parameters: 0xFFFFFFFF8007000B, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x00007FFA8BC80000).

When it went to debug it completely failed also, here is output.
Kernelbase.pdb not loaded

Module Information
Version: 10.0.14393.1770 (rs1_release.170917-1700)
Original Location: C:\Windows\System32\KernelBase.dll

Background on Solution:

  1. Project 1: .Net Core Web API
  2. Project 2: .Net Core Class Library
  3. Project 3: .Net Core Class Library
    This is actually a container for nodejs react web project, the MS 2017 react template sucked big time and some libs are not even supported moving forward anymore, so we are going to nodejs instead of IIS.

We use git for our repository in vsts, works soso, so now we use the command line since VS seems to have issues at times, so not worth it.

I am running project 1 with IISExpress using the Edge browser option, have tried Chrome with same repro.

I am under a timeline, sooooo I guess I will use the InstallCleanup.exe, Maybe that will actually get rid of the files that are killing my startup.

Completely deleted VS 2017 15.7.1:

C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\layout>InstallCleanup.exe -i
Verbose Log File: C:\Users\\AppData\Local\Temp\dd_cleanup_20180524162511.log
Execution Mode: InstanceResources

Detecting MSIs To Remove:
Detecting Packages... Done

Removing MSIs:

Detecting Visual Studio 2017 Installs:
Detecting Instances... Done

Removing Instance Installs:

Removing Package Cache:
Deleting C:\ProgramData\Microsoft\VisualStudio\Packages... Done

Removing File Associations:
Deleting Keys... Done

Removing ProgIds:
Deleting ProgIds... Done

Removing Application Registration:
Deleting AppIds... Done

Removing Capability Registration:
Deleting Keys... Done

Removing Shortcuts:
Deleting Shortcuts... Done

Also deleting everything from here:

• C:\ProgramData\Microsoft\VisualStudio\15.0
• C:\ProgramData\Microsoft\VisualStudio\Packages
• %appdata%\Microsoft\VisualStudio\15.0*
• %appdata%\Microsoft\VisualStudio\Packages
• C:\Program Files (x86)\Microsoft Visual Studio\2017
• HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\15.0*
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\15.0*

FAILURE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
FAILURE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
FAILURE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Fning going crazy with this POS

WHO IS WORKING THIS, have a demo and this POS continues to give me this:

"dotnet has stopped working" WTF is that kind of error?

HELLO Microsoft who the F is working this POS????????????????????????????
What is the point of an expensive MSDN license??????????????????????????

WOW.... so then I create another project just to test out VS 2017 and what do you know I am now getting:
"An error occurred trying to load the page. Object reference not set to an instance of an object" when opening the project properties for the Application, Build, and Bild Events sections only.

This is a brand new project, nothing crazy just a simple web .net core 2.0 site.
Did anyone test just the basics??? this is really bad.
Can open sections Package, Debug, Signing, TypeScript Build, Resources

Ok, solved it myself...
Seems the .vs\config\applicationhost.config was causing issues.

@abpiskunov: I am on the latest VS version (15.7.2) and usually update as soon as a new version becomes generally available. I've had ths issue with one (maybe two) versions before.

I've attached some dump files created after the blue screen, maybe they can help you to find the cause.
Kernel_18_b8cff6b38957c7bbd5a10cb4c673e6ac432_00000000_cab_03a03076.zip

@davkean

We've not seen an update on this bug for a while - I'm going to close it out. If someone is still running into this issue can you please open a new bug with repro steps and actual/expected behavior?

This is still an issue, easy to reproduce.

Create an application with SignalR connected, make sure that the client keeps sending stuff to the server. When you run (debug) and then stop, IIS Express will keep running, but because it is still responding to requests from the client you can't debug your application again. This is because the DLL's in the out directory are still busy and loaded by IIS Express and cannot be overwritten. The only way to continue again is to manually stop IIS Express.

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(4366,5): warning MSB3026: Could not copy "C:\Projects\test.dll" to "bin\Debug\netcoreapp2.2\test.dll". Beginning retry 2 in 1000ms. The process cannot access the file 'bin\Debug\netcoreapp2.2\test.dll' because it is being used by another process. The file is locked by: ".NET Core Host (25368)"

I see the same thing as @davkean in 2017-15.9.17. In my case i'm running in circles trying to figure out whether or not my latest changes are executing or if the first version of code launched is executing. The other problem is, i'm trying to debug application lifetime stops, but the web server is still running and my code never stops when I stop debugging. I can keep making api calls from the browser, and the code keeps executing. So no application stop. I think we should have an option to stop the web server if we need to. Exiting VS every time is very annoying and breaks the developer experience/continuity.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

MBulli picture MBulli  Â·  3Comments

aL3891 picture aL3891  Â·  3Comments

bricelam picture bricelam  Â·  3Comments

aL3891 picture aL3891  Â·  3Comments

davkean picture davkean  Â·  3Comments