Диагностика зависания вызова Interop в настольном приложении C# — только для некоторых пользователей
У нас есть настольное приложение C# (Windows 10 x64), которое зависает при запуске для очень небольшого числа наших пользователей. Я никогда не видел этого раньше, и я не могу воспроизвести это локально.
Наше приложение использует нашу библиотеку C# (управляемую), которая включает некоторые вызовы взаимодействия с нашей C (собственной) библиотекой DLL. Используя специальные сборки и щедрую помощь пользователей, я смог установить, что:
- Наша управляемая библиотека загружается нормально; Я могу получить доступ к классам и статическим членам из нашего EXE.
- Библиотека содержит интероп-оболочки для набора API-интерфейсов в нашей собственной DLL, и как только один из них вызывается, приложение зависает.
Это не работает только для нескольких пользователей, этот же код был протестирован и отлажен и отлично работает для тысяч пользователей.
- Я заменил первый неудачный вызов Interop на тот, который не принимает аргументов и возвращает постоянное значение типа int, но все равно зависает.
- Я запустил DEPENDS.EXE в нашей DLL и убедился, что мы отправляем/устанавливаем все необходимые зависимости DLL.
- У меня были затронутые пользователи, запускавшие распространяемый установщик Visual C++ — никаких улучшений
- Перечисленные выше причины обычно приводят к закрытию приложения, но это приложение зависает без каких-либо окон сообщений или другого пользовательского интерфейса.
Может ли кто-нибудь предложить варианты, как это можно диагностировать удаленно?
Погуглите "c# minidump", чтобы продвинуться вперед. Этот хит выглядит неплохо.
Ответы 1
Оказалось, что это конкретная сторонняя DLL, которая зависала при загрузке (либо запуск CRT, либо основная DLL). Мы много проверяли версии зависимостей DLL, пути поиска DLL и т. д. Но так и не выяснили, в чем именно заключалась проблема; только то, что конкретная DLL (которая нормально загружается в наших системах) будет блокироваться на крошечном проценте систем наших пользователей.
Решение состояло в том, чтобы получить более новую сборку DLL. Этот конкретный набор сторонних библиотек был создан с использованием инструментов, отличных от Microsoft, поэтому, возможно, в их компиляторе или компоновщике была какая-то неуловимая ошибка.
В прошлом у меня были проблемы с
exe, работающим на большинстве виртуальных машин, но сбой на других, это было очень прерывистым и было большой проблемой в ar$e. Я использовал этот инструмент, чтобы найти проблему: (learn.microsoft.com/en-us/windows-hardware/drivers/debugger/… ). Если вы не пробовали, это может вам помочь.