.NET 运行时神秘文件名全解从 coreclr.dll 到 mscordacwks / mscordaccore.dll【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime导读.NET 自诞生以来积累了多个让开发者困惑的二进制文件名——coreclr.dll、clr.dll、mscorwks.dll、mscordacwks.dll、mscordaccore.dll……它们分别是什么彼此之间是什么关系本文以 docs/project/dotnet-filenames.md 这份文件名百科全书为骨架结合当前仓库.NET 跨平台运行时 runtime中的 DAC 设计文档、Cross-DAC 说明 以及 coreclr VM 源码 中的实际引用逐一厘清这些文件名的由来、职责与演变帮助读者在调试、符号加载、dump 分析等场景中准确识别它们。一、为什么 .NET 会有这么多神秘文件名.NET 是一个横跨二十余年、历经多代产品线.NET Framework 1.0/2.0/3.5 → .NET Framework 4 → .NET Core → .NET 5 统一运行时的开源运行时。随着运行时实现的分裂与合并、工作站/服务器 GC 的整合、以及调试基础设施DAC的引入历史遗留与当代产物叠加形成了大量看名字猜不出用途的 DLL。这份 dotnet-filenames.md 存在的意义正是为这些文件名给出权威定义。它本质上是一份运行时二进制命名约定的速查手册覆盖了从 .NET Framework 时代到现代 CoreCLR 的所有关键产物。二、当代运行时的两大核心产物2.1 coreclr.dllCoreCLR 的实现本体coreclr.dll: The implementation of CoreCLR.coreclr.dll就是 CoreCLR现代 .NET 的跨平台运行时核心的二进制实现。在当前仓库中CoreCLR 的源码位于 src/coreclr涵盖 JITsrc/coreclr/jit、GCsrc/coreclr/gc、VMsrc/coreclr/vm、PALsrc/coreclr/pal等子系统最终被链接为coreclr.dllWindows/libcoreclr.soLinux/libcoreclr.dylibmacOS等平台变体。在 .NET Framework 时代这份职责由clr.dllFramework 4或mscorwks.dll2.0/3.5承担而在现代 .NET 中coreclr.dll是调试、符号解析、GC 覆盖coverage等工具链直接引用的关键模块。例如 src/coreclr/vm/gccover.h 中的注释就明确提到代码必须让mscordaccore.dll能够link without getting an unsat symbol避免未解析符号说明 DAC 产物与 coreclr 产物之间存在严格的符号一致性约束。2.2 clr.dll.NET Framework 4 的 CLR 实现clr.dll: The implementation of the .NET Framework CLR since the .NET Framework 4.clr.dll是从 .NET Framework 4 开始作为 CLR 主实现而存在的运行时二进制。它与coreclr.dll是一对同职责、不同产品线的产物coreclr.dll服务于 .NET Core/.NET 5clr.dll服务于 .NET Framework 4 及以上版本Windows 平台。三、历史遗留产物mscorwks.dll 与 mscorsvr.dllmscorwks.dll: The .NET Framework CLR implementation up until version 2/3.5. It was called wks (pronounced works) because it originally contained the client or workstation GC. Up until the .NET Framework 2, there was another variant of the CLR that contained the server GC, called mscorsvr.dll. In the .NET Framework 2 release, the workstation and server GC were merged together in a single implementation, in mscorwks.dll, while mscorsvr.dll was deprecated.mscorwks.dll是 .NET Framework 2.0/3.5 时代的 CLR 实现。其名字里的 wks 读作 works来源于它最初只包含客户端clientGC即所谓的workstation GC工作站 GC。与之对应的还有mscorsvr.dll——在 .NET Framework 2 之前存在另一个包含server GC服务器 GC的 CLR 变体。也就是说早期 .NET Framework 1.x 时代CLR 根据 GC 类型拆分为两个 DLL文件名GC 类型状态mscorwks.dllWorkstation工作站GC.NET Framework 2/3.5 的 CLR 实现mscorsvr.dllServer服务器GC在 .NET Framework 2 中废弃从 .NET Framework 2 开始工作站 GC 与服务器 GC 被合并到单一实现mscorwks.dll中mscorsvr.dll随即被废弃。合并的收益是显而易见的运行时不必再维护两个几乎相同的 GC 二进制GC 的选择从加载哪个 DLL演变为运行时内部根据配置选择 GC 模式这也为后来现代 .NET 中通过配置切换工作站/服务器 GC 奠定了基础。四、调试专用产物DAC 系列mscordacwks / mscordaccore.dll4.1 两组对应的 DAC 变体mscordacwks: A variant of mscorwks.dll (for the .NET Framework CLR), used only/primarily while debugging. It contains the DAC version of the VM implementation.mscordaccore.dll: A variant of coreclr.dll (for .NET Core), used only/primarily while debugging. It contains the DAC version of the VM implementation.这是整份文档中技术含量最高的部分也是当前仓库中依然活跃的调试基础设施。mscordacwks.dll与mscordaccore.dll分别是mscordacwks.dll从mscorwks.dll.NET Framework CLR派生的变体主要/仅在调试时使用mscordaccore.dll从coreclr.dll.NET Core派生的变体主要/仅在调试时使用。两者都包含DACData Access Component数据访问组件版本的 VM 实现。DAC 是 out-of-process进程外调试的核心调试器如 Visual Studio、WinDbg、SOS 扩展不直接运行目标进程中的运行时代码而是加载 DAC 模块让它以宿主进程中的运行时代码身份去读取目标进程或 dump 文件的内存从而解析托管对象、方法表、托管堆栈等结构。4.2 DAC 为什么需要单独的二进制关于 DAC 的设计动机仓库中的 dac-notes.md 给出了完整的解释The DAC is conceptually a subset of the runtimes execution engine code that runs out-of-process. This means that it can operate on a dump file, even on a machine that has no runtime installed. Its implementation consists mainly of a set of macros and templates, combined with conditional compilation of the execution engines code. When the runtime is built, both clr.dll and mscordacwks.dll. For CoreCLR builds, the binaries are slightly different: coreclr.dll and msdaccore.dll.要点如下进程外运行DAC 本质上是从执行引擎源码中抽取出来、在目标进程外运行的子集。它可以分析 dump 文件甚至在没有安装运行时的机器上工作。同一份源码、条件编译DAC 并非重写一份 VM 代码而是通过预处理宏DACCESS_COMPILE对 VM 源码进行条件编译构建出专门面向调试的变体。严格版本匹配因为 DAC 从同一份源码编译而来调试器所用的 DAC 必须与目标运行时版本完全匹配——任何字段增删都会导致对象布局不一致进而使 DAC 无法正确 marshal 对象。命名演变注意 dac-notes.md写于 2007 年中 CoreCLR 的 DAC 名为msdaccore.dll而 dotnet-filenames.md更新于 .NET Core 时代记录为mscordaccore.dll——这反映了 DAC 二进制命名的历史演变以 dotnet-filenames.md 为准现代产物是mscordaccore.dll。4.3 DAC 的核心机制host 与 target 地址空间DAC 工作在两套地址空间的交界处Target目标被调试的进程或 dump 的内存地址空间Host宿主运行调试器与 DAC 代码的进程地址空间。dac-notes.md 中强调Notice that the DAC readsthe memory of the target process. Its important to realize that the debugger and the debuggee are separate processes with separate address spaces. Thus it is important to make a clear distinction between target memory and host memory.为此VM 源码引入了一套强类型体系来区分两类指针T *宿主host指针PTR_T如PTR_MethodTable、PTR_DomainFile目标target指针由 src/coreclr/inc/daccess.h 中的宏DPTR、GPTR、VPTR、SPTR等声明。关键设计在于这些宏在非 DAC 构建中展开为空操作PTR_T就是T *因此 DAC 机制对普通运行时构建零性能损耗而在 DAC 构建中PTR_T展开为带缓存语义的模板类__DPtrT其解引用运算符会自动从目标内存读取数据、marshal 到 DAC 缓存缓存条目类型为DAC_INSTANCE并返回宿主地址。宿主与目标地址的区分本质上是强类型化用错地址空间会导致不可预测的结果。此外DAC 代码必须保持non-invasive非侵入性——不能写目标地址空间也不能触发立即 GC通过DACCESS_COMPILE条件编译与find/create 语义拆分两种手段来保证。4.4 现代仓库中的 DAC 引用实证在当前仓库中DAC 相关代码依然活跃。以 src/coreclr/vm/cdacstress.cpp 为例其中定义了#define CDAC_LIB_NAME MAKEDLLNAME_W(W(mscordaccore_universal))并注释说明Load mscordaccore_universal from next to coreclr以及运行时在该库缺失时会给出提示 (check that mscordaccore_universal is shipped next to coreclr)。这里的mscordaccore_universal正是mscordaccore.dll命名族的直接延续——它需要与coreclr产物放在同一目录shipped next to coreclr这与 dotnet-filenames.md 对 mscordaccore.dll coreclr.dll 的变体的定义完全吻合。另一个实证在 src/coreclr/vm/gccover.h 的注释中该文件说明某些符号需要 mscordaccore.dll to link without getting an unsat symbol——即 VM 代码的符号必须能被 DAC 版本链接解析这印证了 DAC 与运行时共享同一份 VM 源码的事实。4.5 Cross-DAC跨架构调试变体如果被调试的是不同架构产生的 dump仓库还提供了crossdac跨编译 DAC机制见 docs/design/features/cross-dac.mdcrossdac 是在一个平台上编译、用于调试另一架构目标产生的 dump 的 DAC当前实现是在 Windows 上运行、同位数、目标为 *nix 变体从而允许使用 Windows 调试工具分析 *nix 进程产生的 dump与普通 DAC 一样每个 crossdac 必须与其运行时严格匹配DAC 被索引在符号服务器上供调试器按需获取由于需要正确解析目标架构的内存布局crossdac 代码中HOST_*与TARGET_*宏的配置不同默认以TARGET_*为准仅宿主相关服务文件 I/O、内存分配以HOST为准。五、速查总表文件名产品线职责状态coreclr.dll.NET Core / .NET 5CoreCLR 运行时实现本体当代产物clr.dll.NET Framework 4CLR 实现当代产物.NET Framework 线mscorwks.dll.NET Framework 2/3.5CLR 实现wksworkstation GC历史产物mscorsvr.dll.NET Framework 1.x含 server GC 的 CLR 变体已废弃Framework 2 起合并入 mscorwks.dllmscordacwks.NET Frameworkmscorwks.dll 的 DAC 变体仅调试用历史产物mscordaccore.dll.NET Core / .NET 5coreclr.dll 的 DAC 变体仅调试用当代产物六、如何进一步在仓库中探索如果你希望在当前仓库中继续深挖这些文件名的实现细节推荐按以下路径阅读文件名定义总纲docs/project/dotnet-filenames.mdDAC 完整设计host/target、PTR 类型、DACCESS_COMPILE、marshaling 原理docs/design/coreclr/botr/dac-notes.mdCross-DAC 跨架构调试设计docs/design/features/cross-dac.mdDAC 指针类型的宏与模板实现src/coreclr/inc/daccess.hDAC 全局变量表实现src/coreclr/debug/ee/dactable.cppmscordaccore_universal的加载逻辑src/coreclr/vm/cdacstress.cppGC 覆盖代码对 DAC 符号一致性的要求src/coreclr/vm/gccover.h术语背景docs/project/glossary.md七、总结coreclr.dll与clr.dll分别代表现代 .NET 与 .NET Framework 两条产品线的运行时本体mscorwks.dll/mscorsvr.dll记录了工作站 GC 与服务器 GC 从分裂到合并的历史而mscordacwks/mscordaccore.dll则是 DAC 机制在两条产品线上的调试专用变体。理解这些文件名不仅能帮助你在调试器符号加载、dump 分析、SOS 扩展使用时做出正确判断也能让你对 .NET 运行时从同一份 VM 源码条件编译出多种产物的构建哲学有更直观的认知。【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 .NET 运行时“神秘文件名“全解：从 coreclr.dll 到 mscordacwks / mscordaccore.dll
.NET 运行时神秘文件名全解从 coreclr.dll 到 mscordacwks / mscordaccore.dll【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime导读.NET 自诞生以来积累了多个让开发者困惑的二进制文件名——coreclr.dll、clr.dll、mscorwks.dll、mscordacwks.dll、mscordaccore.dll……它们分别是什么彼此之间是什么关系本文以 docs/project/dotnet-filenames.md 这份文件名百科全书为骨架结合当前仓库.NET 跨平台运行时 runtime中的 DAC 设计文档、Cross-DAC 说明 以及 coreclr VM 源码 中的实际引用逐一厘清这些文件名的由来、职责与演变帮助读者在调试、符号加载、dump 分析等场景中准确识别它们。一、为什么 .NET 会有这么多神秘文件名.NET 是一个横跨二十余年、历经多代产品线.NET Framework 1.0/2.0/3.5 → .NET Framework 4 → .NET Core → .NET 5 统一运行时的开源运行时。随着运行时实现的分裂与合并、工作站/服务器 GC 的整合、以及调试基础设施DAC的引入历史遗留与当代产物叠加形成了大量看名字猜不出用途的 DLL。这份 dotnet-filenames.md 存在的意义正是为这些文件名给出权威定义。它本质上是一份运行时二进制命名约定的速查手册覆盖了从 .NET Framework 时代到现代 CoreCLR 的所有关键产物。二、当代运行时的两大核心产物2.1 coreclr.dllCoreCLR 的实现本体coreclr.dll: The implementation of CoreCLR.coreclr.dll就是 CoreCLR现代 .NET 的跨平台运行时核心的二进制实现。在当前仓库中CoreCLR 的源码位于 src/coreclr涵盖 JITsrc/coreclr/jit、GCsrc/coreclr/gc、VMsrc/coreclr/vm、PALsrc/coreclr/pal等子系统最终被链接为coreclr.dllWindows/libcoreclr.soLinux/libcoreclr.dylibmacOS等平台变体。在 .NET Framework 时代这份职责由clr.dllFramework 4或mscorwks.dll2.0/3.5承担而在现代 .NET 中coreclr.dll是调试、符号解析、GC 覆盖coverage等工具链直接引用的关键模块。例如 src/coreclr/vm/gccover.h 中的注释就明确提到代码必须让mscordaccore.dll能够link without getting an unsat symbol避免未解析符号说明 DAC 产物与 coreclr 产物之间存在严格的符号一致性约束。2.2 clr.dll.NET Framework 4 的 CLR 实现clr.dll: The implementation of the .NET Framework CLR since the .NET Framework 4.clr.dll是从 .NET Framework 4 开始作为 CLR 主实现而存在的运行时二进制。它与coreclr.dll是一对同职责、不同产品线的产物coreclr.dll服务于 .NET Core/.NET 5clr.dll服务于 .NET Framework 4 及以上版本Windows 平台。三、历史遗留产物mscorwks.dll 与 mscorsvr.dllmscorwks.dll: The .NET Framework CLR implementation up until version 2/3.5. It was called wks (pronounced works) because it originally contained the client or workstation GC. Up until the .NET Framework 2, there was another variant of the CLR that contained the server GC, called mscorsvr.dll. In the .NET Framework 2 release, the workstation and server GC were merged together in a single implementation, in mscorwks.dll, while mscorsvr.dll was deprecated.mscorwks.dll是 .NET Framework 2.0/3.5 时代的 CLR 实现。其名字里的 wks 读作 works来源于它最初只包含客户端clientGC即所谓的workstation GC工作站 GC。与之对应的还有mscorsvr.dll——在 .NET Framework 2 之前存在另一个包含server GC服务器 GC的 CLR 变体。也就是说早期 .NET Framework 1.x 时代CLR 根据 GC 类型拆分为两个 DLL文件名GC 类型状态mscorwks.dllWorkstation工作站GC.NET Framework 2/3.5 的 CLR 实现mscorsvr.dllServer服务器GC在 .NET Framework 2 中废弃从 .NET Framework 2 开始工作站 GC 与服务器 GC 被合并到单一实现mscorwks.dll中mscorsvr.dll随即被废弃。合并的收益是显而易见的运行时不必再维护两个几乎相同的 GC 二进制GC 的选择从加载哪个 DLL演变为运行时内部根据配置选择 GC 模式这也为后来现代 .NET 中通过配置切换工作站/服务器 GC 奠定了基础。四、调试专用产物DAC 系列mscordacwks / mscordaccore.dll4.1 两组对应的 DAC 变体mscordacwks: A variant of mscorwks.dll (for the .NET Framework CLR), used only/primarily while debugging. It contains the DAC version of the VM implementation.mscordaccore.dll: A variant of coreclr.dll (for .NET Core), used only/primarily while debugging. It contains the DAC version of the VM implementation.这是整份文档中技术含量最高的部分也是当前仓库中依然活跃的调试基础设施。mscordacwks.dll与mscordaccore.dll分别是mscordacwks.dll从mscorwks.dll.NET Framework CLR派生的变体主要/仅在调试时使用mscordaccore.dll从coreclr.dll.NET Core派生的变体主要/仅在调试时使用。两者都包含DACData Access Component数据访问组件版本的 VM 实现。DAC 是 out-of-process进程外调试的核心调试器如 Visual Studio、WinDbg、SOS 扩展不直接运行目标进程中的运行时代码而是加载 DAC 模块让它以宿主进程中的运行时代码身份去读取目标进程或 dump 文件的内存从而解析托管对象、方法表、托管堆栈等结构。4.2 DAC 为什么需要单独的二进制关于 DAC 的设计动机仓库中的 dac-notes.md 给出了完整的解释The DAC is conceptually a subset of the runtimes execution engine code that runs out-of-process. This means that it can operate on a dump file, even on a machine that has no runtime installed. Its implementation consists mainly of a set of macros and templates, combined with conditional compilation of the execution engines code. When the runtime is built, both clr.dll and mscordacwks.dll. For CoreCLR builds, the binaries are slightly different: coreclr.dll and msdaccore.dll.要点如下进程外运行DAC 本质上是从执行引擎源码中抽取出来、在目标进程外运行的子集。它可以分析 dump 文件甚至在没有安装运行时的机器上工作。同一份源码、条件编译DAC 并非重写一份 VM 代码而是通过预处理宏DACCESS_COMPILE对 VM 源码进行条件编译构建出专门面向调试的变体。严格版本匹配因为 DAC 从同一份源码编译而来调试器所用的 DAC 必须与目标运行时版本完全匹配——任何字段增删都会导致对象布局不一致进而使 DAC 无法正确 marshal 对象。命名演变注意 dac-notes.md写于 2007 年中 CoreCLR 的 DAC 名为msdaccore.dll而 dotnet-filenames.md更新于 .NET Core 时代记录为mscordaccore.dll——这反映了 DAC 二进制命名的历史演变以 dotnet-filenames.md 为准现代产物是mscordaccore.dll。4.3 DAC 的核心机制host 与 target 地址空间DAC 工作在两套地址空间的交界处Target目标被调试的进程或 dump 的内存地址空间Host宿主运行调试器与 DAC 代码的进程地址空间。dac-notes.md 中强调Notice that the DAC readsthe memory of the target process. Its important to realize that the debugger and the debuggee are separate processes with separate address spaces. Thus it is important to make a clear distinction between target memory and host memory.为此VM 源码引入了一套强类型体系来区分两类指针T *宿主host指针PTR_T如PTR_MethodTable、PTR_DomainFile目标target指针由 src/coreclr/inc/daccess.h 中的宏DPTR、GPTR、VPTR、SPTR等声明。关键设计在于这些宏在非 DAC 构建中展开为空操作PTR_T就是T *因此 DAC 机制对普通运行时构建零性能损耗而在 DAC 构建中PTR_T展开为带缓存语义的模板类__DPtrT其解引用运算符会自动从目标内存读取数据、marshal 到 DAC 缓存缓存条目类型为DAC_INSTANCE并返回宿主地址。宿主与目标地址的区分本质上是强类型化用错地址空间会导致不可预测的结果。此外DAC 代码必须保持non-invasive非侵入性——不能写目标地址空间也不能触发立即 GC通过DACCESS_COMPILE条件编译与find/create 语义拆分两种手段来保证。4.4 现代仓库中的 DAC 引用实证在当前仓库中DAC 相关代码依然活跃。以 src/coreclr/vm/cdacstress.cpp 为例其中定义了#define CDAC_LIB_NAME MAKEDLLNAME_W(W(mscordaccore_universal))并注释说明Load mscordaccore_universal from next to coreclr以及运行时在该库缺失时会给出提示 (check that mscordaccore_universal is shipped next to coreclr)。这里的mscordaccore_universal正是mscordaccore.dll命名族的直接延续——它需要与coreclr产物放在同一目录shipped next to coreclr这与 dotnet-filenames.md 对 mscordaccore.dll coreclr.dll 的变体的定义完全吻合。另一个实证在 src/coreclr/vm/gccover.h 的注释中该文件说明某些符号需要 mscordaccore.dll to link without getting an unsat symbol——即 VM 代码的符号必须能被 DAC 版本链接解析这印证了 DAC 与运行时共享同一份 VM 源码的事实。4.5 Cross-DAC跨架构调试变体如果被调试的是不同架构产生的 dump仓库还提供了crossdac跨编译 DAC机制见 docs/design/features/cross-dac.mdcrossdac 是在一个平台上编译、用于调试另一架构目标产生的 dump 的 DAC当前实现是在 Windows 上运行、同位数、目标为 *nix 变体从而允许使用 Windows 调试工具分析 *nix 进程产生的 dump与普通 DAC 一样每个 crossdac 必须与其运行时严格匹配DAC 被索引在符号服务器上供调试器按需获取由于需要正确解析目标架构的内存布局crossdac 代码中HOST_*与TARGET_*宏的配置不同默认以TARGET_*为准仅宿主相关服务文件 I/O、内存分配以HOST为准。五、速查总表文件名产品线职责状态coreclr.dll.NET Core / .NET 5CoreCLR 运行时实现本体当代产物clr.dll.NET Framework 4CLR 实现当代产物.NET Framework 线mscorwks.dll.NET Framework 2/3.5CLR 实现wksworkstation GC历史产物mscorsvr.dll.NET Framework 1.x含 server GC 的 CLR 变体已废弃Framework 2 起合并入 mscorwks.dllmscordacwks.NET Frameworkmscorwks.dll 的 DAC 变体仅调试用历史产物mscordaccore.dll.NET Core / .NET 5coreclr.dll 的 DAC 变体仅调试用当代产物六、如何进一步在仓库中探索如果你希望在当前仓库中继续深挖这些文件名的实现细节推荐按以下路径阅读文件名定义总纲docs/project/dotnet-filenames.mdDAC 完整设计host/target、PTR 类型、DACCESS_COMPILE、marshaling 原理docs/design/coreclr/botr/dac-notes.mdCross-DAC 跨架构调试设计docs/design/features/cross-dac.mdDAC 指针类型的宏与模板实现src/coreclr/inc/daccess.hDAC 全局变量表实现src/coreclr/debug/ee/dactable.cppmscordaccore_universal的加载逻辑src/coreclr/vm/cdacstress.cppGC 覆盖代码对 DAC 符号一致性的要求src/coreclr/vm/gccover.h术语背景docs/project/glossary.md七、总结coreclr.dll与clr.dll分别代表现代 .NET 与 .NET Framework 两条产品线的运行时本体mscorwks.dll/mscorsvr.dll记录了工作站 GC 与服务器 GC 从分裂到合并的历史而mscordacwks/mscordaccore.dll则是 DAC 机制在两条产品线上的调试专用变体。理解这些文件名不仅能帮助你在调试器符号加载、dump 分析、SOS 扩展使用时做出正确判断也能让你对 .NET 运行时从同一份 VM 源码条件编译出多种产物的构建哲学有更直观的认知。【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考