32位WinForm遗留应用Session0/1内存差异致OOM问题咨询

首先纠正一个认知偏差：Session0下不存在「所有子进程内存被统一计入父进程统计」的逻辑，你观察到的总内存到1300MB就崩溃，本质是Windows会话隔离机制下的会话级内存配额限制导致的，和单进程的32位地址空间上限无关：

• 单32位进程默认用户态虚拟地址空间上限为2GB，实际可申请的连续内存区间通常在1300~1600MB，你单实例200MB的占用远没有触碰到单进程阈值，手动在Session1启动时运行正常也验证了这一点。
• Windows每个会话（交互会话Session1、服务会话Session0）都有独立的全局内存配额、桌面堆配额，两类会话的默认配额阈值差异极大：
  • 手动在Session1启动程序时，进程运行在交互式用户桌面，默认交互桌面堆配额为3MB，整个会话的总虚拟内存配额阈值很高，8个实例总占用1.6GB远达不到配额上限，每个进程独立占用自己的地址空间，不会互相干扰。
  • 计划任务配置为「不管用户是否登录都要运行」时，进程会被拉起在Session0的非交互服务桌面运行，这个桌面的默认堆配额仅为512KB，整个Session0针对非交互进程的总虚拟内存配额默认阈值就在1300MB左右。你启动的所有子进程都归属在同一个非交互桌面下，所有进程的GDI对象、User对象、会话共享内存占用都要抢占这个总配额池，总占用摸到阈值时，整个会话下的所有进程都会被拒绝内存申请，直接触发OOM崩溃。
• 你使用的VB6内置Shell函数放大了这个问题：该函数封装CreateProcess时默认不会传入CREATE_NEW_PROCESS_GROUP标记，也不会为子进程绑定独立作业对象（Job Object），子进程会直接继承父进程的配额令牌，所有进程被纳入同一个配额统计池，不会因为启动多个进程就累加单进程的配额上限。

你可以通过任务管理器「详细信息」页核对：即使在Session0下崩溃时，每个A.exe进程的私有内存占用依然是200MB左右，不存在内存被算到父进程的情况，只是会话总配额耗尽导致所有进程都无法申请新内存。

• 配置级快速验证/修复：
  • 先验证根因：在计划任务配置页勾选「仅当用户登录时运行」，此时程序会被拉起在交互会话Session1，和你手动双击启动的环境完全一致，如果多实例运行正常，即可确认是Session0配额导致的问题。
  • 调整Session0配额：打开注册表定位到路径HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems，找到Windows键值，其中SharedSection段的格式为SharedSection=xxxx,yyyy,zzzz，第三个数字zzzz就是非交互桌面的堆大小（单位KB），默认值为512，可将其调整为2048~4096，重启系统后Session0的配额即可支撑8个实例并行运行。
• 代码级稳妥修复：
  替换VB6内置Shell调用逻辑，直接通过Win32 API调用CreateProcess拉起子进程，启动参数增加CREATE_NEW_PROCESS_GROUP标记，同时为每个子进程绑定独立的作业对象，单独设置单进程内存配额，避免所有进程共享同一个配额池。
• 额外优化点：
  Session0非交互桌面下不要创建任何可见WinForm窗口、GDI绘图资源，这类资源在非交互桌面的内存开销是交互桌面的3~5倍，会加速配额耗尽。

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