Имеем ПО с С-API. ПО вы не знаете, оно далеко не массовое и доступно только покупателям.
Через С-API присоединяем к ПО свою DLL. Любители кодов могут не беспокоится, их не будет - коды ДЛЛ весят ~90КБ. Вопрос о принципах, а не о кодах. Умение кодировать здесь не пригодится.))
Все работает, ДЛЛ получает однотипный поток данных и их обрабатывает, все прекрасно. Есть одно но, программа иногда выдает Unknown error по взаимодействию с ДЛЛ. При этом может повиснуть, может не повиснуть и продолжить работу, может вообще закрыться. Это может случиться в любой момент - может произойти через 15мин после запуска, а может и весь день работать без сбоев. Иногда сбои происходят чуть-ли не регулярно. Какие-то явные причины их появления отсутствуют. Непредсказуемо.
Надо сказать, что ПО и само особой стабильностью не отличается, но ДЛЛ явно усугубляет эту нестабильность.
Теперь, что делается. Увожу обработку в ДЛЛ в потоки, чтобы освободить вызывающие потоки ПО. Ну, м.б чуть лучше стало, но не более.
Вопрос, собственно, о методах борьбы с такими вот непонятками, ну, и что еще можно предпринять кроме распараллеливания. Ну, а задача, максимально устранить влияние ДЛЛ на нестабильность самого ПО - она есть, но в разумных пределах.

"Есть многое на свете, друг Горацио, что и не сразу в голову придет."
М. Твен "Приключения Геккельбери Финна"

По возможности отвечу на все посты сразу.
О ПО, кроме C_API мы действительно знаем оч мало. Из диспетчера задач знаем, что в нем задействовано 16 потоков. Сколько из них взаимодействует с нашей ДЛЛ неизвестно. Кстати, как это узнать?
С ДЛЛ возможно два вида взаимодействия:
1. Вызов функции ПО из ДЛЛ.
2. Вызов различных функций ДЛЛ по разным событиям в ПО. Сколько потоков обслуживают события - неизвестно. Известно, что до окончания обработки события, и освобождения его потока, функция ДЛЛ на аналогичное событие не может быть вызвана, и событие будет находиться в очереди.
С другой стороны, функции обработки различных событий никак не пересекаются, а у общих переменных только один писатель и здесь конфликтов быть не должно.
Изначально ДЛЛ писалась как однопоточная (в смысле создания потоков внутри самой ДЛЛ). Однако, уже изначально планировалось обработку событий вынести в отдельные потоки, чтобы как можно быстрей освободить поток ПО вызывающий функции ДЛЛ.
Сейчас основная гипотеза следующая.
С какого бодуна, функции тысячи раз отрабатывающие штатно, должны на однотипных данных отрабатывать неправильно и давать сбои. Стало быть, что-то не так с входными данными. Т.е., возможно переполнение очереди событий в самом ПО.
Отсюда, необходимо минимизация времени обработки событий, уход в потоки и освобождения потока(ов) ПО вызывающего функции ДЛЛ. Сейчас реализовано только частично.
Сегодня уже час работы, - все пока ОК. Но и раньше такое случалось, и поболе. Выводы делать рано.

PetroNotC SharpYUBA,
Если ПО (экзешник?) в исходнике вам недоступен, то тут писали что делаете свой exe и тестите нагрузочным вашу dll.
Нереально. И не рацо писать аналог ихнего C-API и имитатор данных к нему. И это, в итоге, будет совсем другое ПО.) При больших трудозатратах так мы ничего не выясним.
ИМХО, на данном этапе единственная здравая идея - не грузить потоки ПО своей ДЛЛ. Взял данные - освободил поток ПО. Обработка уже в других потоках.
Имхо, подобные задачи надо решать на системном уровне, а не на уровне - трясти надо. Обвесить все try и логами всегда успеется.)
Скажем, сегодня сбоев вообще нет. Но это еще ничего не значит.))

Кажется двигаюсь в правильном направлении. Сегодня ни одного сбоя, за исключением разрыва связи с источником данных. Это нормально, данные можно снимать только в установившемся режиме. Пока в потоки вынесены только две высоконагруженные задачи.
Ну, и кусок лога.

PS этот id часа за 3 набрался после обнуления.

Dima T,, там нет проблем многопоточность, по крайней мере пока. В дальнейше могут появиться.
Похоже, введение потоков на данном этапе все решило.