Support Single File Diagnostics

[tommcdon]

This issue is tracking the work necessary to support single-file diagnostics. Our goal is to deliver parity with debugging and profiling with framework dependent applications where applicable.

• Reduce long term maintenance by moving to the dotnet/diagnostics repo
• dbgshim needs an ELF parser to identify if a module is CoreCLR + extract the DAC/DBI keys. There's currently a copy in use in the runtime for createdump and the DAC on Linux dumps and one used in SOS for OpenVirtualProcess.
• dbgshim OVP needs updated ILibraryProvider callback interface that accepts buildid information for DAC/DBI. This receives the DAC/DBI keys that were retrieved.
• dbgshim live debugging case needs to integrate ILibraryProvider so that the caller can locate DAC/DBI instead of dbgshim.
  • We search for CoreCLR in the module list. On Linux and macOS we have the PAL runtime startup helper:

    runtime/src/coreclr/src/pal/src/thread/process.cpp

    Line 1654 in 6438d08

    PAL_ERROR InvokeStartupCallback()

  • Use the path to coreclr as a lookup location for DBI: F:\github\coreclr\src\dlls\dbgshim\dbgshim.cpp:382
  • provide the coreclr base address to DBI:

    mscordbi!Cordb::SetTargetCLR 
    mscordbi!CoreCLRCreateCordbObjectEx 
    mscordbi!CoreCLRCreateCordbObject dbgshim!CreateCoreDbgWithoutSandboxSupport 
    dbgshim!CreateCoreDbg dbgshim!RuntimeStartupHelper::InvokeStartupCallback 
    dbgshim!RuntimeStartupHandler 
    dbgshim!InvokeStartupCallback dbgshim!StartupHelperThread
    

• createdump and a portion of the DAC need to be linked into the host
• The linked version of createdump needs to be modified to use a linked in DAC rather than searching for it.
• F:\github\coreclr\src\debug\createdump\crashinfo.cpp(374) - cache coreclr path unneeded
• F:\github\coreclr\src\debug\createdump\crashinfo.cpp(620) - add alternate path to construct pfnCLRDataCreateInstance
• Mac OS superhost debugging support Change DAC to use MachOReader to lookup "g_dacTable" symbol instead of the rva header file hack #38901
• Link DotNetRuntimeInfo into the superhost Debugging singlefile deployment: Failed to find runtime module (libcoreclr.so), 0x80004005 diagnostics#1764
• Watson support for single-file apps diagnostics#2438 (comment)

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This issue is tracking the work necessary to support single-file diagnostics

[ ] dbgshim needs an ELF parser to identify if a module is CoreCLR + extract the DAC/DBI keys.
○ one copy is linked into SOS for OVP
○ one is still built in CoreCLR

[ ] dbgshim OVP needs updated ILibraryProvider callback interface that accepts buildid information for DAC/DBI. This receives the DAC/DBI keys that were retrieved in (4) David

[ ] dbgshim live debugging case needs to integrate ILibraryProvider so that the caller can locate DAC/DBI instead of dbgshim F:\github\coreclr\src\pal\src\thread\process.cpp:1809 - InvokeStartupCallback - This searches for coreclr in the module list in order to:

	○ use the path to coreclr as a lookup location for DBI: F:\github\coreclr\src\dlls\dbgshim\dbgshim.cpp:382
	○ provide the coreclr base address to DBI: 
		§ mscordbi!Cordb::SetTargetCLR 
		§ mscordbi!CoreCLRCreateCordbObjectEx 
		§ mscordbi!CoreCLRCreateCordbObject dbgshim!CreateCoreDbgWithoutSandboxSupport 
		§ dbgshim!CreateCoreDbg dbgshim!RuntimeStartupHelper::InvokeStartupCallback 
		§ dbgshim!RuntimeStartupHandler 
		§ dbgshim!InvokeStartupCallback dbgshim!StartupHelperThread

[ ] CreateDump + DAC (or a fraction of it) needs to be linked into the nativehost

[ ] Linked in CreateDump is modified to use a linked in DAC rather than searching for it
○ F:\github\coreclr\src\debug\createdump\crashinfo.cpp(374) - cache coreclr path unneeded
○ F:\github\coreclr\src\debug\createdump\crashinfo.cpp(620) - add alternate path to construct pfnCLRDataCreateInstance

Author:	tommcdon
Assignees:	-
Labels:	area-Diagnostics-coreclr
Milestone:	6.0.0

[clairernovotny]

Is there any updates here on progress? This is also affecting attaching to .NET 5 & 6 apps in an MSIX that aren't single file.

[hoyosjs]

The work for dbgshim needed for msix is planned but not yet fully designed. Other more time sensitive components of single file diagnostics were getting addressed first. Cc @tommcdon

[michalk-gc]

This one is required so we can e.g. attach a debugger to installed MSIX app. My team has just migrated the app from .NET framework, where it worked, to .NET 5.0 and it turns out that we won't be able to debug it until .NET 7.0? Feels like a big gap to me.

[yoziv]

debugging in single file mode worked for in .Net 5 and not working in .net 6 , is it only going to be fixed in .net 7?

[hoyosjs]

@yoziv By debugging you mean using a debugger like VS? I'm sorry this might be causing some issues in your experience... Right now single file is only debuggable through SOS. Single files are a deployment mechanism and they changed quite a bit in .NET 6. There wasn't enough time in .NET 6 to add support to launching/attach to one them. For the inner dev loop, debugging would need to go through the usual app build, and SOS is available for the cases where that doesn't work - like post mortem diagnostics.

[ssa3512]

@hoyosjs right now you can't even F5 debug a project with single file publish enabled when it is targeting .NET 6 in VS2022. That may be different from what this issue is tracking. Is this issue specifically the ability to attach a debugger to the published application?

https://developercommunity2.visualstudio.com/t/Unable-to-attach-to-CoreCLR-when-debug/1523427?entry=problem&ref=native&refTime=1636746090780&refUserId=8c25c91a-2d4f-6773-b0fa-d18fdec3f989

This feedback is specifically for "press play" debug in .NET 6/VS2022 which does not work.

[AraHaan]

Currently I bypass this by making <PublishSingleFile> only happen on Release configuration, while debug does not do single file at all.

[hoyosjs]

Sorry - from a scenario perspective this is indeed a regression. I wasn't aware that VS does a use of the publish output to running inner loop scenarios, I expected only build to happen. To achieve this behavior - as @AraHaan says - the best solution is to have this on the project file:

<PublishSingleFile Condition="'$(Configuration)' == 'Release'">true</PublishSingleFile>

The only scenario that this will still fail to cover is doing attach to a running application build outside of the IDE (basically, a release mode attach).

[avidenic]

Tnx @hoyosjs The workaround works.

[mikem8361]

I closing this now. I created #68676 to track the last item.

[ALIENQuake]

@mikem8361 Many thanks for this!