#, чуть выше упоминал, удивительно, но это NLog. AsyncTargetWrapper - это их класс.
По поводу бесконечных циклов - требуется низкоуровневый мониторинг за устройствами. Это специфика приложения.
По поводу того, что они плодятся и не закрываются - тоже прекрасно понимаю.
Не сразу весь пул потоков исчезает, а постепенно - значит после запроса, поток должен начать выполняться. Если бы он завис в середине метода, то это показал бы стектрейс потока. А так складывается впечатление, что вместо того, чтобы вернуться в пул, он блокируется где-то на уровне системных библиотек. UI поток практически всё время свободен, так что они точно не пытаются в него попасть.
И опять-таки, стектрейсы таймеров и бесконечных циклов прекрасно видны и доступны для анализа.
#, забить все использования потоков логами хотелось бы оставить как крайнюю меру. К тому же абсолютно никак не поможет в случае проблем в сторонней библиотеке. Разве что дать чуть больше уверенности, что ищем не там, где нужно.
Изначально требовалась помощь с исследованием именно этого конкретно стектрейса конкретного дампа. У нас уже есть зафиксированный случай, когда повисание потоков происходит в сторонней библиотеке, поэтому хотелось бы определить связаны они или нет.
То есть ожидался ответы вида: "стектрейс выглядит странно, но он происходит если {причина}", "стектрейс криво отображается из-за инструмента, попробуйте {имя_инструмента}", "стектрейс кривой из-за дампа, при поиске проблемы не поможет". Все же комментарии и ответы выглядят как "никогда в жизни не видел такой стектрейс, поэтому сами виноваты, что плодите потоки, вот вам очевидные способы проверить это". Прошу прощения, что не смог сразу корректно сформулировать вопрос, так как не ждал таких ответов.
1. Стек смотрю с помощью Visual Studio, окно Parallel Stacks. Подгружены все библиотеки + скомпилированное приложение + исходники.
2. Дамп создаётся с помощью ProcDump. Судя по размеру, это действительно минидамп
3. BSOD не было, приложение повисло, это поймал ProcDump.
5. Потоки генерируются вручную. Их есть три вида: ради операций UI (создаются только через фабрику, жестко отслеживаются), таймеры (используется безопасная реализация, когда следующий запускается только после завершения выполнения кода, в логах нет связанных с ними проблем) и бесконечные циклы мониторинга (их ограниченное количество, они хорошо видны в списке потоков). Именно тот факт, что нет видимых проблем + странный стектрейс побудил задать этот вопрос.
На самом деле, я умолчал, что у нас были проблемы очень похожие проблемы с Nlog, но там был четко прослеживался стектрейс:
Соответственно, хотелось понять как лучше изучить дамп, и выяснить связаны ли эти две проблемы.
#, проект большой, потоки используются часто, баг единичный, нет стектрейса в управляемом коде. Искать ошибку в коде, значит искать иголку в стоге сена. Поэтому хотелось бы узнать, может есть инструменты, которые позволят больше узнать о проблеме.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
По поводу бесконечных циклов - требуется низкоуровневый мониторинг за устройствами. Это специфика приложения.
По поводу того, что они плодятся и не закрываются - тоже прекрасно понимаю.
Не сразу весь пул потоков исчезает, а постепенно - значит после запроса, поток должен начать выполняться. Если бы он завис в середине метода, то это показал бы стектрейс потока. А так складывается впечатление, что вместо того, чтобы вернуться в пул, он блокируется где-то на уровне системных библиотек. UI поток практически всё время свободен, так что они точно не пытаются в него попасть.
И опять-таки, стектрейсы таймеров и бесконечных циклов прекрасно видны и доступны для анализа.
В любом случае, большое спасибо.