I have a .NET Core 3.1 application that is stopping its App Pool on IIS every time that I do the following:
If I just stop the debugger this doesn't happen, it only happens after close the Visual Studio 2019 after I stopped debugging my code.
I tried a few things but nothing fixed that.
Did anyone come across that before?
I tried the same thing on my Viual studio and local IIS. And the worker prceoss get terminated when I close visual studio as well.
So reviewed event viewer but nothing logged at that time.
Then I created debug diagnostic tool rule for breakpoint ntdll!NtTerminateProcess.At this time, a dump generated.
Here is the full stack trace for all threads
. 0 Id: 688.415c Suspend: 1 Teb: 00000039`02299000 Unfrozen
# Child-SP RetAddr Call Site
00 00000039`0247f938 00007ffb`15c6a954 ntdll!NtTerminateProcess
01 00000039`0247f940 00007ffb`1486cd8a ntdll!RtlExitUserProcess+0x54
02 00000039`0247f970 00007ffb`147da245 kernel32!ExitProcessImplementation+0xa
03 00000039`0247f9a0 00007ffb`147da8b5 msvcrt!_crtExitProcess+0x15
04 00000039`0247f9d0 00007ff7`79ca3214 msvcrt!doexit+0x171
05 00000039`0247fa40 00007ffb`14867bd4 w3wp!__wmainCRTStartup+0x164
06 00000039`0247fa80 00007ffb`15c6ced1 kernel32!BaseThreadInitThunk+0x14
07 00000039`0247fab0 00000000`00000000 ntdll!RtlUserThreadStart+0x21
1 Id: 688.afc Suspend: 1 Teb: 00000039`022a3000 Unfrozen
# Child-SP RetAddr Call Site
00 00000039`026ff848 00007ffb`15c34060 ntdll!NtWaitForWorkViaWorkerFactory+0x14
01 00000039`026ff850 00007ffb`14867bd4 ntdll!TppWorkerThread+0x300
02 00000039`026ffc10 00007ffb`15c6ced1 kernel32!BaseThreadInitThunk+0x14
03 00000039`026ffc40 00000000`00000000 ntdll!RtlUserThreadStart+0x21
2 Id: 688.3f78 Suspend: 1 Teb: 00000039`022a5000 Unfrozen
# Child-SP RetAddr Call Site
00 00000039`0277f858 00007ffb`13266951 ntdll!NtDelayExecution+0x14
01 00000039`0277f860 00007ffb`0aba6bdb KERNELBASE!SleepEx+0xa1
02 00000039`0277f900 00007ffb`0ab748e4 winhttp!SafeTerminateDll+0xcb
03 00000039`0277f940 00007ffb`15c305ac winhttp!FailFastThreadpoolWaitCallback<&SafeTerminateDll>+0x14
04 00000039`0277f980 00007ffb`15c341c2 ntdll!TppExecuteWaitCallback+0xa4
05 00000039`0277f9d0 00007ffb`14867bd4 ntdll!TppWorkerThread+0x462
06 00000039`0277fd90 00007ffb`15c6ced1 kernel32!BaseThreadInitThunk+0x14
07 00000039`0277fdc0 00000000`00000000 ntdll!RtlUserThreadStart+0x21
3 Id: 688.748 Suspend: 1 Teb: 00000039`022b9000 Unfrozen
# Child-SP RetAddr Call Site
00 00000039`02bff848 00007ffb`15c34060 ntdll!NtWaitForWorkViaWorkerFactory+0x14
01 00000039`02bff850 00007ffb`14867bd4 ntdll!TppWorkerThread+0x300
02 00000039`02bffc10 00007ffb`15c6ced1 kernel32!BaseThreadInitThunk+0x14
03 00000039`02bffc40 00000000`00000000 ntdll!RtlUserThreadStart+0x21
4 Id: 688.3b38 Suspend: 1 Teb: 00000039`022bd000 Unfrozen
# Child-SP RetAddr Call Site
00 00000039`02cffad8 00007ffb`132784c3 ntdll!NtRemoveIoCompletion+0x14
01 00000039`02cffae0 00007ffa`b8a238e2 KERNELBASE!GetQueuedCompletionStatus+0x53
02 00000039`02cffb40 00000000`00000000 <Unloaded_aspnetcore.dll>+0x38e2
5 Id: 688.3cf8 Suspend: 1 Teb: 00000039`022c9000 Unfrozen
# Child-SP RetAddr Call Site
00 00000039`024ff788 00007ffb`15c34060 ntdll!NtWaitForWorkViaWorkerFactory+0x14
01 00000039`024ff790 00007ffb`14867bd4 ntdll!TppWorkerThread+0x300
02 00000039`024ffb50 00007ffb`15c6ced1 kernel32!BaseThreadInitThunk+0x14
03 00000039`024ffb80 00000000`00000000 ntdll!RtlUserThreadStart+0x21
You can see that when you close visual studio, it just call a safety terminate function and terminate the process. No strange behavior or exception generated. So it must by design.
If you go to IIS manager , you will see the application pool get stopped when you close VS.
If you don't want visual studio corrupt your IIS worker process. Then please debug it in other profile environment and publish the release version to your local IIS.
I think this is the intended behaviour.
By default Visual Studio uses IIS Express to host your sites. IIS Express is a service which is started by Visual Studio when you start debugging and continues to run until you close Visual Studio (or stop it manually).
If you want it to persist then you'll need to debug using a local IIS instance other than Express.