我之前碰到过几乎一模一样的问题，结合你给出的错误码和已经做过的排查步骤，给你几个针对性的解决方案，按顺序试试：

1. 先解决80070570对应的文件损坏问题 #

这个错误码的核心是「文件或目录损坏且无法读取」，哪怕你重装了IIS，系统层面可能还有残留的32位组件损坏：

• 以管理员身份打开命令提示符，运行sfc /scannow，让系统自动扫描并修复损坏的系统文件
• 如果sfc没解决，接着运行DISM /Online /Cleanup-Image /RestoreHealth，修复Windows系统映像的完整性
• 检查你的Web应用物理路径：把里面的文件暂时移走，只放一个简单的index.html（内容随便写点），再绑定到32位应用池测试——如果这样能正常运行，说明是你原应用里有损坏的文件或程序集

2. 排查32位.NET运行时的兼容性 #

默认应用池的.NET版本可能和VS2019的32位组件不匹配：

• 打开IIS管理器，右键你的应用池→「高级设置」，确认「.NET CLR版本」选的是已安装的32位.NET Framework版本（比如v4.0.30319）
• 去控制面板→「程序和功能」，检查是否安装了「.NET Framework 4.x（32位）」组件，要是没装，手动下载安装对应的32位运行时
• 如果你的Web应用是VS2019创建的，打开项目属性→「生成」，确认「目标平台」是x86，发布时选择「x86」平台，避免混合32/64位程序集导致冲突

3. 修复应用池标识的32位权限问题 #

虽然你给了Everyone权限，但32位模式下应用池的标识可能需要特殊权限：

• 临时把应用池的标识改成「LocalSystem」（只是测试用，不要长期用这个高权限标识），启动应用池试试——如果能正常运行，说明是权限问题
• 改回「ApplicationPoolIdentity」，手动给这个标识添加Web应用物理路径的完全控制权限，同时检查C:\Windows\SysWOW64\inetsrv目录（32位IIS组件所在），确保应用池标识有读取权限

4. 针对70050780的进程级排查 #

这个错误码和IIS工作进程初始化失败有关，大概率是32位w3wp.exe加载了损坏的模块：

• 用微软的Process Monitor工具，过滤w3wp.exe的操作，看应用池崩溃前有没有「访问被拒绝」或「文件找不到」的记录，定位问题文件
• 管理员身份打开命令提示符，运行appcmd start apppool /apppool.name:"你的应用池名称"，实时查看启动时的报错信息，比事件查看器更直接

额外测试建议 #

先创建一个全新的空Web站点，绑定到32位新应用池，只放静态HTML文件测试——如果正常，再逐步迁移原应用的文件，每次添加一部分就测试一次，这样能快速定位到导致崩溃的具体文件或配置。

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