Can't attach to ASP.NET Core application when hostingModel is "InProcess" and .NET CLR version was selected

[ww898]

The attach to w3wp.exe which contains .NET Core v3.0.100-rc1 inside (ASP.NET Core v3 application where web.config has hostingModel="InProcess" ) hangs till the timeout when the IIS application pool configured in the following way:
.
The server diagnostic thread in w3wp.exe is waiting for incoming connection in ConnectNamedPipe:

  35  Id: 492c.3dd8 Suspend: 1 Teb: 000000b2`c3498000 Unfrozen
 # Child-SP          RetAddr           Call Site
00 000000b2`c467f6c8 00007ff8`91965b99 ntdll!NtFsControlFile+0x14
01 000000b2`c467f6d0 00007ff8`49ac225b KERNELBASE!ConnectNamedPipe+0x79
02 000000b2`c467f740 00007ff8`49ad39a4 coreclr!IpcStream::DiagnosticsIpc::Accept+0x7b [f:\workspace.2\_work\1\s\src\debug\debug-pal\win\diagnosticsipc.cpp @ 64] 
03 000000b2`c467f7a0 00007ff8`953c4034 coreclr!DiagnosticsServerThread+0xa4 [f:\workspace.2\_work\1\s\src\vm\diagnosticserver.cpp @ 51] 
04 000000b2`c467f850 00007ff8`955b3691 KERNEL32!BaseThreadInitThunk+0x14
05 000000b2`c467f880 00000000`00000000 ntdll!RtlUserThreadStart+0x21

It looks like the server pipe has wrong access rights in this case. It's the reason of timeout in the client application.

The attach works properly when the .NET CLR version set to "No Managed Code":

The detail repro case is here https://youtrack.jetbrains.com/issue/PROF-903.

[jeffschwMSFT]

I do not believe ASP.NET Core 3.0 can target .NET Framework. See https://docs.microsoft.com/en-us/aspnet/core/?view=aspnetcore-2.2. +@DamianEdwards

cc @tommcdon

[davidfowl]

@jeffschwMSFT the above works and ends up hosting both CLRs in the same process (coreclr.dll and clr.dll). Are you trying attach to w3svc.exe or w3wp.exe?

[ww898]

@davidfowl thanks a lot. You are right, surely w3wp.exe. Fixed the first message.

Our profiler found both .NET Framework v4 and .NET Core v3 in the same process:

[tommcdon]

@davmason

[davmason]

@josalem @sywhang have either of you seen this before?

cc @dotnet/dotnet-diag

[josalem]

Hmm, assuming that @ww898 is using the IPC server to start profiling, the error message makes me think that a Named Pipe doesn't exist for that PID. @ww898, could you try to repro this and then before attaching do gci \\.\pipe\ | findstr dotnet. This will list all the available IPC pipes you can connect to. They will have a name like dotnet-diagnostic-<pid>. Try comparing the PIDs in that list to the PID being displayed in your UI. I'm wondering if somehow the Named Pipe is being created with a different PID in the name than that what is being displayed there due to the different pooling models in IIS.

[davidfowl]

The named pipe here is an IIS implementation detail, nothing to do with event pipe

[ww898]

@josalem here it is:

C:\WINDOWS\system32>handle -a -u dotnet-diagnostic-
w3wp.exe           pid: 14668  type: File          IIS APPPOOL\qqq            7D8: \Device\NamedPipe\dotnet-diagnostic-14668

\BaseNamedObjects\CPFATE_14668_v4.0.30319 or \Device\NamedPipe\CPFATP_14668_v4.0.30319 are absent.

P.S. I can create the memory dump for you if you want.

[noahfalk]

When you launch w3wp.exe with/without the CLR loaded, does that cause it to use a different app-pool, possibly owned by a different user account? In order to connect to the named pipe the process initiating the connection must either be the same user account as the target or have admin rights. There could also be some other security privilege checks involved such as Mandatory Integrity Level checks that would prevent a lower rights process from connecting to a higher rights process.

I think someone will need to setup a repro over here before we've got a more definitive answer, but my current bet is that the root cause will be a windows security check.

[tommcdon]

Hi @ww898, we are triaging diagnostics issue for .NET 6 and are curious if this is still a problem, or has been narrowed down to a runtime issue.

[ww898]

Hi @tommcdon, I can check the issue tomorrow with .NET Core 5.0 RC2.

[ww898]

@tommcdon Our QA reproduced the issue with .NET Core 5.0-rc2 today.

[tommcdon]

@davmason

[davmason]

@ww898 can you both the successful scenario and the failing scenario and provide the output for gci \\.\pipe\ | findstr dotnet? That will show us if the app pool suggestion Noah made is right.

[ww898]

With error in attach:

PS C:\WINDOWS\system32> gci \\.\pipe\ | findstr dotnet
------          1/1/1601   3:00 AM              1 dotnet-diagnostic-6200

Without error in attach:

PS C:\WINDOWS\system32> gci \\.\pipe\ | findstr dotnet
------          1/1/1601   3:00 AM              1 dotnet-diagnostic-10080

[davmason]

@ww898 this behavior is due to permissions issues. I set up a repro machine, and running as a regular user I cannot attach dotnet-trace to the process, but when running as adminstrator I can. Can you verify if running as administrator allows you to attach?

[ghost]

This issue has been automatically marked no recent activity because it has been marked as needs author feedback but has not had any activity for 14 days. It will be closed if no further activity occurs within 7 more days. Any new comment (by anyone, not necessarily the author) will remove no recent activity