退出码139对应的是段错误（SIGSEGV），意味着进程试图访问非法内存区域。结合你描述的场景（Windows上运行正常、Linux服务器上崩溃），大概率是下面几个原因之一，按顺序排查即可：

1. 检查CPU架构是否匹配 #

跨环境崩溃最常见的原因就是镜像架构和服务器不兼容：

• 在Linux服务器上运行命令查看镜像架构：

  docker inspect imageName | grep Architecture
  

• 同时运行uname -m查看服务器的CPU架构（比如amd64、arm64）
• 如果两者不匹配（比如你在Windows x86_64环境构建了amd64镜像，但服务器是arm64），需要用docker buildx跨平台构建对应架构的镜像。

2. 替换Alpine基础镜像为glibc版本 #

ASP.NET Core 2.0属于早期版本，对Alpine使用的musl libc兼容性有限。换成基于glibc的官方.NET运行时镜像，能直接避开大部分这类兼容性坑：
修改你的Dockerfile，把基础镜像从Alpine版换成普通版：

# 替换之前的Alpine基础镜像
FROM microsoft/dotnet:2.0-runtime
WORKDIR /app
COPY ./publish .
ENTRYPOINT ["dotnet", "YourApp.dll"]

重新构建镜像后再运行测试。

3. 为Alpine镜像添加glibc兼容层 #

如果坚持要用Alpine镜像，可以尝试安装libc6-compat兼容库，弥补musl和glibc的差异：
在Dockerfile中添加这一行：

RUN apk add --no-cache libc6-compat

这个兼容层能让很多依赖glibc的程序在Alpine上正常运行。

4. 排查网络初始化问题 #

你提到不带-d运行时显示到“Now listening on: ht...”就崩溃，也可以额外检查：

• 服务器的目标端口（xxxx）是否被其他进程占用，用netstat -tulpn | grep xxxx确认
• 尝试在docker run时添加--network host参数，直接使用主机网络测试，排除容器网络配置的问题

优先从架构和基础镜像这两个点入手，大概率能解决你的问题。

内容的提问来源于stack exchange，提问作者Jiayi