недавно обнаружил FM ZRANDOM_COMMIT - отчет работает себе и работает, а иногда бац и дамп.
"поубывал бы" креативщиков

А падает на одном и том же месте кода?
Если да, то ставить там бряк, и при помощи инструмента анализа памяти смотреть, какие таблицы раз от раза занимают разный объем.
Все полезней, чем просить форумских телепатов-экстрасенсов лечить по фотографии.

Задание фоновое - какой бряк?
Да я в st22 вижу на чем падает - один и тот же селект во внутреннюю таблицу. Через 5 минут тот же селект проходит нормально.
Ошибка можно сказать спорадическая - единственный нюанс, код выполняется один и тот же для разных БЕ, а дамп только на одной конкретной БЕ, в смысле всегда на одной и той же.
Но очень эпизодически.

75 гигов на 10 wp(8 гигов каждый). Это получается что десятый wp у вас всего на 3 гига. Вот и падают в этом wp задания если в него попадает БЕ в которой огромное количество данных для выборки. По БЕ с малым количеством данных и 3 гигов вполне хватает.

Варианты поставить бряк есть:
1. Запускать задание в диалоге
2. Написать в коде бесконечный цикл при наличии установленного где-нибудь отладочного параметра и свалить в этом цикле фоновое задание в отладчик через sm51.
В любом случае, так вы сможете хоть какие-то фактические наблюдения провести, а не гадать на кофейной гуще.

Можно еще использовать "неразрушающий контроль" (т.е. без брекпоинтов и бесконечных циклов): т.к. вы определились с местом падения, вставить в нем log-point. В нем скидывать в лог инфу, которая поможет вам определить причину проблемы.

Я бы посоветовал забить. Причины, скорее всего, найти не удастся.
Есть возможные объяснения.

Во-первых, как здесь уже упоминалось, есть такая штука как дефрагментация памяти, весьма динамическая. Что, собственно. касается всего чего угодно, а не только сапа.
И вполне реально, что если в какой-то момент приложение просит у системы, допустим, еще 10М памяти, а у системы одним куском этих 10М нет. И тогда облом. в смысле дамп.
Хотя при этом в сумме всех кусочком и 20М наберется. И сборщик мусора не успел/не смог к этому времени отработать.
А в следующий раз все сложится.

Второй вариант - дело может быть в том как само приложение написано. Один раз оно уже запускалось на тех же данных.
Вполне возможно что часть из них в первом запуске уже было обработано, какие-то изменения записаны. И по второму разу эти данные уже не трогаются, соответственно памяти нужно меньше.
Если это Z, то можно у авторов поинтересоваться правда ли это. Если стандарт - то ХЗ. Опять же абаперов натравить, может в исходниках посмотрят.

Или забить