Чем запуск приложения C # внутри профилировщика кода отличается от запуска одного внешнего профилировщика кода?

Короткий ответ: мой файл System.ni.dll был поврежден, я заменил его, и все в порядке.

Длинный ответ может помочь кому-то еще в своем подходе к решению ...

Моя проблема связана с тем, что .Net был поврежден таким образом, что приложения не запускались, кроме как через профилировщик. Я загрузил исходный код для профилировщика с открытым исходным кодом SlimTune, построил его локально и установил точку останова прямо перед вызовом Process.Start (). Затем я сравнил все параметры, необходимые для успешного запуска приложения с помощью профилировщика, и вручную. Единственное существенное отличие, которое я обнаружил, - это добавление параметров профиля .NET к переменным среды:

• cor_enable_profiling = 1
• cor_profiler = {38A7EA35-B221-425a-AD07-D058C581611D}

Затем я попытался установить их в среде своего собственного пользователя, и вуаля! Теперь любое приложение, которое я запускал вручную, будет работать. (На самом деле я пытался сделать то же самое несколькими часами ранее, но я использовал GUID, который был включен в пример и который не указывал на настоящий профилировщик, и, очевидно, .NET знал, что я дал ему поддельный GUID и не запустить в режиме профилирования.)

Теперь я вернулся и начал читать о том, как исполняется PE-файл в среде CLR, в надежде выяснить, почему важно, чтобы мое приложение запускалось с включенным профилированием. Я многому научился, но ничего не подходящего.

Однако я вспомнил, что должен перепроверить журнал chkdsk, в котором перечислены файлы, которые были повреждены в результате сбоя диска. После сбоя я превратил все перечисленные идентификаторы файлов в пути / имена файлов, и я заменил все 100+ файлов, которые мог из резервной копии, но, конечно же, когда я вернулся и посмотрел, я обнаружил примечание, что, хотя я заменил 4 или 5 файлов, связанных с .NET, был один такой файл, который я не смог заменить, потому что он «использовался». Этот файл? System.ni.dll !!! Теперь я смог заменить этот файл из резервной копии, и вуаля моя установка .NET вернулась в нормальное состояние, приложения работают независимо от того, профилированы они или нет.

Расстраивает то, что, когда этот инцидент впервые произошел, я полностью ожидал, что проблема будет связана с поврежденным файлом, и в частности с файлом с именем System.dll, в котором размещены методы, которые потерпели неудачу. Итак, я различил и переопределил все файлы с именем System.dll. Но в то время я не понимал, что System.ni.dll является собственной скомпилированной версией System.dll (или чего-то подобного). И поскольку я изменил и переопределил каталоги, связанные с .NET, и не заметил этого (не знаю, как я это пропустил), я отказался от этого подхода.

В любом случае ... Короче говоря, причиной моих проблем был поврежденный System.ni.dll, содержимое одного или нескольких кластеров в нем было заменено на 0x0, и это проявилось как странная проблема, которую я заметил.

Это похоже на проблему с синхронизацией, которую профилировщик «исправил», сделав ее немного медленнее.

Многие профилировщики используют инструменты (подробнее здесь), что немного замедляет работу приложения. Очевидно, это замедляет один поток настолько, что другой поток может выполнять немного больше работы, предотвращая этот сбой. Подобные ошибки часто не проявляются непосредственно на машине разработчика, а проявляются, как только они запускаются на процессорах с большим количеством ядер или гиперпоточностью. Иногда они встречаются только в сборках выпуска (или наоборот, в сборках отладки). Проблемы с синхронизацией бывает сложно отследить, поскольку один и тот же код может давать разные результаты в разных условиях (в профилировщике или отладчике).

Из вашего описания я попытаюсь догадаться, как это можно исправить:

Попробуйте найти в источнике, откуда запускаются новые потоки. Затем после их создания добавьте туда строку System.Threading.Thread.Sleep(500);, чтобы приостановить основной поток и дать новым потокам время для запуска.

Без исходного кода и нескольких следов сбоев в стеке это довольно много догадок.