Будет ли когда-либо профилировщик CLR загружать собственные изображения, которые не оптимизированы для профиля?

Question

Будет ли когда-либо профилировщик CLR загружать собственные изображения, которые не оптимизированы для профиля (то есть были скомпилированы с ngen.exe без /profile вариант)? Если да, то на каких условиях?

Я немного исследовал, и кажется, что ответ "да, будет", но что-то не складывается, и я не могу получить простое непрофильное собственное изображение для загрузки, когда CLR работает с профилированием,
Я запутался, так как:

• С одной стороны, установка COR_PRF_USE_PROFILE_IMAGES Флаг события монитора может быть использован для того, чтобы заставить профилировщик искать только изображения профиля ( здесь, здесь), и если он не найдет их, вообще не будет загружать изображения - что, если я правильно понимаю, означает, что если этот флаг не установлен, CLR будет искать простые нативные изображения по умолчанию (и вернется к JIT, если не найден).

• С другой стороны, кажется (по крайней мере, в моей среде), что непрофильные изображения не будут загружены в любом случае, так как встроенный механизм связывания изображений будет жаловаться на несоответствие - изображение без профиля, но CLR работает с профилированием (как также описано в этом сообщении в блоге, пункт 3, но с другой стороны - изображение профиля используется, но профилировщик не указан).

Простой тест показывает, что при попытке запустить HelloWorld.exe это был NGEN'd с ngen.exe install HelloWorld.exe, с включенным профилировщиком, журнал привязки сборки (ExplicitBind!FileName=(HelloWorld.exe).HTM) показывает:

Операция прошла успешно.
Результат привязки: hr = 0x0. Операция завершилась успешно.

Менеджер сборки загружен из: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll, работающего под исполняемым файлом d: \ work \ dotnet \ projects \ HelloWorld \ HelloWorld \ bin \ x64 \ Debug \ HelloWorld.exe
--- Подробный журнал ошибок следует.

WRN: Собственные параметры компиляции изображения не соответствуют запросу. Ищем следующий родной образ.

Но при работе с изображением профиля NGEN'd с ngen.exe install HelloWorld.exe /Profile, изображение успешно загружено, и вывод связывателя сборки:

LOG: начать проверку всех зависимостей.
LOG: [Уровень 1] Начать проверку собственной зависимости изображения mscorlib, Версия =4.0.0.0, Культура = нейтральная, PublicKeyToken=b77a5c561934e089. Нативное изображение имеет правильную информацию о версии.
LOG: проверка зависимостей выполнена успешно.
LOG: привязка к исходному изображению успешно завершена.
Попытка использовать собственный образ C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\HelloWorld\5647de1868c93e9132a1952a34e0a785\HelloWorld.ni.exe.
Родное изображение успешно использовано.

Между каждым шагом нген я убрал c:\Windows\assembly\NativeImages_v4.0.30319_32\mscorlib для всех изображений согласовать используемые настройки (нет никаких дополнительных зависимостей HelloWorld.exe).

Любая помощь / советы очень ценятся!

PS Я использую.NET 4.0, поэтому не имею доступа к COR_PRF_DISABLE_ALL_NGEN_IMAGES, который, как говорят, вообще отключает нативные изображения (этот пост в блоге от Дэвида Бромана подразумевает, что этот флаг отключает все виды изображений, а это означает, что во время профилирования CLR могут использоваться как обычные, так и оптимизированные профили).

Answer 1

Возвращаясь, чтобы ответить на мой собственный вопрос: да, нативные изображения, которые не оптимизированы для профиля, будут загружены, учитывая, что COR_PRF_USE_PROFILE_IMAGES флаг не установлен в маске событий профилировщика.

Источником моего потребления было неверное прочтение выводов журнала FUSLOGVW. В частности, как-то я упустил, чтобы увидеть, что WRN: Native image compile options do not match request. Looking for next native image был дан для /profile изображение, но поиск изображения продолжился и нашел простое непрофильное изображение, и успешно.

В конечном итоге мне помогло понимание того, что при отладке профилировщика в Visual Studio привязка собственных изображений отображается в окне "Вывод отладки", где также отображаются загружаемые библиотеки DLL, например:

'CSharpTestProgram.exe' (Win32): загружен 'C:\Windows\assembly\NativeImages_v4.0.30319_64\mscorlib\2ef49acbb43c068f6ddf1587283b5f29\mscorlib.ni.dll'.

Как только я получил это, журналы FUSLOGVW стали более понятными для меня, и я смог точно понять, какое изображение загружено и когда.

Другое наблюдение состояло в том, что mscorlib /profile изображение занимает больше места на диске, чем обычное собственное изображение (в моем случае это на 30% больше) - это также помогло соотнести путь к изображению и его /profile или нет.

Надеюсь, это кому-нибудь поможет.