Не удается открыть файл дампа .NET Core 2 службы приложений Azure в WinDGB (в файле дампа присутствуют 2 среды выполнения)

У меня проблемы с открытием файла дампа процесса .NET Core в WinDBG. Раньше я без проблем отлаживал дампы .NET framework с помощью WinDBG, но с дампом, поступающим из службы приложений Azure, происходит что-то странное: и clr.dll, и coreclr.dll загружаются внутри процесс..

В результате при использовании правильной версии SOS из WinDBG (той, которая указана в пути установки sdk ядра dotnet на моей виртуальной машине Azure) при запуске! Dumpheap отображается следующая ошибка:

0:000> !dumpheap
Error requesting GC Heap data
Unable to build snapshot of the garbage collector state

Я попытался опубликовать свою службу приложений локально, как автономную или зависимую от платформы, и запустить опубликованные двоичные файлы. В процессе загружается ТОЛЬКО .NET Core Runtime (coreclr.dll), поскольку мой проект нацелен на .NET Core 2.1.

После развертывания в Azure двоичные файлы запускаются IIS с помощью процесса w3wp. Внедряет ли этот процесс некоторые зависимости в мою службу приложений, для которых требуется .NET Framework? Почему мое приложение .NET Core 2.1, работающее в Azure, имеет некоторую зависимость от .NET Framework?

При анализе файла дампа (с помощью ClrMD) внутри присутствуют две среды выполнения:

  • .NET Core (mscordaccore_X86_X86_4.6.26212.01.dll)
  • .NET Framework (mscordacwks_X86_X86_4.7.2563.00.dll)

Протестированные сценарии (не сработавшие):

  • Открытие 32-битного дампа развернутого приложения, зависящего от платформы, в Azure с помощью WinDBG v10 (из Win10 SDK)
  • Открытие 32-битного дампа развернутого приложения, зависящего от платформы, в Azure с помощью WinDBG Preview v1.0.1805.17002
  • Открытие 64-битного дампа автономного удаленного приложения в Azure (из Win10 SDK) с использованием WinDGB Preview v1.0.1805.17002

Что работает (почти):

  • DebugDiag может анализировать дамп и показывать некоторую информацию о куче (чтобы она могла как-то ее прочитать)
  • Мне удалось прочитать дамп с помощью ClrMD, используя собственный код C #, но не все объекты кажутся присутствующими, когда я просматриваю кучу (некоторые объекты, показанные DebugDiag, не видны, когда я просматриваю кучу вручную).

Тем не менее мне нужно иметь возможность читать дамп с помощью WinDGB, чтобы найти потенциальную утечку памяти. Уже много часов я работаю над этим и не могу найти никакого решения.

Любая помощь будет принята с благодарностью! :)


azure .net .net-core sos windbg
person Jerome Thievent    schedule 13.06.2018    source источник
comment
Почему для вашего приложения включена платформа .NET Framework, когда в этом нет необходимости?   -  person Lex Li    schedule 14.06.2018
comment
Он не зависит от .NET Framework при локальном запуске приложения. Но после развертывания на лазурном сервере clr.dll загружается. Когда он делает полный дамп на dotnet.exe, он видит, что модуль clr загружен   -  person Steven Muhr    schedule 14.06.2018
comment
Из любопытства, не могли бы вы попробовать открыть этот дамп в JetBrains dotMemory? Интересно, будет ли тоже ошибка.   -  person Ed Pavlov    schedule 05.07.2018
comment
Используя JetBrains dotMemory, я получил исключение: эта среда выполнения не инициализирована и не содержит данных. Используя SciTech .Net Memory Profiler, я могу открыть дамп, но все экземпляры объектов, относящиеся к платформе .NET Core, не видны, тогда как все экземпляры objet, относящиеся к .NET Framwork, видны.   -  person Jerome Thievent    schedule 07.07.2018
comment
@JeromeThievent, и есть ли вероятность, что вы сможете загрузить свой дамп вместе с соответствующим файлом mscordaccore.dll / mscordacwks.dll в uploads.services.jetbrains.com? Нам любопытно исследовать поведение dotMemory в этом случае, но проблема, похоже, не воспроизводится в нашей тестовой среде. Заранее спасибо!   -  person Ruslan Isakiev    schedule 01.08.2018
comment
@RuslanIsakiev Загрузка завершена. файлы: dotnet_7724.dmp, mscordaccore_x86_x86_4.6.26212.01.dll, sos_x86_x86_4.6.26212.01.dll. Свяжитесь со мной в личку, если хотите подробностей, или мою контактную информацию. Я буду рад помочь JetBrains!   -  person Jerome Thievent    schedule 02.08.2018

Ответы (1)


arrow_upward
6
arrow_downward

Была аналогичная проблема и исправлена, выполнив эти команды.

Вы правы в том, что windbg использует неправильную среду CLR (неправильную, как в приложении net core). В этом можно убедиться, запустив команду .cordll и просмотрев путь к используемым файлам среды выполнения.

Сообщите отладчику, какую среду выполнения dotnet использовать

.cordll -I coreclr -lp "D: \ Program Files (x86) \ dotnet \ shared \ Microsoft.NETCore.App \ 2.1.1"

Выгрузка и перезагрузка модулей отладки CLR

.cordll -ve -u -I coreclr -l

person dnndeveloper    schedule 10.07.2018
comment
Оно работает! Большое спасибо, вы просто сэкономите мне часы на будущую отладку. - person Jerome Thievent; 12.07.2018