[Regression] RedM physical-player-extension build 36547 causes heap corruption on startup

RedM Discussion Bug Reports
1

After today’s update of the
specific/feature/redm-physical-player-extension channel, RedM updated
from client build 36062 to 36547.

Since this update, RedM crashes during startup approximately 5–7 seconds
after RedM_b1491_GTAProcess.exe starts.

This is reproducible for all tested players of our server since the
feature-channel update.

Environment

RedM client: 2.0.0.36547
Previous working client: 2.0.0.36062
Update channel: specific/feature/redm-physical-player-extension
RDR2: 1.0.1491.50 / b1491
Windows: 10.0.26100

Reproduction

  1. Use:
    UpdateChannel=specific/feature/redm-physical-player-extension
  2. Let RedM update to build 36547.
  3. Start RedM normally.
  4. RedM_b1491_GTAProcess.exe starts.
  5. After approximately 5–7 seconds RedM crashes.

The issue did not occur with build 36062 on the same systems.

Regular RedM update channels also start successfully, but cannot be used
with our server because of a client/server version mismatch.

Crash dump analysis

WinDbg !analyze -v:

Failure bucket:
HEAP_CORRUPTION_c0000374_RedM_b1491_GTAProcess.exe!Unknown

Exception:
0xC0000374 (STATUS_HEAP_CORRUPTION)

Process:
RedM_b1491_GTAProcess.exe

Image version:
2.0.0.36547

Relevant stack:

ntdll!RtlReportFatalFailure
ntdll!RtlReportCriticalFailure
ntdll!RtlpHeapHandleError
ntdll!RtlpHpHeapHandleError
ntdll!RtlSizeHeap
RedM_b1491_GTAProcess+0x2ED4CE1

Failure hash:
{2641f2ed-fc5a-413f-2c38-057d779112b0}

The crash was reproduced again after a complete Windows reboot and the
second dump produced the same exception, same offset and identical
failure hash.

Troubleshooting already performed

  • Tested without custom PoolSizesIncrease settings: same crash
  • Verified RDR2 version: 1.0.1491.50
  • Rebooted Windows and reproduced the crash
  • Regular RedM channels start normally
  • Previous feature-channel client 36062 still starts when its automatic
    update is bypassed, but Cfx authentication rejects the outdated client
    version when connecting
  • Multiple players reproduce the problem after the update to 36547

A crash dump and the full WinDbg !analyze -v output are available.

WinDbg Analyze

WinDbg !analyze -v result:

Failure.Bucket:
HEAP_CORRUPTION_c0000374_RedM_b1491_GTAProcess.exe!Unknown

Failure.Exception.Code:
0xc0000374

Failure.ProblemClass.Primary:
HEAP_CORRUPTION

Process:
RedM_b1491_GTAProcess.exe

Image version:
2.0.0.36547

Error:
0xc0000374 - A heap has been corrupted.

Relevant stack:

ntdll!RtlReportFatalFailure+0x9
ntdll!RtlReportCriticalFailure+0xa9
ntdll!RtlpHeapHandleError+0x12
ntdll!RtlpHpHeapHandleError+0x7a
ntdll!RtlSizeHeap+0x213
RedM_b1491_GTAProcess+0x2ED4CE1

Failure hash:
{2641f2ed-fc5a-413f-2c38-057d779112b0}

Faulting module reported by Windows:
ntdll.dll

Faulting offset:
0x117EB5

The crash occurs approximately 5–7 seconds after
RedM_b1491_GTAProcess.exe starts.

The crash was reproduced after a full Windows reboot. A second dump
produced the same:

  • Exception code 0xC0000374
  • HEAP_CORRUPTION failure classification
  • ntdll!RtlSizeHeap+0x213
  • RedM_b1491_GTAProcess+0x2ED4CE1
  • Failure hash {2641f2ed-fc5a-413f-2c38-057d779112b0}

This indicates that ntdll.dll is detecting an already corrupted heap;
ntdll.dll itself is not necessarily the component that originally
corrupted the memory.

e3fd1d48-aae9-4547-a60d-673174c65301.dmp (6.9 MB)

RedM_36547_WinDbg_Analysis.txt (3.3 KB)

1 Like